Design Issues Meeting 11 December 2003

Attending: MitchKapor, AndyHertzfeld, MimiYin, ChaoLam, BrianDouglasSkinner, KatieCappsParlante, JedBurgess, StuartParmenter, DuckySherwood

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

0.3 Release UI ("Caterpillar")

The apps group joined us in large part to find out which pieces of the Caterpillar UI were likely to persist and which were likely to go away.

Mimi said:

• The sidebar, which users can hide, is going to stay.
• Back and forward buttons in the navigation bar probably remains.
• Refresh might remain, but it's unclear as to what "refresh" should mean in the Chandler context.
• Whether or not we'll have a URL box is up in the air.
• The toolbar with shortcut navigation items, with folders and individual views, stays.
• Navigation is up for grabs. She thinks capplet-based trays will remain, but expressed an unwillingness to swear that on her grandmother's grave. It's useful to group views but it's not clear how the views should be grouped. Maybe there will be different sidebar tabs, each with a different set of views, that users can toggle between.
• There will still be a notion of many views having columns in a table armed with certain widgets.
• There are open issues on editable detail views and how they interact with the ubiquitous text entry box.

There was a brief discussion of the meaning of the word "capplet" and how it related to Andy's concept of "context". Mitch said that while that question is in his top tier of things that need attention, that hasn't been completely worked through.

Mimi pointed out that applications and document types have traditionally been tightly coupled: you can't edit a Word file with Excel, for example. In the old world, each application had its own toolbar with its own functions; with hybrid elements like we have in Chandler, what goes in the toolbar becomes an interesting question.

Mitch asked if this level of detail met the expectations of the Apps group. The rough consensus was yes, although they felt that some stuff was still a little fuzzy.

Mitch recognized that trying to integrate Design and Applications' models of the world was tricky and that we were going to have a lot to learn on how to do it. In particular, we'll need to tie together the CPIA into the design after the fact. He feels that there is a high probability of an impedance mismatch. One potential mismatch candidate is the sidebar, where picking two different items in a tray causes the user to see the union in the main pane. We don't know how well that will fit in with CPIA, where each block has an associated query.

Katie is slightly concerned about Collections and how they fit in. She doesn't think it's a large mismatch, but something that the groups will have to deal with.

The Apps group will see how things work, and we will talk more next Thursday, 18 Dec.

Mixed Item View

From there, we went on to discuss mixed item views, looking at this picture from Mimi's 0.3 design page:

In this View, users can select show the union of several sets of Items by dragging a View from the sidebar onto a tab. A consistent set of columns is shown: Who, About, and Date. What goes in those columns changes. For example, "Who" might be the sender of received messages, the receiver of sent messages, the name of the person calling the meeting for a meeting, etc.

If an Item was received, the Who column entry is left-justified. If an Item was sent, the Who column entry is indented.

Andy thought that we might need the Kind of an Item in a column. Icons are fine for now, but when Chandler is extended a lot, there will be enough Kinds that it will be difficult to create visually distinguishable icons for all of them.

Mitch pointed out that somebody needs to determine exactly which attributes of the Content Model map into Who, About, and Date. We drew a preliminary table on the board:

	E	C	T	N
Who	sender/receiver	host/invitees	requester?	author
About	subject	headline	headline	headline
Date	sent or received date	startTime or endTime	Do-on	creation or modification date

Mitch said that a deliverable that needs to be attached to the design proposal is the content model that we want supported.

Mitch also requested that the ContactItem support a nickname attribute and use it in a lot of cases. Katie and Brian assured him that it was already in. Mitch noted that "Who" might be a full email address, a "smart address" (i.e. full name), or a nickname, depending upon how much information was available. He also noted that we'd want "Me" as a nickname. Mimi suggested a WikiWord, and Andy pointed out that there are two issues: you want something shorthand-ish, but you also want to display all that fits.

(Mitch noted this as an example of where things often break down: either one never gets to implementation because people are trying to hard to figure out every conceivable case, or the design is underspecified and engineers have to figure things out and make decisions themselves about the design.)

Andy wondered if Who/About/Date were the best columns: maybe Status and Project would be good. Mitch answered that there was no one-size-fits-all solution: there needs to be a way for people to customize Views, but they need some template Views to start out with. He also pointed out that Who/About/Date were all filled in by Chandler, not the user. As Mimi analogized, Who/About/Date describe the animal but Status and Project dress it. Brian suggested that Collection might be another interesting category.

