Grant posted his reply just before I sent mine; mine pointed out
problems with doing on-the-fly master->occurrence translation, but
Grant's suggested a mechanism for allowing us to conditionally store
occurrences in collections, which seems more in line with the
collection/indexing model that the table uses.
However, I'm still not sure which occurrences should show up: Jeffrey
says "the next relevant occurrence". We'd need a way to make sure this
stays up-to-date with the passage of time, but I think we can use the
startTime-transition reminder for this.
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.
(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!)
...Bryan
Grant Baillie wrote:
On 8 Sep, 2006, at 15:34, Mimi Yin wrote:
This would be a good first step towards what we would eventually like
for recurring events in the Dashboard:
http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html
Here's what I understand from this:
1) We should show modifications in the summary table. This comes from
the requirement that we want to show occurrences that have been
triaged. Note that these really are modifications to the master: they
have different triageStatusChanged/lastModified values (and therefore
have a different value in the date column).
2) Jeffrey's idea of showing the "next relevant occurrence" makes
sense. Perhaps we can even get away with showing this as a placeholder
for the master, except for:
3) There are some cases where no occurrences exist, only the master.
These are somewhat pathological, but users could accidentally get into
this state (e.g. by mistyping the "until" date).
Anyway, the design question here is to figure out specifically what
events/occurrences we need to display so that people can see/edit
their events. This includes some tricky cases, like modifications or
deletions to the master itself, or #3 above. Or, say, a case where you
have a weekly event, and want to delete the occurrence that occurs in
three weeks' time, which isn't shown in the dashboard.
<<This really belongs on chandler-dev, but it follows on from the
previous stuff>>...
On the implementation side, much as been made of the difficulty of
retrofitting the existing collection-based model to support having
various and sundry occurrences and/or masters floating around in the
summary table. I think the easiest approach is to create a filter on
the collection of all events (much as we do to filter out non-masters
today). That filter would be very simple: it would check a Boolean
attribute on the events, and the domain model would be responsible for
maintaining that attribute. I don't think this is an inappropriate
infiltration of UI requirements into the model layer.
--Grant
On Sep 8, 2006, at 3:16 PM, Philippe Bossut wrote:
Jeffrey Harris wrote:
The first thing that comes to mind for me is that perhaps instead of
always displaying the master, we want to display the next relevant
occurrence in the table view, taking the current time and triage
status
into account. I expect doing that would be quite a bit of work,
but at
least it wouldn't involve varying numbers of rows per item like
displaying several occurrences alongside a master would.
+1
Since the table view is now the Dashboard, we should see in priority
here things that are upcoming next or close to (Now or Later).
For the "changing the triage status to unique occurrences" issue,
why can' we have a "All, All future, This one only" dialog? IOW,
isn't the triage status an attribute of the item and should trigger
the same behavior as other attribute change? (obviously a naive
question but I thought I ask to clarify the problem)
Yes this is the desired behavior.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
