[Design] [Sum] Oct 30th - Nov 5th

[Sheila Mooney]

New Threads:

Jared sent out the latest hosted service update.
http://lists.osafoundation.org/pipermail/design/2006-October/005598.html

Dan sent an email with 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.
http://lists.osafoundation.org/pipermail/design/2006-October/005599.html

Mimi replied to an email BCM sent to the Cosmo list which detailed  
the 0.6 casual collaborator functional requirements. 0
+ 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.
http://lists.osafoundation.org/pipermail/design/2006-October/005604.html

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.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005611.html

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.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005612.html
+ Priscilla followed up with the new workflows.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005615.html
+ 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.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005613.html

Priscilla sent out a note announcing the Cosmo 0.5 release.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005616.html

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).
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005623.html

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'
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005624.html

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061121/1db5c3b8/attachment.htm