Re: [Proposal] What is Chandler supposed to do anyway?

+1 This point has been made several times in the past and I agree with  
it.

Separating filter and display is easier for people to understand, it  
allows for easier addition of new filter or display types, it lets  
people slice and dice their data in new and interesting ways and it's  
much easier to implement.

The only downside that I've heard mentioned to it is that it takes  
more screen real estate to implement two separate controls instead of  
one and sometimes requires an extra step to get where you want to go.  
Our simple tool bar buttons don't extend easily to many new filters or  
display types, so you'd probably have to go with something open ended  
like a drop down list.

I don't think it would be too hard to implement and it would yield a  
nice reduction of code complexity and a net reduction in code size.

John


> Confused View Metaphor:
>
> I believe, in the chandler UI there has been a confusion between the
> concepts of filtering vs presentation.
>
> By filtering, I mean what items appear in a given screen.
> By presentation, I mean what the layout of the items are on the  
> screen.
>
> As I see it, the presentations are calendar style (month,week,day),
> and Table (i.e. list style).
>
> The filters are calendar items, task items, mail items, and note  
> items.
>
> The word calendar is used to describe both filtering and presentation.
> But more importantly, because the verbs (buttons and menus) are
> separated from the areas they control (the objects) it is unclear what
> it means to click on calendar or mail, or what it means to select all
> or mail in the view menu. Because really, in the view menu, you are
> filtering *and* changing presentations. This means in the same menu,
> similarly grouped verbs operate on different types of objects.
>
> The result is it is very difficult to visualize the underlying data
> model because there are no consistent rules.
>
> So I am going to suggest, as I have for related issues, that the view
> menu be eliminated and the intended commands moved much closer to
> there intended targets.
>
> Structurally there should be a view control and a filter control.
>
> The view control options are: Table or Calendar.
> Within the Calendar area there should be a popup menu to choose day,
> week or month.
>
> The filter control options are: Mail, Note, Task, Event, Show All.
>
> Also, consistent behavior should be enforced as relates to
> presentation type. This means if I am in the fun collection, it should
> *never* be possible to change the presentation type by changing to
> another collection. If I am viewing using a month view then that
> should be stable regardless of what collection I am in. The mental
> model of the system falls apart when filtering the contents changes
> the way the view looks.
>
> Just to clarify, I understand why the design is the way it is. I am
> sure it was felt that the easiest thing to do would be to just give
> users commands that related directly to what they wanted to do and to
> therefore "simplify" by making a command change the presentation and
> filter at the same time when it was "logical" to do so.
>
> The problem is that by skipping these steps and not clearly
> establishing the axes along which the program operates, reinforced by
> interface objects that reflect state and the relationship between
> states, the underlying data model becomes unclear. The interface
> designer's critical task is to support and reinforce the users
> understanding of the data model even if that may at times require a
> bit more screen real estate or an extra step on the part of the user.
> Shortcuts can always be added for power users comfortable with the
> data model.
>
> Hank
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design