Design Issues Meeting 4 December 2003

Attending: MitchKapor, ChaoLam, MimiYin, BrianDouglasSkinner, DuckySherwood

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

Chao opened by saying that our urgent goal is to gain consensus for our 0.3 release deliverables. A secondary goal is to provide context for beyond the 0.3 release.

We need to figure out exactly what deliverables we provide to the Apps team on an ad hoc basis for 0.3 and what we will deliver in a more formal way for 0.4.

A subset of the Design Team met with Katie later in the day with the consensus items from this meeting. (@@@ when the Cat and Nav docs get wikified, update the later meeting notes)

Chao mentioned the idea of going to a usage-scenario-based release process instead of a feature-based release process. Andy thought that would be okay if the usage scenarios were more succinct and less anecdotal. We agreed that in the limiting case, scenarios and feature requests ended up looking almost identical.

Mitch thought that we should start with one scenario and see how that works before trying to do a lot of scenarios. We deferred discussion on that topic for later.

Caterpillar UI

Mimi presented the "Caterpillar" interface that we'll use for 0.3. It's called "Caterpillar" because it's hopefully going to turn into something much different and more beautiful.

The decisions on Caterpillar won't necessarily stick. It would be nice if we could make "sticky" decisions, but we have immediate issues and need to do something soon.

The Caterpillar UI has three parts: the Navigation bar at the top, the content display area below it, and the side bar to the left of the content display area.

The nav bar has

• forward, back, stop, reload, and save buttons
• URL text entry/display bar
• a bookmark toolbar

The content display area is split, with the list summary view on top and the preview (detail) view on the bottom. The current display area is a tabbed view, meaning that there can be multiple content display views selectable via tabs at the top of the list summary view.

The sidebar has "trays" for each of the silos of Kinds: Mail, Calendar, Tasks, Contacts, and Notes. (Note: Repository and ZaoBao might also be in the sidebar, but they might only be menu items since they will only have one View apiece.) Clicking on each of the Kinds will disclose the "tray" of Views for that Kind. For example, clicking on Mail will expose In and Out Views. Clicking on Mail again would hide the Views.

Clicking between different Views causes the Views to alternate in the frontmost tab. Right-clicking on a View creates a new tab for that View. (This is identical to how tabs work in Web browsers: new content is always loaded into the frontmost tab; you have to do something "special" to create a new tab.)

Right-clicking on a tab pops up a menu which has, as one of its options, creating an empty tab (i.e. one with no contents).

There was some discussion about persistence of Views. Andy felt that any change you make to any View should persist. Other people voiced an opinion that they wanted to be able to make temporary changes, then revert to their original View. One idea for persisting a View was to make it a bookmark. This decision was deferred.

Single-attribute Views (formerly known as filters)

Each tray has single-attribute Views that can be combined. Yes, this implies that only homogenous Views can be combined. Yes, that's trouble if there are radically different Views in the tray (e.g. an "accounts preferences" View next to the In and Out Views in the Mail tray). Perhaps if you try to combine disparate Views, the UI just won't allow it. Perhaps the data from the second View will get forced into the layout of the first View; any fields that the second batch doesn't have will just show as blank. We will not specify the behavior, but will let Katie choose whatever is expedient.

Mitch noted this as an important point: there are some Caterpillar features that we like but we know they would make other features difficult (or impossible). That's okay: we'll play with them in Caterpillar and maybe move them, maybe drop them later. He likened this UI to sailing: the wind is blowing where the wind is blowing; you start out sailing even though you know that you're going to have to tack sooner or later -- instead of waiting for the wind to be in exactly the right direction.

Brian pointed out that some attributes naturally partition items into obvious and mutually exclusive groups (read/unread, inbox/outbox); some attributes have more of a "playlist" sense where belonging to one group doesn't exclude it from another interesting group. In the playlist metaphor, something can be both in your "60's music" and "Favorites" groups. We deferred the question of whether those two types of Views would have different affordances.

Andy disagreed with calling the detail view the "preview pane". Mitch noted that the fact of the matter is that people know that term and are used to it.

Nav bar (sometimes formerly called the "URL bar)

We went through Chao's proposal for the Nav Bar pretty quickly. (See also ChandlerNavigation for the questions it's addressing.)

