Design Issues Meeting 15 December 2003

Attending: MitchKapor, ChaoLam, MimiYin, DuckySherwood, BrianDouglasSkinner

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

0.3 Release Deliverables

Chao started off by going through the 0.3 deliverables. Projects.ZeroPointThreePlanning#WorkGroups Some of them are mostly done:

• DesignSummary - right now, this has too much detail, but we'll want at least a few paragraphs here
• CaterpillarUI - mostly done, but a few cleanups needed as a result of our last meeting. The Apps group has some feedback, but this is mostly done.
• ItemCollection -- Mitch and John are scheduled to meet (later on 15 Dec) to work out the details
• Butterfly UI - This needs to lay out the Canoga UI and landscape. For each release, this should be much more specific, with concrete deliverables for that release.

Brian asked what the difference between the terms "Butterfly UI" and "Canoga UI" was. Chao explained that he felt that we might need a name for our current snapshot. While "Canoga UI" means our final, end Canoga UI, "Butterfly" is our best guess of what it is. If that distinction isn't needed, he was fine with calling it the "Canoga UI".

Mitch asked what percentage completion target we were establishing for Butterfly in the 0.3 timeframe. He wanted a way to know if we had succeeded. Chao and Mimi are to get together to set expectations for what will be done by 17 February (the current 0.3 release date). Mimi mentioned that she believes the framework will be ready by 0.4, but not the design of every single element. (For example, the page where users set up their email accounts might not be designed by then.) Mimi also pointed out that she'd need a spec for Chandler's functionality in order to know which screens to design.

Brian pointed out that the deliverables doc didn't mention figuring out how to organize the Design section of the wiki, including templates for different kinds of pages. For example, when we have a wiki pages for a tentative feature set for email and one for calendar, those two pages should look similar and be found in similar places. Chao thought that that wasn't a deliverable, but a goal that would make it easier to do our deliverable tasks.

We then went through the other documents listed in ZeroPointThreePlanning#WorkGroups and assigned owners to them:

• DesignSummary - Chao
• Butterfly UI - Mimi, who is to come up with a list of what she needs help on
• Caterpillar UI - Brian
• Canoga Users and Groups - Brian (though this will touch on two of the below items)
• Canoga Sharing Framework - Mitch is going to write up a canonical sharing page (based on the nine different Sharing pages that Brian found), rationalize it, clean it up, and post it.
• Canoga Security - Mitch to draft a short document

Design Map revision

Mimi edited the Design Map in DesignProgram based on our recent discussions. "Generic Information Management" has been replaced by some columns of text:

Navigation Architecture	Collections	Entering items
View types	Static collections	Information design
Filtering	Dynamic collections
Organizing Archetypes	Tightly linked items

Chao thought we should make the diagram clickable.

Mitch felt that while we might need to do a little wordsmithing, that captured the essence of what we'd been talking about.

Mitch proposed reworking the diagram to show, at a high level, "Canoga's Basic UI". Subelements of that seemed to him to be

