[Design] [Cosmo] Update on Dashboard and Recurrence

Mimi Yin mimi at osafoundation.org
Mon Jun 4 12:42:58 PDT 2007


Bobby and I chatted briefly today to catch up on Dashboard and  
Recurrence issues and came up with the following list of Open  
Questions and Scenarios. Bobby, BCM, Jeffrey and Ted will be meeting  
tomorrow at 11AM PST to hopefully iron out some of these issues:

The current Recurrence Proposal as I understand it:
1. The web client does not have the smarts to expand recurring event  
series.
2. The web client will ask the server to expand the series and send  
down:
+ 1 NOW occurrence (if there is one)
+ The next LATER occurrence (If there is one)
+ The last DONE occurrence (if there is one). Open question: Jeffrey  
felt the logic for DONE instances was quite a bit more complicated  
than NOW and LATER and perhaps should be ignored for Preview.
+ Any modified instances. Open question: Would it help to ignore  
modifications for Preview?

Open Question: Does the master event of a recurring event series have  
a triage status? If so, what is it?
Open Question: When the server expands the recurring event series and  
sends down 1 NOW and 1 LATER instant, does that turn those instances  
into modifications?

===

The current Auto-triage Proposal as I understand it:

Bobby proposes that we do both kinds of auto-triage in the web client:
1. Auto-triaging events based on their start/end date/time metadata.

2. Auto-triaging events to NOW as time passes (aka Tickling)

3. Events will not be auto-triaged to DONE as time passes. Once  
events have been auto-triaged to NOW via tickling, they stay there  
until the user explicitly triages them to DONE.

4. The web client will understand how to set and respect the flag to  
'stop auto-triaging on changes to event date/time metadata.'
+ Once an item has been auto-triaged (tickled) to NOW as time passes,  
the web client should stop auto-triaging items on changes to event  
date/time metadata.
+ Once an user (any user, Desktop or Hub, sharing the item) has  
explicitly clicked the Triage buttons to manually assign Triage  
Status to an item, the web client should stop auto-triaging items on  
changes to event date/time metadata.

5. The web UI will only auto-triage items based on event date/time  
metadata and ignore alarms. However, Desktop clients that Auto-triage  
(Tickle) items to NOW when alarms fire will send that information to  
the server and the web UI will respect that the Triage Status has  
been 'explicitly' set to NOW which in turns overrides any Triage  
Status the web UI might wish to automatically assign the event.

Are there other scenarios we should spec out in detail?

Mimi

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


More information about the Design mailing list