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