• Items, Collections, and Capplets -- the basic atoms and molecules of the UI
• Important View types and collection types (e.g. static and dynamic)
• Topography -- chrome, etc.
• Navigation -- URLs, bookmarks, history, and all the other ways you can move around in the topology
• Data entry (David Allen's "Collect" phase)
• User rationale -- the organizing archetypes (e.g. "Collect/Process/Organize/Do")

Mimi noted that "data entry" shouldn't have been in that block -- that entry is orthogonal to the visual design of where things go.

Chao noted that "filters" used to mean "spam filters" and now means something very different. He asked if a terminology list should be an explicit deliverable for 0.3. Ducky asked if Apps had requested it (answer: no) and whether we thought our terminology was stable enough to deliver anything meaningful. There wasn't a firm consensus that we had settled adequately on language. A glossary of terms is mentioned in the DesignSummary, so we won't forget about it.

ZaoBao

Mimi wasn't sure how to tell which feeds were new vs. which feeds had already been read already. As it turns out, RSS articles don't have unique identifiers, so there isn't a good way for RSS aggregators to know what has been seen already. (Your humble scribe made a rude interjection about RSS here.) Thus, we have a question of what to store in our repository and what to treat as ephemeral. If we store every article when we see it, we'll have a lot of redundancy. If we don't store anything, users will lose articles.

Brian pointed out that there are some heuristics we could use to get it right most of the time; Mitch was somewhat concerned that "mostly right" might mean "wrong too often", but also felt that we might be able to advance the state of the art by using and improving those heuristics. However, we decided to defer working on the heuristics. For simplicity, it was decided that by default, RSS articles won't be stored. If a user wants to keep an article, they need to take an explicit action to save it.

Wiki Redesign

At one point in the meeting, we (all of us with laptops in front of us) struggled to find a particular Wiki page, and it was noted that even as familiar as we all are with these pages, we still have a hard time. Mimi noted that the fundamental structure of the Wiki made navigation difficult: that there was no difference between "navigation" and "content", meaning you couldn't have a sidebar for drilldown. While you can see the parents of a page, you can't find its children or siblings easily.

Mitch hoped that navigation would be easier after the grand wiki reorganization. Ducky assured him that that was her intention. She cautioned, however, that in consultation with Brian and Chao, she decided not to hold up the wiki reorg for a reorg of the design area.

The question came up as to how the wiki inheritance hierarchy was built. Mitch was amazed to discover that the parent of a page was determined by which page you created the initial link on.

There was some confusion about one of Mimi's screenshot mockups -- most of us interpreted the summary pane as one-feed-per-line, where she intended (and we wanted) one-article-per-line. She will fix the drawing to make it more clear.

Mimi asked if, in the Date column of the summary pane, she should show the download date or the creation date of the RSS article. Mitch and Chao warned that some feeds don't have good date information. For that matter, Chao pointed out that some don't show the Subject, and some show the creator as an attribute.

Mimi asked if the Who column should be the channel or the contributor. Mitch opined that since very few channels have multiple contributors, it should be the channel.

One of her screenshots showed floating boxes to indicate pop-up menus brought up by right-clicks, which included a way to do grouping. Chao asked if that was how grouping would be done in the future and got a resounding no. One reason for using dialogs is that the widgetry for in-place editing won't be available by 0.3.

Brian asked if there would be affordances for seeing that something was right-clickable, which prompted Mitch to mention that he feels that one of our value-adds will be screenshots annotated with information about what you can do.

Mimi said that Stuart said that he could do grouping, but that she'd be fine with not having grouping in 0.3. We decided to let Stuart see how much he could accomplish.

Mimi then showed the ZaoBao preferences page. Chao asked if a user could set the update time on a per-feed basis; Mimi said no.

Mimi showed another screenshot mockup, this one for showing only one group. It had the first few lines of each article underneath the Who/Subject/Date line. People weren't sure if by 0.3, the blocks would be able to support spanning columns as was shown in the diagram. We decided to let Stuart see what he could come up with.

Usage Patterns

Brian asked if we needed a separate usage patterns deliverable, or whether usage patterns are pervasive. Presumably we'd deliver it to the Apps team -- what would they do with it? This spawned a side conversation on the usage patterns documentation.

Chao suggested starting with DaveAllenUsagePatterns and thought that it was general enough that it was hard to see how it fits in with other stuff. Brian suggested perhaps expressing the tentative feature set in terms of usage patternsChao pointed out that in addition to specific deliverables, the Apps group requested a "big picture" of what's going into Canoga. There might be other ways to organize the "big picture", but Chao thought that they had something like the usage patterns in mind.

There was a discussion about what we should do with the David Allen usage patterns. Mitch felt that it was important to cross-check against them to make sure that Chandler could satify all the use cases, but that we didn't need to organize our thought process around it.

Mimi said that she thought we should come up with different personas, different models of how people interacted with their stuff -- people who filed everything immediately, people who kept everything in a big pile, users who enjoyed creating hierarchy, those who didn't... Mitch firmly believes that people's behaviors are a result of efforts to cope with their stuff given the tools they've traditionally been given. Some strategies are driven by an impedence mismatch between what they want to happen and what the tools make easy to do. He feels that if users give Canoga a chance, they will use its affordances for accomplishing their tasks. Well-intentioned as it might be, he feels it would be maladaptive in some ways to give people tools for doing it the way they've always done.

He also thinks there's a bunch of work to be done on helping people set up their filing system. (Less work is better, but he doesn't think "less" will translate into "none".)

Mimi disagreed that filing was a maladaptive strategy: she said that she filed "because [she] is anal" -- the way she remembers things is by filing them into nice clean buckets. She wondered how much was poor tools and how much was innate. Ducky piped in that she's observed an element of "learned helplessness" -- they learned one way with poor tools; even when given better tools, they stick to their maladaptive behavior because they've spent so long brainwashing themselves that it was the right thing to do.

Mimi made the point that in Chandler, users will be able to organize documents by creating new CPIA Views.

Summary

Consensus

• RSS articles will, by default, not be saved. To save an article, the user needs to perform an explicit "save this" action.
• The summary pane of the "show all RSS feeds" view will show one article per line.
• The Who column of the "show all RSS feeds" view will show the feed name and not the contributor name.

Open Issues

• Will we use the term "Butterfly UI" or "Canoga UI"?

Action Items

• Chao and Mimi to discuss targets for Butterfly for the 0.3 timeframe.
• Unspecified somebody to make the Design Map clickable.
• Mimi is to redo the redone Design Map.
• Brian to come up with guidelines for how to organize our thoughts on the wiki.
• Mimi to redo the ZaoBao summary area for "all feeds" to make it clearer that there is one-article-per-line.

-- DuckySherwood - 16 Dec 2003