[Design] Re: Updates to the Dashboard Spec - Smarter Date column

[Bryan Stearns]

Mimi,

comments inline

Mimi Yin wrote:
> http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html
>
> I started updating the Dashboard spec and thought of a hybrid approach 
> which would allow us to keep the Reminder column interactive 
> (clickable) AND give us 
>
> Of course this proposal may be both:
> 1. Too complicated to implement; and
> 2. Too complicated for the user.
Just like before, it's no more complicated to implement than what was 
already in the spec. I still have no idea how much of the spec stuff 
we'll get to in any particular timeframe, however.

Did you see my comments in the message you replied to? You just said 
this again:
> I've also added a section in the Alpha 5 dashboard for auto-triaging 
> events that are created directly on the calendar canvas. This is taken 
> directly from the list discussion, so there shouldn't be any surprises 
> :o)
>
> *Auto-Triaging events that are created directly on the Calendar*
>
>     * 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.
>     * 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.
>
but the message you were replying to ended with me saying that those 
last two bullets aren't doable:

>>>> 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

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