Hi,
Thinking about this a bit I was wondering if the real issue is that the
Dashboard is lacking the notion of a time bracket (like the calendar has
because of its nature) while, indeed, it's all about time (Now, Later or
Done). I know those are "triage status" but they are truly related to a
rubbery notion of user time as their monikers indicate.
Proposal: For recurring events, expand and individualize occurrences in
a limited time frame centered on "today" (say one month on both side,
future and past, just to get a picture). Thus using the same mechanism
we currently use for calendar.
Rationale: From a user standpoint, displaying all possible occurrences
or just the master seems inadequate. Displaying only the next one is
weird too since the user may want to manipulate different instances
differently (Mimi outlined a couple of scenarios). Since the dashboard
objective is trying to focus the user on what needs to be done Now or
not too far from now, it makes sense to display a time bracket. Also
users act on instances of events so displaying them instead of the
master seems more adequate.
Implementation: We could use the same expansion mechanism we're using
currently in the calendar view. Manipulating any of those occurrences
would be no different than manipulating one in the calendar today. If
I'm not mistaken, this mechanism indeed creates individual events in the
repository. We should make sure that those events and the ones created
by the calendar are one and the same (I see no reason why not but just
pointing to the possible issue).
The differences with calendar are:
. for non recurring events, we would not bracket them in time. Seeing
that trip to NY in 3 months from now for a conference is still
important. So the way we create the collection will be different from
what's done by the calendar.
. we need to change the bracket (go to the "next" one) every so often
(once a day apparently...).
Consequences:
. We edit only occurrences so we don't have the problem of creating
modifications out of the master we're having now (at least, the problem
is no different to the one we have with calendar and we have a pretty
good solution there).
. This solves the issue of triaging several near occurrences of the same
event (say the meeting in 2 weeks in a weekly meeting of which 1
occurrence shows up in Now and 3 in Later).
. Occurrences that are not marked Done will simply fade out of view. Is
that really bad? I don't think so (at least, most of my recurring
meetings don't need to be actively triaged to become Done: their time
simply pass...).
. Long range recurring events won't come into focus before they enter
the time window (say birthday won't be shown before the month before).
Might be bad... Not sure... Could we have a "variable time frame"
depending on the recurrence frequency? On the other hand, if the
dashboard is about "focusing on Now", not having "Christmas shopping"
showing up in Later all year long is not that bad if you ask me.
. The Dashboard is not really a "view all" sort of view anymore since
some temporal masking is added for events. Should we have a true "All"
view with only master events (no occurrences) and no triage then?
Thoughts?
- Philippe
Bryan Stearns wrote:
Mimi,
Our recurrence implementation doesn't allow individual occurrences to
have their own values for attributes (that is, values different from
the master's) unless the occurrence is a "modification", which means
it inherits *no* attributes from the master (and won't change if an
"all events" or "this and future" modification is made to the series).
(Alternatives to this have been proposed, but aren't going to be
implemented soon.) ... so (see below)...
Mimi Yin wrote:
Hi Bryan,
On Sep 12, 2006, at 3:47 PM, Bryan Stearns wrote:
Grant interprets the spec (I think) to call for showing
modifications. However, I'm not sure what constitutes a
modification. Philippe suggested, and Mimi +1'd, that triageStatus
changes should be considered modifications, but triage status
changes with the passage of time, so every event that's gotten
bumped to Now and is now in the past would be a modification.
I think the user has to manually set an event from NOW to DONE. It
doesn't automatically become DONE just because the event end
date/time is in the past.
Right - but when an event's startTime is reached, it automatically
becomes "now", which doesn't work right for recurrence series because
occurrences can't have their own attribute values without becoming
modifications.
(Yesterday, I got fed up with thinking about these recurrence
issues, so I implemented the mechanism to set the "read" attribute
when an item is displayed in the detail view - it works great for
ordinary items, but guess what happens when you display a recurring
event? You get the All/This/ThisAndFuture alert, and get to create
modifications. Clearly that's wrong: even if we didn't put up the
alert, it'd mean that any occurrence you've looked at suddenly
became a modification!)
It might make sense for individual instances to be Read or Unread.
For example, if I edit and update the Agenda for the 3rd instance of
a weekly lecture series and send it to you, shouldn't you see that
particular instance of the recurring event as unread?
Except that individual occurrences can't have their own attribute
values without becoming modifications.
Although now re-reading what you wrote, I'm not sure I understand
what you mean by: "any occurrence you've looked at suddenly became a
modification".
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
