Re: [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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design