Hi Bryan,
Thanks for pulling this over to the design list. It's long overdue!
I agree that this is the most common use case.
#2: Dan says that when seeing an end time change that would be
before the start time, we should automatically change the end date
by a day. This is doable by itself.
I agree with you that Jeffrey's scenario might happen if users make a
mistake or plans change but is less common.
#4: Jeffrey says that the opposite behavior might be useful: on a
12/16 9PM - 12/17 1AM event, changing the end time to 11PM should
change the end date to 12/16, even though 12/16 9PM - 12/17 11PM is
valid.
My only concern is that the "?" behavior is handy for detecting
mistakes where users don't mean to enter end-dates that happen before
start-dates. Which makes me wonder if it'd be better to simply
disallow this behavior altogether and return a ? in the
For example, I enter something from 10AM-2PM and accidentally auto-
complete to 2AM, since AM is always the 1st auto-complete option. If
we implement #2, Chandler will create a multi-day event from 10AM-2AM
instead of warning me that I made a mistake.
This makes me wonder if it might be all-around cleaner to just
disallow entering end-times that start before start-times and tell
users that they've made an error. This is what Apple iCal does.
But I don't feel strongly about this and think it would be neat to
try out #2. So I think we should just do whichever option is most
expedient to implement.
Mimi
On May 16, 2007, at 12:17 PM, Bryan Stearns wrote:
hamstar, JeffreyH, philippeB,
I took bug 7522: https://bugzilla.osafoundation.org/show_bug.cgi?
id=7522 (start and end time automagically changing wrong)
However, the end of the discussion there isn't conclusive, so I'm
moving it back to the design list:
The story so far: Priscilla wanted to enter an event that crossed
midnight (eg, starting at 10PM for four hours), by changing the end
time (on what was then a 1-hour event starting at 10PM) to "2:00
AM". The existing date/time entry behavior confused her, since the
spec (see http://viewcvs.osafoundation.org/docs/trunk/docs/specs/
rel0_6/Detailview-0.6.htm; look for "Under certain circumstances")
currently says that "Changing the end date or time such that it
becomes earlier than the existing start date+time will change the
start date+time to be the same as the end date+time (that is, an
@time event, or a single-day anytime event if the event had already
been an anytime event)."
The mechanisms behind these fields have certain constraints:
1. We never allow the user to enter dates that would produce an
invalid event: the end date/time must always be after the start
date/time. (Internally, this is because we represent events as a
start date/time and a duration, not as separate start and end date/
times - this works out better for e.g. recurrence & timezone
handling.)
2. When automatically changing other fields on entry, do so without
any "history": each entry operation looks at the underlying values
on the event, and can change them, but can't tell what values they
used to have, etc.
3. Our only current way to reject entry in a field is to quietly
add a "?" to it (try entering "foo" in a time field to see this).
In this situation, the underlying event's value is left unchanged.
4. Anything in the application that subsequently changes an
underlying value causes the field to reload, even if it's invalid.
The user expects this behavior when dragging an item in the
calendar - the detail view fields update during dragging. In this
case, though, if the user entered a too-early 2:00 AM in the end
time, and we changed that to "2:00 AM ?" without changing the
underlying value, and the user changed the end date to the next
date, the end time field would reload itself automatically to
whatever time was there before the bad 2:00 AM was entered. We
could add more special-case code to handle that, but that snowballs.
(Changing these is doable, but could be a kettle of fish we'd
prefer to leave closed until after Preview.)
Comments on the bug added several partial proposals:
#2: Dan says that when seeing an end time change that would be
before the start time, we should automatically change the end date
by a day. This is doable by itself.
#3: Mimi says that we should do what Dan suggests, if the start
time is after 5PM. This is also doable.
#4: Jeffrey says that the opposite behavior might be useful: on a
12/16 9PM - 12/17 1AM event, changing the end time to 11PM should
change the end date to 12/16, even though 12/16 9PM - 12/17 11PM is
valid. This is doable, but I think the cases where it'd be useful
are less common (than, say, events that crossed several midnights,
which'd be confusing); I think users would have a hard time
figuring out the rules from this behavior.
#10: Mimi asks about several different possible alternatives.
I think the simplest thing is to do Dan's #2 proposal, or Mimi's #3
modification of it (though I don't see why 5PM is a magic
boundary). This would change the rule in the spec to: "Changing the
end time such that it becomes earlier than the existing start date
+time, if the start and end dates are the same (and maybe if the
start time is >5PM), will increment the end date by one day. Other
changes to the end time, or changes to the end date, will change
the start date+time to be the same as the end date+time (that is,
an @time event, or a single-day anytime event if the event had
already been an anytime event)
Comments?
...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
