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
