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