On Feb 10, 2007, at 1:48 AM, Philippe Bossut wrote:
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?
That sounds better. I'm just trying to figure out, is it possible to
have a New item that is tickled? I guess what it is is that Tickling
to NOW in and of itself does not result in a change to Unread status.
- "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.
Yes, that is what that sentence is trying to describe.
- "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.
When Purged, items need to appear in the same order for all sharees.
This doesn't mean there's a specific mechanism for ordering (although
in the future, we will want to have one). Just that the way triage
sorting, tickling and purging works should result in the same triage
sort order across Chandlers.
- "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").
I mean "Right now" in a literal way. If the event is scheduled for
Today at 10:42AM and it is 10:41AM, the event would not be right now.
If an event is scheduled for Today from 10:40AM-11:42AM and it is
10:41AM, the event is NOW. This only affects the Color triage status,
not the Section triage status. Newly created events will show up in
the NOW section regardless of what Color triage status they receive.
I will clarify that in the spec.
If we decide that "Right now" should really mean Today...or +/- 1
hour, then we should make the tickling behavior match this as well.
e.g. An event scheduled for 6PM tonight, would tickle into my NOW
section at 5PM. Then there is the question of the alarm, what if
there is a '15 minute before' on the event. Does the event tickle at
5:45PM? 4:45PM? or 5PM?
- "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...)
Oops, yes this is something we explicitly decided against. Good
catch. I will change that. The Section Triage status becomes NOW, but
the Color triage status stays the same.
- "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?
I think Bryan Stearns was going to take a crack at this too.
- 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?
Good question. I will address this in a separate thread.
That's it for tonight.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
