[Design] Recurrence, table view, and triage status

[Grant Baillie]

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