Overview: We had our first design review, covering the basic structural elements of Chandler design. Notes below do not cover everything that went on in the meeting (see links under related pages below), but rather concerns and suggestions mainly from Andy and next steps.

Attendees: MimiYin, MitchKapor, AndyHertzfeld, ChaoLam, SheilaMooney

Related Pages: DesignReview20040831, DesignProcess, OrganizeDesign, SidebarSpec, TriageDesign, CreatingNewItemsWorkflow, DetailViewSpec

Andy's comments:

• Rapid-prototyping is the best way to test out new design. Many problems in design can only be teased out through rapid-prototyping or actual implementation. Mitch said in the past he's been resistant to prototyping but now is right time to start this effort
• Conceptual Organizing: We model "done, processing, deferred". Should we also model urgency. Mimi: you can model urgency within the processing section through explicit ordering of the processing items.
• Sidebar and Extensibility. How much thought have we given to extending the sidebar (and other Chandler UI elements) to third-party parcels? Mitch: Plan of record is that
  1. There will be a generic viewer (although not in Kibble) to view heterogeneous content items (some created by third-parties, and non-PIM related)
  2. Third-party parcels can have full control over the sidebar to populate with their own sidebar items.
  • We've intentionally decided to sandbox extensibility at the UI level. This is so that we can focus on Chandler as a immediately usable PIM application. It's a tough choice, but we have to constrain our ambition in the near-term to make forward progress
  • Andy suggests something akin to NeXT's "national small programs" iniative to get individuals inside and outside of OSAF to start developing parcels for Chandler. Mitch observed this is very similar to our "Developer Dog food" initiative
• Sidebar visual cues: Icons next to the sidebar collection text can be useful to demonstrate the states of the collection (e.g. is it being shared? read-only?)
• Visual polish: We need to raise the bar in terms of visual polish for 0.5. Chao: current plan is work off Mimi's ZeroPointFourVisualBugs20040930, see how many bugs are fixed for 0.4, and then assessing remaining issues, decide level of polish for 0.5.
• Summary table fisheye date column: does the fisheye feature buy us anything? It replaces text clutter with whitespace, so it doesn't really save space. Mimi: visual clutter is crucial and it does save some space for "time" (vs. date).
  • Fisheye is much less confusing when items are sorted by date.
  • Are we overloading the date column in too confusing a fashion: e.g. email received date vs. calendar event date vs. task do on date (especially when an item is stamped as multi-kind)
• Summary table kind column: should messages have an email icon? rather than blank?
• Visual design: text icons jar with pictographic icons (prefer icons with text and pictogram)
• Dashboard view: should "done" be at the top (people read top down)? Is "done" in the way?
• Toolbar and menus: Would be nice if "New item" command is context based. So, if calendar filter is turned on, default for New Item should be New Event (and should say so in the menu and tooltip).
• Detail view: Stamping affordance. Are push buttons the right UI? Should be easier to stamp than unstamp. Mimi: But ease of unstamping allows users to experiment with this new stamping concept.
• Detail view: In addition to iconic message history, some users may prefer a textual description of message history. Textual description of message history can even be editor (same UI affordance as having the text of a rule to be edited)

Next Steps and Decisions

• Andy to think about our extensibility strategy and see if there are easy wins (big impact with little work) such as clever menu design.
• Andy to think about Dashboard view layout e.g. optionally hiding done and deferred sections
• Mimi to think about Andy's feedback and revamp her design as necessary
• Chao to work with Mimi on rapid-prototyping plan/proposal.
• Sheila to explicitly specify and track visual polish goals for key UI components starting in 0.5
• Drop fisheye dates to post-kibble

-- ChaoLam - 01 Sep 2004