Design List summary for October 30-November 5, 2006

New Threads

Jared sent out the latest hosted service update.

Dan sent feedback that he finds the Triage button in the toolbar confusing and didn't really understand what it did. He suggested changing the text to "Sort Triage" or "Resort" might make more sense. He also suggested that clicking on the column header might be more intuitive than having the button.

• Mimi thought using the column header to resort was a good suggestion but wondered if people would discover this feature. Clicking on the column header is simply supposed to flip the sort order.
• Jeffrey pointed out the the button behavior was really different than simply resorting. The users has made a bunch of changes and is now ready to "commit" them. A bunch of different things happen, the items shift to a different section, things move to the top of the NOW section. It's about refocusing your attention. Jeffrey also suggested that if we greyed out the button when there was nothing left to purge/reorder/commit, it might make more sense.

Mimi replied to mail BCM sent to the Cosmo list which detailed the 0.6 casual collaborator functional requirements.

• The previous week, we had a design session with the Cosmo team to review the storyboards for how casual collaborators will use the clickable URLs to view calendars using the Cosmo UI. This was followed up with a detailed breakdown of development tasks from BCM.
• Mimi responded to BCM with a suggestion that we cut 2 features that were discussed in the meeting. Both of these features relate to notion of "temporary" subscriptions. A temporary subscription would get created when a user "previews" a collection (by clicking on the URL) but hasn't yet officially subscribed to it. This would allow people to login and see their subscriptions and also see the collections that they have "previewed".
• Although a neat feature, Mimi and Priscilla ran into a bunch of snags when they went off and started working on the more detailed visual design. This got very complicated and we decided that it really wasn't necessary for Preview.
• Getting rid of this had some consequences for the design and we needed to make a couple of changes to our original proposal in order to make this simplification. The changes implied... *If a user is clicking on a URL for a share they are not already subscribed to in Cosmo, we don't automatically log in. This means that we don't have to deal with displaying shares that we have subscribed to and that are being previewed.
  • Disallow login when user clicks on a URL for a new share. Users can only log in by adding the share to their Cosmo account.
• Mimi and Priscilla are going to follow-up this thread with another set of detailed storyboards based on these changes.

Jeffrey posted a thread on recurrence and communications. This really relates how we deal with recurring events and mail (stamped items) and the intersection with the In/Out collections. We have decided to try and simplify things for Preview and say that any mail actions applied to recurring events (forward, reply, send, stamping etc) apply to the whole series. We will also be changing the table so that it will display a row for each modification and a row for the recurring event in the Now, Later, Done sections based on where we are in the series (occurrence happening now, things in the future and past occurrences).

• Should we have a this and future dialog popup to warn that user that adding addressees, stamping/unstamping, forward etc apply to the entire series? Mimi replied with "yes" and we should gray out the options not available in the dialog.
• Jeffrey is also suggesting that it would be easier for users if we just had one row per occurrence in the In/Out views. Mimi thinks it's not worth doing this since most people don't look at these collections anyhow and certainly won't be triaging items in there.

Mimi sent out an update on where we are with the Cosmo login related workflows needed for Cosmo 0.6.

• Priscilla is continuing to work on the modified storyboards and will send out an update soon.
• Priscilla followed up with the new workflows.
• BCM replied with a note that we need to make sure the home collection browser is accessible to everyone.

Mimi sent out a proposal for the user experience of how to handle more than just events in the Cosmo UI (Cosmo simplified dashboard). This does not mean replicating the dashboard features in Cosmo, it simply means that a user from Chandler has shared a collection with more than just events (tasks, mail etc) and we need to figure out what the Cosmo user sees of that info and what are all the actions they can take. The Cosmo team is quite keen on supporting more than events for Preview so we have come up with a simple proposal that eliminates much of the complexity of the display we have in Chandler.

Priscilla sent out a note announcing the Cosmo 0.5 release.

Mimi sent out a note around What does Read/Unread status mean in Chandler? We have been talking about this in the context of a number of dashboard discussions. Read/Unread status is pretty straight-forward when talking about individual items but what does it mean when you are dealing with recurring events? Mimi put together a proposal for how we should treat Read/Unread status.

• Unread:
  • Item you created in the CLI
  • Newly created item
  • Item changed by somebody else
• If items pop to the top of the Now section because a tickler goes off or a date rolls around it DOES NOT appear as Unread.
• Marking recurring events as Read or Unread marks all instances of the recurring series that look like it (including other occurrences of a different date or triage status).

Continuing on the dashboard discussions, Mimi forwarded a summary of how we will address Forwarding and Replying to Recurring Events.

• At any time a user performs a Communications related operation with a recurring event, the entire series is affected.
  • Stamping/addressing
  • Forward
  • Reply
  • Reply All
• Mimi then had a number of follow-up questions about how this works and if we can treat replies a bit different since it's meant to be a different action.
  • If we forward an events series with modified instances, can we display this information in the notes field?
  • Can we reply to individual instances of a recurring event, or the 'This and Future' subset of a recurring event series?
  • If so, can we mark individual instances of a recurring event or the 'This and Future' subset of a recurring event series as 'Needs reply'? Since reply really has nothing to do with the recurring series, we can handle reply differently. It's only an email and the work involves deciding what to display in the notes field when you to reply.
  • The meta data from (the thing you clicked on to reply to) gets copied into the notes field. This could be meta data for a single event, entire series, subset of a series etc.
    • If you are replying to a single instance, display the metadata from that single instance
    • If you are replying to the 'This and Future' subset of the recurring event series, display the metadata from the
  • We will also allow users to select to choose between All, Just this event, and This and Future when marking an item as 'Needs reply'

Mimi forwarded some discussion around Bug#6553 (Go offline for email) to the list. Brian is working on the ability to take email offline to help facilitate testing for the developers. Then in the context of making this an end user feature, Mimi started to think about how this would work with taking shares offline and the desired user experience. There was a bunch of back and forth in various email threads. It became obvious that we need to figure out how to integrate this into the design and that was going to take some bandwidth.

• Conclusion: We did this work to support a developer need and will add the ability to take email offline in the test menu. We don't need this as an end user feature for Preview and will revisit the right design post-preview - when the higher priority tasks are out of the way.