Design Issues Meeting 25 November 2003

Attending: MitchKapor, AndyHertzfeld, MimiYin, BrianDouglasSkinner, DuckySherwood

(Editor's note: these notes are my best understanding of what we believed on 25 November 2003. There are few guarantees that this will be an accurate depiction of reality in the future.)

Terminology

Mimi presented a number of elements that she uses in her designs, mostly to get us synched up on what she means by different terms:

Kinds are types of Items -- Email, Tasks, Calendar, Notes, and Contacts. Filters are discussed more below, but span all information Kinds. Browser in this context means a calendar-based browser. The Viewer has three sub-buttons to let people switch between a list view, a calendar view, and a grouped view. The Query-er is a text entry box that can be used to define a query.

Main View

Mimi showed a design for a possible way of navigating to different views of data. Part of the design (less the query-er) is in the first picture below.

At the top is a query-er.

Below that is a toolbar, with buttons for Mail, Tasks, Calendar, Notes, and Contacts.

Below that is the main view of Items.

To the left of the main view is a sidebar of filters, with things like "Unread" and "Cobra Project".

In Mimi's vision, clicking on one of the toolbar buttons (e.g. Mail, Task, etc) brings up the "default" view for that Kind. For example, clicking on Mail would bring up the user's Inbox.

From there, the user could click on various filters to restrict the data shown in the View. For example, the user could click on "Unread" and "Cobra" to restrict the view to Mail messages that are both Unread and tagged with Project of 'Cobra'.

When the user clicks on the filters, the query-er shows the parts of the query. Thus, for example, when the user clicks on "Mail" in the toolbar, the query-er would show something like "Kind='Message' and direction='in'". When the user clicked on "Cobra", the the query-er would display something like "Kind='Message' and direction='in' and project='Cobra'". Mimi also suggested that color coding could visually tie the query-er query elements and the filters. For example, "Cobra" in the list of filters would be e.g. green and the text "and project='Cobra'" would be the same e.g. green:

View-specific buttons

At the top of the main Item pane, Mimi envisions the possibility of a few buttons specific to that kind of View. For example, for the Email pane, she envisions checkboxes for In and Out, and a mini-toolbar for "bookmarks" of common Mail views.

Combining Tabs

Clicking on a second toolbar button would bring up a second tabbed view. For example, if the user first clicks on Mail and then on Task, there would be two tabs on the View to allow users to switch between viewing Mail and viewing Tasks. To merge the views -- to see both mail and tasks in one view -- the user would drag one tab onto another.

Grouping Button

At any point, the user can hit the Grouped View button to group Items in the list by a particular attribute. For example, all the Items from the Cobra project would be at the top, all the Items from the Mustang project would be in the middle, and all the Items from the Zebra project would be at the bottom:

Calendar Browser

Users could also modify a view with the Calendar Browser. If the user selects a day on the calendar, then Chandler would highlight all the Items associated with that day (and only those Items). Similarly, the user could select a week or a month to highlight that week's Items or that month's Items.

If you select a day, then press the Grouping button, Items would then be grouped by day.

Filters vs. Views

Most of the ensuing discussion in the meeting centered around filters vs. views. Mimi is concerned that a list of all the possible views would be long and redundant. For example, you would end up with "home" and "work" views for Tasks, for Email, for Events, etc. By allowing users to expand the View's query (i.e. limit the data shown) with filters, there would be less redundancy.

Editor's note: after the meeting, Mimi wrote up ShouldUsersPrimarilyBeInViewModeOrFilterMode, which gives a visual example of an explosion of Views.

Mitch and Andy argued vocally against that paradigm.

They saw filters principly as a way to create new views, and thought that filters were given too much prominence. Andy felt that at least 90% of the time, users would want to go straight to a stored view, and spend less than 10% of their time creating new views. Mitch felt that most people would NEVER create a view. They both thought the filter bar should be hidden for most of the time and only made visible when the user was creating a new view.

Mitch didn't think that having too many Views was a problem. Andy guessed that a simple user would have about six, while a power user could have zillions. There was some discussion about manage Views in a way similar to how Web browsers manage bookmarks.

Mitch did like the pushbutton method of constructing Views, so somewhere the "filter" construct should exist... the question is where and how prominently. Mimi suggested putting a "View" tab on the Filter list so that you could switch between them easily. Andy objected to the View tab being behind, and thus subordinate, to the Filter tab.

Mitch also pointed out that more than about twelve tabs was unmanageable. Multi-row tabs didn't work well either.

There was discussion about the difference between filters and views. Synthesizing madly, this editor thinks that the way Mimi was using the terms:

• Views are a combination of
  • layout
  • a complete query
• Filters are query clauses that can be AND'ed with an existing complete query to expand the query (i.e. restrict the data returned).

User modes

We talked a little about what modes users are in:

1. Select predefined out-of-the-box (OOTB) Views (e.g. Inbox, current month).
2. Customize existing view or view a template on the fly.
3. Create and save user-defined view for future retrieval.

We have disagreement over how users will rely on these different activities, with Mimi advocating a more prominent role for #2 than Mitch and Andy do.

Color

At some point, Mimi suggested that the user could click once on a filter to highlight messages matching that filter, and a second time to restrict the view to only messages that matched that filter.

Andy was concerned about the color connection, pointing out that if a View has a huge number of items in it (e.g. mail inbox), you might highlight a certain class of messages -- and not see any color change because the first highlighted message would be too far up or down the list to appear. The user would have to scroll to see it. Perhaps if the user selects a filter, the window should scroll to the first occurence of a matching Item.

URLs

We got into a discussion of how Views, URLs, and queries are related. There was some sense that a URL should be a query. In Andy's view, a URL specifies a View -- a place where people go. On the other hand, the CPIA work says that each little thing on the screen can have its own query. Mitch felt that a query specifies a set of items. Andy said that URLs are hierarchical and actually have three parts: the address on the network, then the Capplet, then the View. It might be possible to pass parameters to the view that allowed you to drill down to a smaller set. We moved on and left URLs as an open issue.

Summary

Consensus

• The "pushbutton" way of creating queries from individual filters is useful and should exist somewhere.
• Bookmarks of E/T/C/N/Ct Views that we prepopulate can be hierarchical.
• We have a goal of getting UI mockups to Katie that she can use to give direction for the 0.3 release.
• The Apps group will not get pixel-level screenshots by 0.3, but they will get such by the 0.4 release.

Open Issues

• How are URLs, Views, and Queries related? Are the view types included in the URL?
• Is there a single global status for all Items? Are Task and Email statii different?
• How prominent should the list of view filters be?
• What is the proper term for what Mimi called "filters" here?
• Is the Viewer okay? We need more discussion about that.
• We need to talk more about the different activities users can do in creating and modifying views.
• What kind of Kind-specific affordances will there be in the main view's data view (e.g. checkboxes for In and Out in the Email view)?
• Will the list of filters look the same for all Kinds, or will the filter list change depending upon which Kind(s) are displayed?

Action Items

• Mimi to draw up what this view looks like out of the box (OOTB) -- including which views are pre-loaded.
• Mimi to generate pictures of the list, calendar, and group views (what you get when you click on the Viewer buttons).
• Mimi to make a series of sketches for each Capplet for three levels of activity to give to Katie bu the end of the week.
• Ducky to write up the meeting notes.

-- DuckySherwood - 02 Dec 2003