[Design] [Proposal] What is Chandler supposed to do anyway?
hank777 at gmail.com
Sun Dec 9 18:35:09 PST 2007
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
More information about the Design