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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