A clarification: to merge views, the user would drag a tray from the sidebar onto a tab, not drag one tab onto another.

Mitch asked how the user would indicate that a View was to be mixed. Mimi answered that all Views could be mixed Views. Mitch indicated that there was an issue about managing collections. Do some collections have immune systems with antibodies that prevent other Items from intruding upon them?

I believe Chao asked about sidebar selecting and mixing, whether that was a way to make heterogeneous views. Mitch replied that that might be asking the Caterpillar to do too much.

Andy thought that the trays in the sidebar should be indented with respect to the category. (For example, In and Outshould be untented relative to Mail.) He's also suggest a click affordance like a disclosure triangle so that users would know to click there. Mimi responded that she hasn't done a careful visual design, just layout. As Andy questioned the distinction, Katie interjected that the sidebar would likely be implemented with the tree widget, and hence would have a disclosure element. Andy noted that he prefers triangles to boxed plus/minus signs; Katie said that we could spend cycles on it to make it prettier later. Because the sidebar is a "tarpaulin", we will minimize effort on it, but iterate from there.

Mitch noted that in the mixed View, depending upon which row was selected, the headers could dynamically change. For example, if an email message were selected, Who/About/Date could change to From/Subject/Date. Mimi suggested that it could change to Who (From)/About (Subject)/Date.

Katie requested that sooner, rather than later, Mimi provide them with designs for creation-with-attributes, e.g. create a Calendar Event with a date. Andy suggested a menu option for generating 25 random items. Katie assured him that they would definitely have a generate-random-items feature, including incoming and outgoing email. Mimi interjected that Tasks were In and Out as well.

Mitch put some brakes on. He wondered about the distinction between tasks received and sent, sharing, collaboration, and delegation... He believes that users should be able to create a task and send it to someone else, but draws the line there. The next step -- where users would assign tasks, accept, reject, convey completed status, etc -- are too complex for Canoga. (People can, as always, do "out of band" agreements of tasks.) In that case, there is much less of a distinction between Tasks you make yourself and ones you receive.

Mimi asked if we would distinguish between who requested a Task and who was owed a task. Katie said that it wasn't a must-have, but would be nice.

(Side note: at one point, someone asked about note creation, visible also in ZeroPointThreeUI. The idea is that users would select New Note from a menu, and just start typing in the Detail View to get plain text. The title would come from the first line.)

ZaoBao and Agents

Stuart had some questions about what the UI for ZaoBao and the agents should look like.

Stuart drew a picture of his view of what ZaoBao might look like. It looked very much like Mimi's other Caterpillar drawings, with a summary View on top of a detail View, with a sidebar listing all the feeds. He wasn't sure how Feeds would fit in -- maybe they were sort of like different email servers, but maybe not.

Brian suggested that maybe ZaoBao would be a tray with a View for each folder. Andy pointed out that it was analogous to multiple calendars. Mimi promised to draw up some sketches, and we moved on.

Mitch noted that he thought the RSS aggregator netnewswire was nice.

Stuart asked where the visualization of the agent should live: was it View specific? Capplet specific? And what piece of screen real estate did it live in? Some agents are always running -- is it always visible? Andy said that there were several alternatives: the value of visible agents is the status of ongoing activity, so they must always be visible. There could be an "agent toolbar" that users can hide. This brought up a brief discussion of Contexts, with the decision that Mitch and Mimi would go off and make a proposal for Contexts.

Mimi asked for a spec of what the agent would be doing; Andy cautioned her about being too specific: that any solution she came up with would have to work for agents in general.

Stuart also asked about dialogs: the easiest thing would be for the user to click on an agent and get a dialog box with the state of the agent -- but he wasn't sure if dialogs were verboten. Andy said that dialogs would be best because it would maintain state. Mimi pointed out that the Back and Forward buttons saved state. Andy thought that it would be a big change to navigate away. (Andy expressed a desire for a View for managing all of the agents, but noted that's a separate issue.)

Katie suggested that using a dialog for 0.3 freed us from having to have that CPIA element ready for 0.3. Andy didn't view it as a compromise. Mimi suggests that in the future, we'll be able to dock pieces of the UI in different places.

Stuart asked who managed the list of feeds: did the user add and remove feeds directly, or did the user ask the agent to add and remove the feeds? Andy pointed out that while it would be expedient for the user to manage the feed directly, it would develop the agent framework more if the agent were an intermediary. Stuart asked which was most appropriate long-term, and Andy felt that agent-mediated was.

