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

[Bryan Stearns]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060710/49ba50bb/attachment.html