+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