We talked about other purposes of the nav bar (aside from ones mentioned in Chao's proposal). Andy pointed out that the Back button also, in a sense, gives something of an "Undo" function. Mimi elaborated on use #1 -- show where you are -- by noting that in a sense, it gives a bit of a breadcrumb trail and tells you what it means to be where you are.

Mitch asked if we were really talking about URIs instead of URLs -- that perhaps we wanted to specify a repository in the abstract which might have multiple copies. Ducky thought we meant URNs instead, and we decided that we collectively didn't know (or remember the distinction, so we tabled that.)

(Editor's note: URIs are an abstract superset of URLs and URNs. URNs do (in theory) allow for multiple copies in different locations, but URNs appear to still be a very research-y thing.)

Brian imagines that we might want to address different repositories specifically and not in the abstract.

There was some discussion of the history list. Chao originally argued against history being an important feature on the grounds that Chandler would only have a handful of Views to live in the history list, while Web browsing would put hundreds or thousands of URLs in the history list. Mitch's counter-argument was that if you know you had it up in the past day or two, you can look in your history list to find it again. I believe that we agreed that history was important (and linked to the back button on a per-tabbed-View basis), but not important enough to try to get it into 0.3.

There was a brief discussion of affordances for showing the history list. There was an idea of making the history list appear in the content view pane to allow for sorting, searching, filtering, etc. Andy

Plans for next week

Mitch discussed things we need to talk about next week:

• Push forward around the idea of collections, which is a pre-requisite for dealing with Views, complex Views, and sharing.
  1. The unit of sharing is a collection, not a ViewGroup (a ViewGroup can have more than more collection)
  2. Sharing's access control lists are associated with collections. This makes it easier to figure out how to do an ACL for the singleton collection of "Me".
• UI and interaction issues
• Push ahead with the PIM schema
• Canonical use cases

Mitch feels that it's important to settle PIM schema issues first -- that it's become apparent that we can't do the UI until we know the PIM schema. There was some mild dissention that the two drove each other, but we truly were all in agreement.

Mimi said that she had the following items to discuss:

1. Collections
2. Collections bin
3. Polymorphability
4. Landscape filtering
5. Item creation

Mitch mentioned that he really wants to kill polymorphability: Tasks and Calendar Events are one item, but everything else should be links or destructive operations (e.g. turning a Note into a Task).

Summary

Consensus

• Caterpillar is not a final UI, it's an expedient UI.
• New content goes into the front tab.
• "Back" operates on a per-tab basis.
• Which tray is selected changes depending upon which tab is frontmost.
• A good history list won't be in 0.3.
• Canoga should have a good history list.
• The history list should be tied to the Back button.
• The Back button's history should be tied to the active individual content view's history.
• Command-return to create a new tab is an okay way to do it. (We didn't have strong opinions one way or the other.)
• Right clicking on a tab will close the tab, and there will probably also be a menu option for closing the tab.
• There will be no duplication of Safari's snap back feature in 0.3.
• There will be a way of accessing single Items with URLs.
• For now, queries can't be represented by URLs. If that needs to change, we'll revisit it.
• Users will be able to hide the sidebar and the nav bar.
• The line between the list summary view and the detail view can be moved to resize the panes.
• If there is only one tab, the tab will still show.

Open Issues relevant to 0.3

• Which Views live in which trays?
• Where does the agent for ZaoBao^? live?

Open Issues that we're not going to worry about settling firmly before 0.3

• What is the ultimate name of the "nav bar"?
• If you select a View, change it, close it, and select the same View, do you see the original View or the changed View?
• What happens when you combine heterogenous single-attribute Views?
• What happens when tabs fight (@@@ huh? Andy: "fights w/tab feature... multiselect would be to have two tabs")
• Is the summary view above the detail view, or to the side of the detail view?
• How do the nav bar and the sidebar interact?
• If you select one View (e.g. Inbox), then right-click on a second Kind (e.g. Calendar), does the first (e.g. Mail) tray close?
• Will single-attribute Views of mutually exclusive groups and "playlist" types of Views have different affordances?
• Will we call the single-Item View the "preview pane", "preview View", "detail View", or something else?
• Would URNs be better than URLs for repository accesses?
• Where will the text entry area for searching or filtering be?
• What will the final syntax of URLs be?
• If Views are incorporated into a URL, what is the URL for an unnamed View?
• If the sidebar is hidden, how will a user reopen it?
• Can the user hide the detail view pane or the list summary view pane?

Action Items

• Mitch and Mimi to meet Friday 5 Dec at 2:30 PM
• Ducky to write up meeting notes.

-- DuckySherwood - 05 Dec 2003