Design Issues Meeting 8 December 2003

Attending: MitchKapor, BrianDouglasSkinner, ChaoLam, DuckySherwood, MimiYin (later)

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

ItemCollection

Mitch presented his ideas for ItemCollection. He felt that he didn't have everything completely worked out, but that he was done enough to present it.

(Editor's note: Mitch has since updated ItemCollection based in part on this meeting.)

(He noted that he stumbled across some Longhorn documents and was struck by how spookily similar our parallel development was, down to the same terminology for "Item".)

Mitch recognized a need for a term to distinguish static collections from dynamic collections in the user space, and proposed "visible attribute". While presumably everything will run off of attributes "under the hood", there would be a limited set that would be visible to the user for static collections.

Mitch pointed to iTunes: that in the Get Info dialog box, there are a number of attributes that the user can edit, but presumably there are many more "housekeeping" things that aren't made visible.

Static collections are easy to manage and are the basic usage style that users are familiar with. Mitch believes that queries (which underlie dynamic collections) are hard for average users to grok, but that Chandler will be underpowered if we don't have facilities for dynamic queries.

Example: Inbox will be a static collection. When a message comes in, the program will stick the message in the Inbox collection. It will work just like people know and expect. Sent mail would also be a static collection.

(Note that putting an Item into a static collection can be program-initiated (as with Inbox), user-initiated, or agent-initiated.)

Here's a table that Mimi and Mitch drew that delineates the differences between static and dynamic collections:

type	static	dynamic
metaphor	like playlist	like iTune's "smart playlist"
visibility	Playlist name is not visible in Item detail View	Common attribute is visible
drag&drop	can drag and drop an item into a collection to make it a member	cannot drag and drop
edit attributes	cannot add an item by editing attribute	can add an item to by editing attribute
find fellow members	cannot find fellow members of playlist from member	can
order	has order independent of attribute sorting	doesn't have independent order

Clarification: for order, this means, for example, that a user could elect to order Items (Fred, Bonnie, Wilma, Mabel, ...) in a static collection. However, for a dynamic collection, the only way to sort would be based on the sort order of one of the attributes in the collection, e.g. "sorted by age" or "sorted by first letter of last name".

Mitch thinks that we might be able to relax some of the restrictions -- that users could perhaps drag and drop Items into dynamic collections and maybe dynamic collections can have an independent ordering.

(Mimi joined the meeting at about this point.)

Collections vs. Projects

Brian suggested that Collections and Projects were not all that different, and so perhaps Projects could be used for Collections. Brian argued that membership in a Collection was something that didn't want to be on an attribute basis: if you had Item A and Item B both in your "stuff" collection, you didn't want to have Item A and Item B each with an attribute "stuff" attached to to them because then it would be a real pain to change the name of "stuff" to e.g. "StuffForMyMotherInLaw". Instead, Brian argued that it was more reasonable to have a Item "stuff" that pointed to Item A and Item B, and (because of bidirectional references) that A and B would point to.

Mitch didn't like that idea. Waving my hands and summarizing dramatically, I believe he was concerned that the interface be separate and distinct for static and dynamic collections, and he was concerned that the user interface would smear if the same mechanism was used for both Collections and Projects.

Editor's note: one difference between projects and collections in Mitch's mind that was not exactly explicitly called out is that of hierarchy. If I understood it correctly, static collections do not have parents or sub-collections. Projects, however, must live in the user's Project hierarchy. I believe that he was concerned that if the same mechanism was used for Projects and Collections, that people would have to spend some effort figuring out where in the project hierarchy it should go.

Sharing

Mitch has modified his opinion. He now feels that what can be shared is either an item or a collection. He thinks that people shouldn't have to go to the overhead of putting an item into a collection in order to share it.

He can imagine a View called "shared stuff" -- a summary View with one row for each shared entity, saying what it is (Item or Collection), its name, who's subscribed, etc.

Chao asked if it will be possible to mark individual attributes in Items (note: not Kind) as private. Mitch felt that users should be able to mark attributes private but that that privacy would apply to any scope where the Item was shared. You wouldn't be able to mark the phone number as not visible when sharing to Joe and visible when sharing to Wilma.

Mimi mentioned that Collection is the top level meme, with Inbox, Calendar, etc all being Collections. She also has a model of an "Unclassified" Collection: when someone makes an Item but doesn't file it, it by default goes into a distinguished Collection named something like "Unclassified". Users can then View that Collection like any other Collection -- which ensures that their Item won't "get lost".

"Rich Text Notes"

Brian and Mimi discussed some of the UI for viewing Collections and/or Notes (as proto-Items). When viewing a Collection (i.e. a list of Items in a Collection), Mimi would like to be able to

• change the order of Items in the list
• indent items in the list (i.e. change the hierarchy)
• label the Items

However, she does not feel the need to put arbitrary text anywhere.

She does, however, want to be able to take text from a Note and turn it into a collection, even if there is non-collection text mixed into the note. Having the Item embedded in the Note would be tricky. Perhaps the whole thing -- including the text pieces -- would turn into a Collection, and a summary View would be shown. Mitch said this was not a Canoga feature.

(We all agreed that we thought rich text with bold, underscore, italics, etc. was completely feasible and likely. The area of doubt concerned embedding Items into this "rich text"-ish view.)

Polymorphism

Chao asked if the polymorphism topic was dead. Mimi said she still needed to do some sketches. Mimi wants to see the Item and its related Items in the same View, but we don't need polymorphism for that. We could just show the links. There was quite a bit of discussion as to whether there were "priviliged" /"strong" links or not. Brian said that in the Content Model (formerly the "PIM schema"), there was an optional field for pointing at a Task/Event Item, and that seemed like a reasonable solution.

Summary

Consensus

• The name of a collection should live in an Item separate from each of the Items in the collection so that renames are easy.
• Both Collections and individual Items can be shared.
• Collections can be hierarchical.
• Embedding Items in Notes is not a Canoga feature.
• "Polymorphism" is not needed. Events and Tasks are a unified Kind, and the Email Kind has a field for a pointer to an Event/Task.

Open Issues

• Are there user-visible "hybrid" collections and what role do they play?
• Can you drag and drop items into a dynamic collection?
• Can dynamic collections have an ordering independent of attribute sort order?
• Can Notes display Items inline?

Action Items

• Ducky to write up meeting notes
• Mitch and Mimi to figure out affordances for creating and manipulating collections.
• Mitch and Mimi to figure out how (and if) users can turn a Note with extra text into a Collection.
• Mimi to do some polymorphism sketches.

-- DuckySherwood - 08 Dec 2003