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.
But if it's not too complicated to implement, it may be worth trying out for Alpha 4.
Bryan, let me know what you think. I can easily change the spec back to turn off interaction in the Reminder column (as discussed previously on the list).
PROPOSAL
Revising the rules for what displays in the Date column:
With the addition of Ticklers, what appears in the date column becomes a bit more complicated. Dates should appear in the Date column in the following manner:
* Date and time format * All dates appear in the form 'Mon DD, YYYY', e.g. May 12, 2006 except for Yesterday, Today and Tomorrow. * All times appear in the form of '(H)H:MM AM/PM' e.g. 3:30 PM =====NEW STUFF=====
* Always display the NEXT important date. * If both the custom tickler and event start dates/times have past, in other words, if there is no NEXT important date, display the Start date and time of the event. * If the custom tickler date has past and there is no event date/time, keep displaying the Custom Tickler date. =====NEW STUFF=====
* If an Item is not an Event, always display the most RECENT date: either the Date last modified or the Date sent which ever one happened most recently. * If an Item has none of these dates, the date column displays the Date created.
Keep the Reminder column interactive. (e.g. Click in the Reminder column to 'Tickle' the item.)
Activating the Reminder icon in the Reminder column blanks out the Date column for that row, overriding whatever Date should be displayed in the Date column. User motivation: This provides users with a way to 'tag' Items as 'Needs to be assigned a Tickler date.'
However, once the user assigns a Tickler date, the usual Date column rules apply. For example, if the custom Tickler date is not the right Date to be displayed, both the Tickler icon in the Reminder column and the Tickler date in the Date column will be overridden by the Calendar stamp icon and the Event Start-date and time.(See below in the Date column section for specifics).
====== 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.
All the above is dependent on if and how the user sets alarms on these items.
Users can manually change the triage status at any time in the detail view of the event.
Thanks,
Mimi
On Jul 10, 2006, at 2:46 PM, Bryan Stearns wrote: 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list |
