[Design] Re: Smart Auto-triaging of new events on the calendar

[Mimi Yin]

In the Alpha 4 Dashboard Spec, Sheila and I simplified the behavior  
of the Date column. However, she dug up this use case last week,  
which points out some of the usability problems of our simplified  
design.

Q. What if you set a custom-date Tickler on an event that fires after  
the event has happened? e.g. You want a reminder to fire after every  
staff meeting to write-up and post the meeting notes.

Q. What if the custom-date Tickler has already past? What date should  
we display? The tickler date? which has past? or the event date which  
may or may not have past?

This also touches on some issues Mitch brought up in our Spec review.

Alpha 4 Design:
+ If the item is an event, show the event date/time
+ If the item has been assigned a custom-date tickler, show the  
custom-date tickler
+ If the item is neither an event nor assigned a custom-date tickler,  
display

Ideal design:
+ Always display the NEXT important date.
+ If both the custom tickler and event dates/times have past, in  
other words, if there is no NEXT important date, display the event date.
+ If the custom tickler date has past and there is no event date/ 
time, keep displaying the custom tickler date.

Always displaying the NEXT important date, be it the event date or a  
custom tickler date, would be consistent with the way we display  
dates when an item has neither an event date or a custom tickler  
date. Non-event, non-tickled items display the MOST RECENT important  
date (Date sent, Date modified, Date created), whichever happened  
most recently.

Always displaying the custom tickler date, if there is one, is what  
we have spec'd out currently, and is more consistent with the  
workflow of allowing users to set ticklers in-line, in the Reminder/ 
Calendar stamp column of summary table view. (It would be confusing  
to set a tickler in the summary table and then have it revert back to  
show the event date/time. It might make you think your tickler date  
didn't stick.)

So, what are our options?

1. We can ignore this use case for now and worry about it after Alpha  
4. This would be in line with the spirit of 'focusing on the basics  
for Dashboard' in Alpha 4.

2. We could implement the 'ideal design' and turn off in-place  
editing for the Reminder/Calendar stamp column.

Questions:
+ Does anyone have any specific examples of when they would set a  
custom-date tickler to fire after an event?
+ Is the 'ideal design' much harder to implement than what we have  
spec'd out for Alpha 4?

Mimi

> On Jul 9, 2006, at 4:46 PM, Sheila Mooney wrote:
>
>
>> Mimi,
>>
>> If you you create an event for today ie: 3pm and you have an  
>> alarm, I didn't think it popped into the NOW section until the  
>> alarm went off. Maybe I am confused between events created today  
>> and events (for today) that were created at some time in the past.
>>
>> Sheila
>>
>>

On Jul 6, 2006, at 7:52 AM, Bryan Stearns wrote:

> Mimi,
>
> You wrote:
>> On the calendar canvas, instead of setting all new events to NOW,  
>> we should set triage status on event items in terms of where they  
>> live on the calendar canvas relative to your current place in time.
>>
>> + For example, events created in the future (ie. after Today) are  
>> set to LATER.
>> + Events created for Today are set to NOW.
>> + Events created in the Past are set to DONE.
>>
>> + If it is 3PM and you create an event for 10AM Today, the event  
>> should be set to DONE.
>> + If it is 3PM and you create an all-day or anytime event for  
>> Today, the event should be triaged as NOW.
> Those five are straightforward enough - I think it breaks down to  
> this, done by the calendar canvas as part of creating the event:
>
> if start > now and start.date() != now.date():
>  triageStatus = LATER
> elif end < now:
>  triageStatus = DONE
> else:
>  triageStatus = NOW
>
> However...
>> + If you create a multi-day event that starts before Today, but  
>> ends either Today or after Today, the event should be set to NOW.
>> + If you create a multi-day event that starts Today but ends after  
>> Today, the event should be set to NOW.
> I think the only situation where we can pre-set triage status is on  
> *initial creation* of an event where the time is already known:  
> that is, when the user double-clicks on a canvas to create an  
> allday event (if in the allday/anytime area) or a one-hour event  
> (if in the timed area). Everything the user does after this (like  
> turning the original event into a multi-day event by drag-extending  
> it on the calendar canvas, or editing fields in the detail view)  
> are edits to an existing event.
>
> We could update triageStatus with the above logic (or something  
> like it) whenever the user edits one of (start, end, timezone,  
> allDay, anyTime), but I think that'd be weird... alternatively, if/ 
> when we change events to allow them to not have a start date/time  
> until the user fills it in (which isn't quite as simple as it  
> sounds), then we could set triage status as part of the user's  
> first entry of a valid start date/time (assuming we're still  
> assuming that timed events are an hour long by default).
>
> ...Bryan
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060710/8c82bb71/attachment.htm