[Design] [Please Review] Dashboard Spec Update - Recurring Events

[Mimi Yin]

http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/ 
Dashboard-0.7.html

Bryan Stearns has already updated the Dashboard spec with his  
rewriting of the Triage model: http://wiki.osafoundation.org/Journal/ 
TriageStatusImplementationNotes and the issues we worked through on  
the list: http://lists.osafoundation.org/pipermail/design/2007- 
February/006368.html

Yayy Bryan.

After chatting with Jeffrey last week, we worked through a model for  
how to present edit/updates to recurring events in the  
Dashboard...I've copied and pasted an excerpt from the spec below.

There is also the issue of triaging and marking recurring events as  
read/unread/needs reply, also pasted below. Jeffrey, are we really  
applying explicit triaging to the entire series? I couldn't remember  
if we only agreed to do that with Read/Unread/Needs reply status or  
if we are doing that with Triage as well.

Also...the stuff in the Triaging/Marking as Read/Unread section,  
should the same rules apply to Stamping to Add to/Remove from Task  
list and Adding/Removing Reminders? Both can be done from the Dashboard.

Mimi

Sending, Editing and Updating Recurring Events
In the Preview timeframe: Send, Update, and the Addressing fields  
will always apply to the entire event series. However, only 'edited'  
instances will be popped to the top of the NOW section in the  
Dashboard view.

If the user makes a global Edit to a recurring event series and then  
sends out an Update, all instances of the recurring event in the  
Dashboard will pop to the top of the NOW section in the Dashboard.  
(We know this isn't ideal, but it's a first step for Preview. When we  
have a notion of clusters, we might be able to represent global edits  
as a single row item that can expand to show more instances.)

If the user Edits a specific instance in a recurring event series and  
then sends out an Update, only that instance will pop to the top of  
the NOW section in the Dashboard.

If the user makes a 'This and Future' edit to a recurring event  
series and then sends out an Update, the 'This and Future' edit will  
be represented at the top of the NOW section in the Dashboard by the  
1st instance that was changed.

For more information on how replies and forwards will work with  
recurring events, see the Sending, Replying to and Forwarding  
Recurring Events section of the Email spec: http:// 
svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html

Triaging and Marking Recurring Events as Read/Unread and Needs Reply

If an user Triages, 'Reads' an item or marks an item as 'Unread', we  
should mark all instances of the recurring event that look just like  
it. (Ignoring differences in Triage status and Date/time metadata.)  
This is true in both the Dashboard and the Calendar.

-- Actually, after talking with Mimi today, instead of doing "events  
that look just like this", for now we'll just mark the entire series  
Read/Unread/Needs reply because this is an easy first step. --  
JeffreyHarris - 13 Dec 2006

-- I'm assuming that Triaging will apply to 'all instances of the  
recurring event that look just like it'. -- MimiYin - 23 Feb 2006
Note: Ideally, we'd like users to be able to make recurring events as  
Read/Unread/Needs reply in the same way we Triage recurring events.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070223/0645c7b7/attachment.html