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

[Bryan Stearns]

Whew - That first sentence should've been "I don't think that the 'ideal 
design' given below _is_ any harder to implement than any of the 
others", though even rereading that confuses me. :-)

Bryan Stearns wrote:
> Mimi,
>
> I don't think that the 'ideal design' given below isn't any harder to 
> implement than any of the others.
>
> I think all the approaches discussed so far are going to require a 
> little piece of code to return "the value to sort by or display for 
> this item". (Where this code lives, or how it's found, is still to be 
> decided, but the point is that I don't think there's a declarative 
> purely-structural way to specify any of the behaviors you've 
> suggested.  As long as we've come up with a way to call that little 
> piece of code, I don't think any of the approaches are hard.
>
> ...Bryan
>
> Mimi Yin wrote:
>> 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
>>
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/0f0347b9/attachment.htm