Views Meeting 30 October 2003
Mitch, Andy Hertzfeld, Chao, Mimi, Ducky, and Brian in attendance.
Icons in
One set of diagrams that got some discussion was three lists that that Mimi drew. I will reproduce in a three-column table, with dashes representing summary entries in the table (e.g. Subject lines for email messages):
| E | T | C |
--------------------------- | ---------------------- | ---------------------- |
--------------------------- | --------------------------- | ----------------- |
---------------------- | ----------------- | ----------------------- |
----------------- | --------------------------- | --------------------------- |
--------------------------- | ---------------------- | --------------------------- |
----------------------- | --------------------------- | --------------------- |
--------------------- | ----------------------- | --------------------------- |
--------------------------- | ----------------- | ----------------- |
---------------------- | --------------------- | --------------------------- |
----------------- | --------------------------- | ---------------------- |
Each View above only shows one type of Item, and the icons show what links that Item has. (I think I remember that she had subcolumns which showed how many links of each type (E/T/C/N) there were, but my notes don't reflect that.
The items can have a number of links, which can be confusing.
Andy pointed out that it was redundant and possibly confusing to show the icon for what the item
was, in addition to what it was
linked to. So instead, something like:
| E | T | C |
| --------------------------- | ---------------------- | ---------------------- |
| --------------------------- | --------------------------- | ----------------- |
---------------------- | ----------------- | ----------------------- |
----------------- | --------------------------- | --------------------------- |
| --------------------------- | ---------------------- | --------------------------- |
----------------------- | --------------------------- | --------------------- |
--------------------- | ----------------------- | --------------------------- |
| --------------------------- | ----------------- | ----------------- |
---------------------- | --------------------- | --------------------------- |
----------------- | --------------------------- | ---------------------- |
(Andy was also concerned about the "Task" icon itself being confusing, but was assured that the current icon is just a placeholder.)
Andy wanted to see a summary of the related item; Mimi explained that she envisioned a "threshold" meter that would allow the user to see more or less detail. Mitch mused that there were interesting questions about levels of detail shown, and observed that we needed a visual vocabulary.
Some more discussion ensued, and at one point Mitch summarized by saying that it was clear to him that there was strong agreement that if an Item was in a linked View, it was fundamentally important that there be different [types of?] linked items, and to be able to navigate to the other items from there.
There was some discussion of paths. I think the icons represent not whether there is a strong link or not, but what "path" the item took during its life: if a Task was created from an email message, then the Task would have an Email icon in its summary. Weak "FYI" links would not be noted by icons.
Clustering
That then brought us to a relatively long discussion about clustering. Mitch made the observation that we can't have a complete discussion without saying that an equally fundamental display technique is to cluster sets of related items. We'll want Chandler to automatically cluster items, e.g. creating a task from an email message should put it into the email's thread. Threading/clustering should be a pervasive feature -- available in in any tabular view.
Thread View User goals:
- hide/show detail without losing context
- unit = any collection of linked items
- E - thread/thrask
- T - thread/thrask
- C - recurring meetings
- in any view, want to be able to see {the cluster itself}, {what items are in the cluster}, of {the items themselves}
- create a new cluster
There was some discussion of sorting vs. threading and Projects vs. thrasks. There was a sense that Projects and thrasks were different things, but if there was a clear definition of the distinction, I missed it.
Some discussion ensued of separating E and T views (with the understanding that C views were handled pretty well by the Calendar). There seemed to be consensus that in the Email view, other item types might appear if and only if they were in a cluster headed by an email message.
There was some confusion stemming from ambiguity in the term "generic viewer". Mitch and Andy were using "generic viewer" to be something that could view just about anything in the repository, while Mimi had been using it to mean something that only showed E/T/C/N items.
There was a desire for a place to make "unformed items" -- a place to write stuff down before classifying it. There was some discussion of whether or not Notes would work for "unclassified" things.
Open issues:
- Can Notes work as "unclassified" things?
Deferred issues:
- levels of detail in a summary view
- groups and subgroups
- whether threads/clusters should be flat or hierarchical
- whether Contacts should be terminal nodes in a thread/cluster or not (i.e. does a cluster show items that a Contact links to?)
- how exactly to enter information/create info items
Action items:
- Mimi to generate a set of questions for us to think about
- Chao and Mimi to prep agendas of meetings
- Ducky to post notes of this meeting
- Chao to coordinate regular frequent meetings
--
DuckySherwood - 31 Oct 2003