Design Issues Meeting 18 December 2003

Attending: MitchKapor, ChaoLam, MimiYin, BrianDouglasSkinner, KatieCappsParlante, JohnAnderson, JedBurgess, plus two visitors.

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

Caterpillar Questions

The Apps group joined the Design group to go through CaterpillarQuestions20031216. (Editor's note: Katie has updated that document to reflect many of the decisions made, so I will focus on discussion.)

There was a discussion about the proper way to add columns. We could duplicate how it's done in Excel, where you click on a column, then select a menu item to add a new column. Whatever we do, John said, it would be nice if it were easily discoverable. Mitch said that we did not need to worry about a final solution now: the "insultingly stupid" way of selecting attributes from a menu is probably okay for now.

The question of which attributes could be be displayed came up; Katie replied that Design already gave them a list. She observed that homogenous views were easy: just use the attributes. Heterogenous views were harder.

Jed and Mimi had a conversation about fine-tuning features in the UI: should buttons be raised or not here, what background color there, etc. We decided pretty quickly that this meeting was not the appropriate place for such detailed questions. Instead, Mimi and Jed should get in a tight little feedback loop of their own and negotiate based on what Mimi wants and what Jed can deliver.

As a side note in the Jed/Mimi fine-tuning discussion, John mentioned that we don't know if wxWindows 2.5 will have alpha channel or PNG, but Mitch pointed out that we didn't need to spend any cycles on that in this meeting, since we wouldn't move to wxWindows 2.5 until after the 0.3 release.

John noted that in a perfect world, a refresh button wouldn't be necessary because everything would always be up-to-date, but we have to live with the realities of asynchronous communication -- checking email, viewing shared documents, etc. We need to have a refresh button but try to make its use infrequent. Mimi thought it should perhaps be less visually prominent.

Katie voiced concern about drag and drop. Jed amplified by saying that we could allow users to drag from many places (e.g. bookmark, sidebar, main window) to many places, and we needed to figure out what we want to support. (Mitch wondered why drag and drop was at all iffy, and Katie pointed out that they'd need to add it to CPIA. Oh.) Mimi said that the most important thing was to be able to drag and item onto a tab. The complete discussion of drag and drop was deferred as out of scope for 0.3.

There was a question of whether URLs could be parameterized. Mitch observed that there were two ideas fighting with each other. The idea of a persistent URL being a place was long-standing (and in Vista, for example). Command-clicking to create a new query/view is a newer idea that has meritious aspects. It's also unclear at this point how View construction will be done. Given that, he favors the former approach, killing parameterized URLs.

Katie asked if you command-clicked to create a union of two views, was that a new View or a change to the current View. John asked where forward and backward took you. Mimi's instinct was that it was a new View, but that meant that the URL needed to have a new value. Mitch moved to defer this discussion, but Katie pointed out that she thought one reason unioning views was wanted for 0.3 was to try it out and see how it worked. She also pointed out that this question didn't need to get resolved by the next milestone, but that it was coming up.

There was some question about the exact syntax of URLs, but Mimi pointed out that we might want more human-friendly "URLs" anyway. While that wouldn't change what happened "under the hood", she didn't feel it was appropriate to worry about users getting confused by question marks, ampersands, and equals signs.

John pointed out that there are a few platform-specific menu changes: Quit vs. Exit and Delete vs. Clear, for example. Chao felt that "do the right thing for the platform" was the appropriate way to implement things; the documentation will be updated to reflect the shared consensus.

(Everybody from the Apps group except Katie left at this point.)

Organizing Design Artifacts

Chao then talked about the issues in how to organize documents that the Design team comes up with. The consumers of those documents include the Design team itself, the Apps group, QA, and the community. Chao wants to come up with a template that we can work with, not a detailed proposal.

Brian summarized FilingDesignArtifacts200312^?. There are numerous types of documents in numerous formats that we produce that numerous people use for numerous reasons. There's also the question of whether the documents only discuss differences/additions from the last milestone, or should the documents attempt to capture the entire sweep of all decisions ever made? Katie said that getting only the "deltas" would be easier for them than larger documents.

Mitch felt that Product Management owns the task of developing these artifacts based on input from other people, but emphasized that we should use a commonsense approach. He suggested using a "just-in-time" approach to developing artifact procedure: we should figure out the next type of artifact based on the next practical undertaking that we haven't figured out yet (like Sharing). Chao suggested that at each milestone we work on deltas, and at each dot release we spend some time to document the big picture. (Chao also pointed out that Design needs to stay a few milestones ahead of Apps.) Katie thought that it would be good to experiment for a while and see how well documenting at the milestone level worked.

There was a discussion about having a glossary with pointers to pages with detailed decisions.

(At this point, Katie left.)

Notes Design

We did a quick walkthrough of NotesSummarizedFeatureList^?. (Mention was made that there is also a NotesDetailedFeatureList^? page with a slightly different format, and that Notes was an excellent example of the need for standardization.)

It was decided that Notes could be linked to other Notes, but not "contained" inside each other. This meant that you couldn't drag a Note onto another to incorporate it. With Views, however, you can presumably create an outline view that contains a lot of little notes and get essentially the same effect.

Chao asked if Notes were plain text or HTML. Mitch thought we should support some level of rich text, but it's not clear to what level.

Every time a user sends a Note via email, Mimi thinks that the message should show a link to the Note. Mitch said that it should be treated like any other attachment. As a result of some confusion in that discussion, Mitch asked for a ban on the term "strong link".

Mitch had to leave abruptly at this point to go to a phone meeting, and the meeting dissolved.

Summary

Mitch made the observation that this was a historical milestone: the UI team and the Apps team negotiating about what would get implemented. (Editor's note: it felt like a notably productive meeting to me!)

Consensus

• There is a level of detailed design that the whole group does not need to be involved in.
• We will not have parameterized URLs.
• The Design group will provide documentation to the Apps group in milestone-sized chunks.
• Notes cannot contain other notes.
• From a design perspective, there is no limit on Note length.
• There will be no custom filing of notes beyond filing that you can do with any item.

Open Issues

• The behavior of the stop/refresh button and its location are undetermined.
• What things can be dragged from where to where?
• What is the process for Design to deliver docs to Apps? What level of detail do they have? For exah area, is there one document per release or one document that is continuously updated?
• Does making a union of two views create a new View or is it a modification of the current View?
• Does the URL path reflect the directory hierarchy of code?
• When linking items, what is the linking locus?
• What are the display affordances for showing linked items?
• How does the user customize the PPF View?
• What are the attributes of the Content Model?

Action Items

• Design group to use sharing as a test bed for thinking about which artifacts need to be delivered.
• Brian to come up with new terms for "strong link" and rewrite the NotesSummarizedFeatureList^? page to use the new names.

-- DuckySherwood - 20 Dec 2003