Design Issues Meeting 16 December 2003

Attending: MitchKapor, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood

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

Processing vs. Filing

Mimi discussed usage patterns:

• processing (triage)
• organizing archived messages so that you can find messages later
• organizing to-do so that you can figure out what to do next

She noted that these have traditionally been conflated into one step, when in reality these are different activities with different needs. Furthermore, the user will spend much more time on to-dos than on their archive. The affordances of the common email programs help the user mostly with organizing their archive.

(Note that in Mimi-speak, <X> means "crossed with", i.e. "intersection" or boolean "AND". Her abbreviation for "union" (boolean OR) is <U>.)

This sketch sets up a framework for where things might live. Across the top are "processing" views, things you have to stay on top of, places you go to most. (The bar is roughly equivalent to the "bookmarks" bar.) These are views you go to to decide if something is to do, defer, or delegate.

The icon to the far left of the bookmark bar (to the left of "Universal Inbox" is a bookmark icon -- if you click on it, perhaps i will open up a bookmark management area. TBD.

On the left of the main view area is the sidebar, which shows two levels of hierarchy. For example, Trip to Vegas is a project with subprojects. For other things, you want one-click access, e.g. Jane's Calendar. You can create shortcuts where you pair a kind with specific attributes, e.g. Kind=Message, Sender=Jane.

(There was a side discussion about the mechanism for shared calendars to appear in the sidebar. Mitch felt that calendars were different from email folders. He felt that almost all events would be either in Work or Home, but that the percentage of messages that would be in either Work or Home is typically way less than 100%. Because of that, he feels people will use Home and Work collections differently than Home and Work calendars.)

Continuing on: the Inbox is all the received mail, which is fundamentally different from all the mail in a particular project. The filter "all mail in the Foo project" is more like searching. We should make Kind-specific exhaustive lists on the sidebar for easy access.

Mitch interjected that he didn't like the "C:" in front of the calendars. He thought an icon would be better, though Mimi felt that there were enough icons already. That brought up a question about the five icons above the sidebar: Mimi said they were for filtering the main content view by item type. Mitch felt that they didn't belong in the sidebar.

Mimi is still playing around with the interaction design. She had been thinking about using command-click a lot, but is now wondering if drag and drop would work -- that dragging and dropping a filter into the main view might work. Unfortunately, there's ambiguity between union and intersection, and there needs to be a visual distinction between the two: we can't expect the user to guess that e.g. click means union and command-click means intersection.

Mitch drew a little schematic of a coffeemaker, suggesting that if you drag into the resevoir part, it does a union; if you drag to the filter part, it does an intersection. (He admitted that he has coffee on his mind.) While he drew the picture in silliness, after looking at it, he wondered if maybe something like that might actully work.

Chao asked what the distinction between bookmark items and sidebar items was. Mitch explained that it was frequency: the things you use hundreds of time per day are on the bookmark row. The things that are on the sidebar are a more exhaustive list. (Mimi and Mitch disagreed about whether the set should be a completely exhaustive or just bigger list.)

Chao asked if someone were to drag an item from the main content view to a project-based filter (e.g. "Trip to Vegas"), would that add the item to the Trip to Vegas project? Mitch and Mimi, said yes, though with the caveat that the View needs to allow that. Some views might disallow this type of drag and drop. For example, the Inbox (Message only) might prevent someone from dropping a calendar event onto it.

Today View/Universal Inbox

Mimi showed her "Today" View, or Universal Inbox (what later in the day became the "Past/Present/Future" View.

At the top is stuff that has been stored, Items that are "done". The user still wants to have them around, but have them out of the way. Below that is the "fuzzy timeframe" area -- a place for things that have a fuzzy time like "this week" or "this month" associated with them.

Below that, Items are filed by date. Note that the date is shown in less detail than is common; for most messages, people don't need to know the arrival time down to the exact second.

Below that section that are upcoming calendar events.

Users can sort messages in the center area either by date or by dragging things around the way they like them. For example, a user might have six untimed tasks related to shopping and want to gather them all together. The "123" icon is not a Lotus icon, but a toggle button for switching between date-ordered and user-ordered.

Items that haven't been seen (e.g. unread messages) are in bold. There will be a button for "done", but she hasn't figured out where yet.

From this view (from any view), users should be able to add columns and organize messages.

For the time when an event is happening, the icon is filled in. The icon is not filled in next to reminders for an event.

There were some objections to time moving from past ("done") to present ("this week", "this month"), then backwards in time to things that happened before this week or this month. Mimi and Mitch to discuss that and nail it down. Mitch felt that location was related to order, and his ranking of Items is as follows:

1. today's tasks and events (including stuff carried over from previous days), scheduled and unscheduled
2. email (it has to go someplace)
3. active old email -- messages he wants to keep around
4. more tasks that are active but are not as important -- roughly "this week, this month"
5. future meetings and tasks

Mitch pointed out that usually, the top and bottom of the view are landmarks -- easy to get to and see -- so the things you want to see are usually at the top and bottom of a View. Putting the important stuff in the middle would be different, but might work if we had a "now" button that took you to the stuff you wanted.

Mimi said that a "now" button would fit well with the "scrollbar bookmarks" in NavigatingTheChandlerLandscape.

Chao asked how this view interacted with Collections. Mimi replied that the user should be able to navigate to other collections that an item is a member of via the detail view. Users would need to switch views, but that's an acceptable limitation. (Mimi noted that in Outlook, every person in an email message's headers was linked to the appropriate Contact record. She's not sure if we need to do this for Canoga.)

Chao asked how unnamed collections would get promoted to a Project. Mimi suggested that the user could select a set of Items from the universal inbox, then drag that set (to the sidebar?) to create a new View, which would have the side effect of promoting that set to a named collection.

Chao asked if this view has a preview pane or not. Mimi said that she just hadn't shown it in the drawing, but that it could go either below universal inbox or to the side. To put it on the side would require a good line rewrapping algorithm. If we don't have time to develop a good line rewrapping algorithm, we should put it on the bottom. Mitch said that if she could fit the sidebar, content, and detail side-by-side in 1024 pixels in something as legible as 12 pt Verdana on the Mac, then he'd be fine with putting the detail view on the side -- if and only if the summary view stayed at one line per message. The Outlook style with two lines per message was unacceptable to him. (We might also consider a case where we have a different and better layout for people with 1280 pixel widths, and do the "better" version when width permits.)

He did note that there were various things we could do to compress the width of the summary view -- abbreviate the time as is shown in Mimi's view, abbreviate the name by using nicknames, etc.

(We got into a brief side discussion of screens with higher DPIs, and how that messes up the fonts, icons, spacing, button sizes, etc. The Mac's dock deals with this by insisting that the icon designers provide the icons in a huge number of different sizes. We made displeased faces.)

Delegation

We spoke briefly about delegation. Mitch feels that we should allow this workflow:

• Someone proposes a meeting and invites people.
• The invitees get email with buttons that allow them to accept/reject/accept tentatively/counterpropose.
• Responses accumulate.
• The person who propsed the meeting either
  • lets the proposal stand
  • reschedules, in which case we go back to the beginning of the workflow

It would be a major headache to do anything more, so any more should be "extra credit", something we do at the very end. He explicitly made the non-goal of task delegation in the same manner as calendar delegation because he thinks it's too hard.

However, collections can be shared, so you can share a task. Delegation can happen "out-of-bound", i.e. through non-Chandler channels (telephone, hallway chats, etc). We won't support anything formal beyond using sharing and our given Content Model.

(Side note: Mimi mentioned that she was uncomfortable starting on capplet designs because she needs to know what affordances we'll give users. For example, from a UI perspective, how do we show something has an attachment? How do we create a reminder. Chao asked if she could get adequate information from e.g. the CalendarFeatureList2004? Brian pointed out that there are multiple feature list documents in different formats; Chao and Brian discussed briefly how to unify them. We decided that this is a big hairy problem that should be taken off-line.)

Summary

Consensus

• We will design for a screen width of 1024 pixels, and text must be at least as legible as 12 pt Verdana on the Mac.
• While Tasks can be shared, Task delegation through Chandler is not a goal.
• Any rescheduling of a meeting must be done by the original inviter.

Open Issues

• Will we make accomodations for screens that have high DPIs?
• Will the preview pane be to the right of or below the summary pane?

Action Items

• Mimi to send Mitch pointers to Longhorn papers.
• Brian to look at the Longhorn schema.
• Chao to publish agenda for Thursday.
• Brian and Mimi to meet to talk about what Mimi needs from feature lists.
• Mimi to propose how views end up in the sidebar.

-- DuckySherwood - 17 Dec 2003