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
