[Design] Please review: Dashboard Spec Updated!

[Philippe Bossut]

Hi Mimi,

Mimi Yin wrote:
> I have updated the Dashboard spec with stuff from the wiki, including: 
> http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html 
>

So I read the new sections except the "recurring events" section. I have 
some questions:

- in "Read/Unread status Workflow", there's this puzzling sentence:
    "Not-new tems are not marked as Unread when they are 'tickled' into 
the NOW section"
?? Lots of negation are hard to decipher... but anyway, my understanding 
is that this could simply be rewritten as:
    "The read/unread status is not changed when items are tickled in the 
NOW section"
Is that correct?

- "Note: If there are Unread items that are about to be purged, we 
should throw up a dialog: Are you sure you want to purge? There are 
newunread items that will be purged."
I don't see a strong rationale for such a pop up dialog. What's wrong 
with triaging unread items? Besides, the verb "purge" seems to indicate 
that something will be "removed" or "got rid of" which is not the case 
(items will simply be resorted). I suggest not to provide this dialog.

- "As a result, syncing a collection should share items as if the 
collection had just been purged (but shouldn't actually cause a purge to 
take place)."
?? Unclear. Anyway, since the "section triage status" is not shared, 
newly synced items will get their "section triage status" assigned as 
described later in the spec, i.e., set to NOW.

- "However, ticklers and start date/times that auto-triage the item and 
triage status changes invoked by explicit user action DO permanently 
affect the explicit and ARE shared."
?? Unclear. I suppose that could be summarized simply by "Color triage 
status are shared".

- "If Triage status is shared, then the order of items in the collection 
is shared as well"
I don't think there is anything like an "order of items" in collections, 
at least, not one that's surfaced to users except for the "section 
triage status". But since this one is precisely not shared, I really 
don't understand what this "order of items" refers to. The other "order" 
is the one induced by when an item has been moved to a particular 
section but again, since this "section triage status" is not shared and, 
potentially, different between sharees, its order cannot be shared either.

- "Create a new event by double clicking on the calendar that is 
happening right now"
Define "right now" (for this example and all other places where "right 
now" appears in the autotriage spec).  Is that within +/- 1 hour of 
current time? Sometime today? I think that "right now" should be "today" 
'cause I think that creating an event for, say, this afternoon when it's 
9am is not enough to park the event in "later". This is debatable. 
Anyway, we need a definition of this concept. This definition will 
mechanically influence what is "in the future" (after "right now") and 
what is "in the past" (before "right now").

- "Receving a message via Email (even if the message is an Update on an 
existing item)." (item becomes NOW in the NOW section...)
I'm confused: if a message is an Update on an existing item (say an 
event), I thought that the message was not shown as a message to the 
user but that the item was simply updated as if shared via Cosmo. Why 
then should its triage status be changed? (especially confusing if the 
update contains a triage status change...)

- "Note: Respecting explicitly set triage status needs to work with 
sharing, if triage status is a shared attribute. In other words, 
auto-triagingtriggered by users assigning and changing date/time 
information to items ALSO stops if a sharee 'explicitly' triages an item."
Hmmm... This means that an "explicitly set" flag exists in the domain 
model *and* is shared along the triage status. Morgen? Grant?

- Autotriage summary:
I'm tempted to summarize the 3 tables into the following set of rules 
(for Preview):
    rule 1 - If Alarm date/times or Event date/times fires then *always* 
set the "Color status" and "Section status" to NOW
    rule 2 - If "Color status" has been "explicitly set" then do not 
autotriage the item
    rule 3 - If the date/time or alarm has been edited then change the 
"Color status" but not the "Section status"
    rule 4 - If item is received by a share (new, edited, error) then 
set "Section status" to NOW (the "Color status" is the one set in the 
share...)
    rule 5 - Items created by the user have their "Section status" set 
to NOW and their "Color status" set according to their Date/time or 
Alarm or NOW by default
Looks like it covers everything, isn't it?

- Ordering per section:
I don't understand why items are sorted according to their 
Tickler/Calendar Date in the Later section but not in the Now or Done 
section. Is there a rationale for that?

That's it for tonight.

Cheers,
- Philippe