Design Issues Meeting 9 December 2003

Attending: MitchKapor, ChaoLam, BrianDouglasSkinner, DuckySherwood

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

There was a meeting with Katie and representing the Apps group. They would like to have

1. more hands-on concrete material on features, interaction design, etc.
2. a bigger picture of where things stand: what's in Canoga, where are we going, etc.

Capplet Inventory

Following Chao's lead of the design map, Mitch wanted to talk about the inventory of capplets. The design map seems to show Email, Task, Calendar, and Notes as separate entities, but much of the Design Group's work has been focused on "generic information management" -- allowing users to view and manipulate multiple different types of Item at once.

Brian noted that the "Caterpillar" UI has individual capplets for E/T/C/N. Mitch said not to read too much into the Caterpillar design. As an analogy, he said that when you're building a house, working on the inside and outside simultaneously, you put a tarpaulin on the top of the house to keep it dry until the roof goes on. However, nobody should ever think that the tarpaulin is what the final roof is going to look like. The Caterpillar UI is like a tarpaulin -- it's something that we need right now but that it shouldn't be mistaken for the final UI.

What's in the sidebar, how the views are organized in the sidebar, what Views are going to be in Canoga "out of the box" -- those are all still up for grabs.

(Brian pointed out that even if the UI was the same for all E/T/C/N Items, the development team would still need to compartmentalize them some: email messages are fundamentally different from calendar events under the sheets because of e.g. the different formats given by different specs. Mitch recognized that, but was concerned with what the UI level only.

Mitch also mentioned that we're using terms (e.g. "capplet") slightly differently when talking about implementation and UI design. Like Humpty Dumpty in Through the Looking Glass, he wants to go ahead and use terms as to mean what he wants now, recognizing that there will need to be a Grand Reconciliation later. Brian was fine with that, and thought that in the end, the user vocabulary should trump engineering's vocabulary. Mitch pointed out that engineering reality trumps design desires, however. There was much laughter. (Okay, I guess you had to be there.))

Mitch asked Brian for a definition of "parcel". Brian took a deep breath, gave a disclaimer, and then gave a long and beautiful definition of a parcel that included phrases like "an end-user bunch of functionality that includes Views (or CPIA documents)", "some notion that the capplet as a whole can be installed", and "can register". Alas, he spoke long enough without enough hesitations for me to be unable to record the entire sentence in its full glory. (@@@ get him to try to reconstruct it, and/or point me to a definition elsewhere)

It was clear that a "parcel" is a unit that can be installed, replaced, or removed. The question naturally followed as to whether E/T/C/N/Ct (Email/Task/Calendar/Note/Contact functions) were separate parcels or one monolithic parcel.

Brian mentioned that being able to add parcels is easy, but that being able to swap out core (i.e. PIM) functions was difficult. He registered the opinion that if it wasn't necessary, we shouldn't spend a lot of effort trying to make core functions swappable.

Could someone swap out e.g. our Task parcel, replacing it with one of their own? After some head-scratching, we came to the consensus that no, there will be one monolithic PIM parcel that contains all the E/T/C/N/Ct functionality . These were some of the supporting arguments:

