Design Issues Meeting 1 Dec 2003

Attending: MitchKapor, MimiYin, ChaoLam, BrianDouglasSkinner, TedLeung, DuckySherwood

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

Process

The meeting opened with some discussion of strategy and approach. Things that are on our plate include:

1. 0.3 deliverables
   • UI Landscape 0.1
   • Chandler Navigation
2. UI Landscape
   • stronly linked items/item stamping
   • groups
3. Usage patterns
   • Dave Allen approach
4. PIM Schema
5. Design strategies to date
6. Synthesizing and distilling the wealth of decisions made
7. Deliverables specification

Chao felt that we need to focus on #1 this week, since the developers really need our deliverables in order to put something together for 0.3.

Chao felt that we're reasonably close on #2, and that it's probably best for Mitch and Mimi to work on this one-on-one.

For #3, we need to discuss usage patterns, "what are the most important actions we want to help users with", and how to weight the different usage cases. It might make sense to section this work between Mitch and Chao first, then involve the larger group.

Brian is working on #4, and is close to having a strawman schema ready. (Editor's note: see SchemaRoughSketch200312.)

Chao felt the need to bettter synthesize and document our decisions to date.

Chao felt that numbers 2, 3, 4, 5, and 6 could be parallelized.

Work Modes

Mimi then presented a bit about how David Allen talks about different work modes:

• Collect
  • e.g. receiving mail, receiving meeting invitations, creating tasks, etc
• Process
  • decide to do, delegate, defer, or delete -- which you might do in your inbox, taskpad, Today view, or in a specialized view
• Organize
  • filing by attribute, project, timeframe, urgency, etc
• Review
  • look at items with specialized views, e.g. by project
• Do
  • writing/replying to email, arranging/coordinating events, collecting info across the PIM, writing longer notes, etc

Mimi also noted that across all these activities, there are general navigation issues related to scanning, scrolling, sorting, grouping, and attribute filtering.

We noted that using the Dave Allen taxonomy doesn't separate user tasks as neatly as we might like. For example, in the Process step, you can Do something. In the Collect and Review steps, users work with groups of tasks before moving on to the next mode, while users Process one item, Organize the item, Process the next, Organize the next, and so on, one at a time.

Mimi noted that we need to be good not just at each individual mode, but also at carrying users between the modes. It will be nice if we can give users templated ways to cross the organize-review-do chasm, and allow users to create their own templates.

@@@ ask Mimi what she means exactly by the organize-review-do chasm

Mitch felt that was a good starting point, and noted that Chandler should have affordances to make it easy to:

• collect (with the ubiquitous text entry box)
• organize (with stamping and linking items)

but from his time with Agenda, he believes it's very difficult to create a template for crossing that chasm, so we should scale back our ambitions to more modest goals.

Mimi mentioned that one reason why the myriad Entourage Views weren't useful is because the users didn't create them.

Chao asked how we should scale back our goals: what wouldn't we do? Mitch pointed out that when all was said and done, users will still have piles of "stuff"; that they'll still have to stare at the stack of stuff themselves and figure out what to pick to work on next. There are limits to what a PIM can do.

Ted piped up that there was a good opportunity for people to provide "organizer du jour" plug-ins that implemented the "Franklin-Covey" method or the "Daytimer" method.

Mimi felt that we could come up with a handful of basic views that would be helpful to users, that they might not think of making on their own, e.g.:

• Today
• Active projects with pending items
• Last two weeks x project activity (@@@ huh?)
• To-do items by location

Mitch felt that providing these views was a nice goal, but that it was "extra credit" and not necessary for right now. Mitch did ratify, however, that Canoga will have affordances to help the user create views like those. He also believes that Canoga will have a "Today" view, but in the 0.4 timeframe.

Filters

Following up on the 25 November meeting, Mimi talked more about navigation. She presented two alternatives.

In the first option, which I will call Option A for the purposes of this document, users first select a view from the sidebar, and then a filters list would pop up. The filters that are involved in creating the query would have checkmarks next to them.

In Option B, the views would be in the toolbar (possibly with drop-down menus of more filters), while filters would always be in the sidebar.

Mitch felt strongly that "filter" was the wrong word, but was unable to articulate what word he thought would be better -- in part because he could't understand exactly what Mimi meant. (Editorial note: I believe that in Mimi's world, a "View" is a layout plus a complete query. A "filter" is a query element that can be ANDed with a query to restrict the returned result list further.) Mimi also used the term "single-attribute view" for filter and "multi-attribute view" to try to explain the concept better.

Brian pointed out that some filters wouldn't make sense for some Item types. For example, "sender=Ducky" might not make any sense for Tasks. Mimi suggested that more detailed drawings would distinguish between "universal" filters (like "Project=Cobra") vs. Kind-specific ones. Perhaps there would be separate sections for each; perhaps Kind-specific ones would be greyed out when they weren't relevant.

Mitch felt pretty strongly that there were a limited number of Views that a user would want; that users were used to Views, and that composing Views out of filters would be too complex for most users. Brian chimed in that he, for one, really wanted to be able to use filters prinicipally instead of Views. Mimi felt that it was premature to say, "users can't do this" because no program right now allows users to do this.

Mimi reiterated that a hierarchical display of Views (like Vista had) ends up being inefficient in mouse-clicks in part because it is redundant. (See ShouldUsersPrimarilyBeInViewModeOrFilterMode for a further expansion of her argument.)

Mitch is in violent agreement that the sidebar shouldn't be cluttered with too many Views, but wondered how important it was for someone to be able to find all the items in a Project (i.e. how often would that happen) and thought it might be too much trouble to make sure that the View was marked up. Mimi asked a clarifying question, and Mitch responded that there needed to be affordances for customizing a View but that didn't need to concern us for the basic navigational landscape. (Editorial note: I had the feeling that he was talking about things in the view for fiddling with the View. For example, in a Calendar Month View, you presumably have a button that says "Next month". We've also talked in the past about having a slider in the view that changes the timespan of the displayed objects. However, I'm not certain of that. His words were somewhat ambiguous, my notes doubly so.)

Summary

Consensus

• Mitch ratified that Canoga will have affordances to assist users with creating different views.
• Mitch ratified that Canoga will have a "Today" view.

Open Issues

• What is a "filter" and what is a "view"?
• Which has primacy: filters or views?

Action Items

• Mitch and Mimi to meet on Tuesday to hash out filters vs. Views.
• Ducky to write up meeting notes.

-- DuckySherwood - 04 Dec 2003