Katie suggested that Stuart and Mimi confer, that Mimi get a proposal to Stuart et al by the 17th, and that Stuart would in turn generate a timeline.

Extensions to Caterpillar UI

Mimi went over the two pictures in PPFInformationDesign of the Generic Viewer.

She noted that there's a difference in EASability (easy to learn) and USability (easy to use). Frequently, USability is sacrificed for EASability in designs. However, power users need USability -- people would be willing to spend a few minutes figuring out how to use a program if there were the promise of big time savings later.

Mimi also noted that most people are tripped up by booleans (AND and OR) in searches.

The Generic Viewer is organized by time. This is not meant to be the end-all way to see things -- user-generated collections will be much more helpful. However, especially if you're entering proto-items, time is the only attribute that gives you a continuous narrative. Time is also the easiest axis to construct, and is a familiar way of organizing.

Note that a quick query resolves itself into the URL that is more human-readable than a regular URL.

On the time View, it doesn't show down to the minute because people really don't usually need to know the exact time when something arrived. For a summary view, the order is enough most of the time. Note that the timeline is dynamic: it changes to coarser- and finer-granularity depending upon how many items there are in a time range. On Monday in the example, there are a lot of Items, so it's expanded out.

There is a tick to separate morning and afternoon, as that's a division that people frequently remember.

For calendar events that have a start time and an end time, there are brackets around the start and end time, e.g. [2-4] for tonyb@parliment.gov.uk's message.

To the right of the timeline are icons representing Item type. No icon means it's an email message; checkboxes next to email messages mean that the message has a followup task. A filled-in item denotes the time of an event; an unfilled item denotes a reminder for an event.

The small numbers in parentheses indicate how many people are involved.

At the bottom is a text entry interface with prompts and hints for shortcuts for tagging language.

If you click on a day in the calendar browser, you'll go to that day. If you select an entire week or month, then you'd see all the Items for that time period.

Chao asked if there should be a vertical scrollbar. Mimi said yes, that she was purely doing information design. Andy asked what the distinction between information design and visual design was. Mimi responded that she was separating them almost like you'd separate for print. (Editor's note: no, I didn't understand that either.@@@)

Andy asked if you could only sort by date in the Generic Viewer. Mimi wasn't sure. We could resort with an abbreviated timestamp. Maybe if the user wants to sort by a column, they would drag the column to the left. Mimi also suggested looking at IBM's Remail mockups, where they group by name or by subject.

Mitch asked about the "X" and "U" in the URL bar. Mimi said those represented "cross" and "union". There was some feeling in the room that those would be even less understandable to lay users than "AND" and "OR".

Mitch noted that there are a large number of interesting ideas here. He could imagine using this view when searching against all items in the universe. There's a question of what's the difference between structuring a View to show everything and one showing just what the user needs to manage today. In the Today View, if the user reads a message and there is no further action, it should be easy to get rid of the message.

Mitch feels that the non-uniform timeline is nice, sort of like a fisheye lens. He likes the sophisticated iconography (and is absolutely convinced that if more products had screenshots with callouts explaining everything, that people would be way more productive).

Mitch asked what it would take to make Chandler's typography look as good as Mimi's mockups. Katie answered "money, time.." and there was much laughter. Jed explained that on the Mac, Cocoa libraries were better than Carbon libraries, but that wxWindows had been done with Carbon.

Summary

Consensus

• Clicking on an agent will bring up a dialog for 0.3.

Open Issues

• How do detail views interact with the ubiquitous text entry box?
• How do users create/edit views?
• What goes on the sidebar past 0.3? How is it organized?
• Will we have a URL box past 0.3?
• Past 0.3, will an Item's Kind be listed in the summary view line for that Item?
• Are the Caterpillar Views customizable?
• Past 0.3, what are the appropriate columns for a mixed view? Project? Status? Collection?
• Where does the representation of an agent's status live?
• In the Generic Viewer, can the user sort by anything besides Date?

Action Items

• Mitch to work on which attributes map to which Who/About/Date columns.
• Stuart, Mich, and Mimi to meet Friday at 2 PM to discuss ZaoBao. Mimi to then make some sketches of ZaoBao by 17 Dec.
• Mitch and Mimi to come up with a proposal for Contexts.

-- DuckySherwood - 11 Dec 2003