• E/T/C/N/Ct functions have very tightly integrated interoperability requirements.
• Even if the PIM capplet is monolithic, there is still a huge amount of flexibility for people to extend functionality. People can add complementary parcels that extend the core functionality, write agents, scripts, make CPIA Views, etc.
• We could perhaps add swappability later. (Editor's note: this was implied but not stated explicitly.)

It wasn't clear whether IM should live in the monolithic PIM capplet but probably not. IM might be a separate parcel that, if installed, makes the PIM capplet more useful.

Epistemology Thoughts

Chao asked if it would be a productive time to should shift our focus from cross-domain areas (e.g. generic navigational landscape) back to domain-specific (e.g. Email) features. This led to an evaluation of what we knew and what we didn't know.

Mitch wrote a list on the board. Things that we'd discussed enough that we thought we were "more done" with were at the top of the list; things that we thought were "less done" were at the bottom of the list.

• Caterpillar UI
• recognizers
• security
• sharing and collaboration
• agents
• users and groups
• collections, views
• IM
• search
• CPIA affordances in Canoga

Mitch also made a list of things we hadn't discussed:

• users changing the content model (what we used to call "schema evolution")
• generic information management -- superwidgets
• RSS feeds
• agent builder affordances
• View types
• filters

As part of the set of things we hadn't discussed about RSS, Mitch mentioned that IBM's "Remail" prototype could route stuff from RSS directly into the email inbox, and that he thought that was an idea worth looking into.

For View types, Mitch pointed out that Mimi's designs so far have a notion of these types of Views:

• list
• detail
• table
• calendar
• "Today"

However, we haven't talked about what e.g. the table view will do. Will it support widgets? Outlines? Pivot tables?

Chao asked if there were any open data model issues (not content model issues). Brian said that he hoped that there were no outstanding data model issues that the Design team needed to worry about.

Usage Patterns

Chao moved on to agenda item #2, where we discussed DaveAllenUsagePatterns. Chao wanted to know if people agreed with the document (and strategy), if there were other things that the document didn't capture, and what affordances would map into which patterns.

Mitch asked if it was an exhaustive list. Chao and Ducky replied that completeness at a categorical level was the goal. Mitch pointed out a few tasks missing from Collect (enter notes, RSS items, and "anything Canoga can receive in the future from future plug-ins") that your humble scribe added during the discussion.

There was a brief discussion of delegation. Mitch felt that we were probably going to have to forgo "in-band" delegation in Canoga. By "in-band", he meant through a formal process facilitated by Chandler. (This is in contrast to "out-of-band", where the delegation would be more ad-hoc and could happen through communications channels other than Chandler. For example, Margot might send Pat email requesting him to send Michelle the Fromblester report. Even though Chandler would have no way of understanding that a Task should be created here, Margot and Pat would both understand that Margot had delegated the task to Pat.)

Brian asked why we were looking at organizing around David Allen's workflows. Chao said that the hope was to give ourselves (and others) a picture of what Canoga is going to do. Brian said that he was concerned about having yet another orthogonal axis for organizing wiki pages along. He was concerned that we'd eventually have huge long lists of all "this is in, this is out". He'd like to organize our thoughts such that each feature was only listed once in our master plan. Chao assured him that these pages were meant to be at a relatively coarse granularity.

Brian expressed a wish for a better tool for keeping track of features, and we jokingly invoked Morgen's name (since he recently "threw together" a status tracking tool that we all quite like).

Mitch thought that the basic categories on DaveAllenUsagePatterns were correct, that the sub-bullets fit well -- but wasn't sure if it was complete or not. He also didn't think that we needed to settle that issue now. He also thought that David Allen's process was a bit fuzzier, a bit more abstract, than was needed to design a piece of software.

Mitch believes that there will be things in Chandler that fall outside David Allen's usage patterns. We're not going to do only things that fall under his scheme.

• Sharing and collaboration don't fit anywhere in his scheme. (David Allen presumes that people are working in splendid isolation, not continuously connected to one's colleagues.)
• David Allen doesn't devote much attention to prioritization. In his scheme, prioritization is a fuzzy, intuitive thing. We should strive to give Chandler affordances for helping users prioritize.
• Annotation and creating a historical record are both useful affordances.

Browser

Mitch would like to schedule a thought experiment about connecting Chandler to a browser: what affordances could we/should we put into Chandler to make it friendly to someone wanting to plug a browser in, and what advice would we give him/her/them?" How could we make it possible, how might it appear to the user, etc.

Brian mentioned that Mac OS X has a way for an application to advertise its services, and Chandler could perhaps do something similar. (There was rough consensus that that feature wasn't hugely compelling.)

Next meeting

In the next meeting, Chao would like to talk about the ZaoBao design and Caterpillar enhancements.

Summary

Consensus

• There will be a monolithic PIM parcel incorporating the core PIM functionality. We will not invest any energy in Canoga cowards making it easy to swap out one piece (i.e. Email), replacing it with a different version.

Open Issues

• What will the final UI look like?
• What pieces from Caterpillar are known to be "tarpaulin" (throw-away) vs. roof (keep)?
• What pieces of CPIA should be exposed to users?
• What are the fundamental View types (blocks?) that can be used to create Views?
• How does delegation work?
• What is missing from DaveAllenUsagePatterns?
• What affordances (if any) will Chandler have to help people prioritize?
• What affordances (if any) will Chandler have to help people create a historical record?

Action Items

• Mitch to rewrite ItemCollection.
• Undetermined someone to replace "generic information management" on the design map with "view types". (Mitch suggestion.)
• Ducky, working with Brian, to connect all the pieces of the design map to wiki pages that talk about that piece. (Note: there

were some suggestions about implementation details, but those probably aren't interesting.)

• Everyone to think more about what's missing from DaveAllenUsagePatterns and to give feedback to Chao and/or Ducky.
• Chao and/or Ducky to update DaveAllenUsagePatterns based on feedback.

-- DuckySherwood - 08 Dec 2003