6.0.0-git
2019-06-18

[#7474] Tweak event editing form time logic
Summary Tweak event editing form time logic
Queue Kronolith
Queue Version HEAD
Type Enhancement
State Assigned
Priority 1. Low
Owners Horde Developers (at)
Requester chuck (at) horde (dot) org
Created 2008-10-11 (3902 days ago)
Due
Updated 2008-10-21 (3892 days ago)
Assigned 2008-10-21 (3892 days ago)
Resolved
Milestone
Patch No

History
2008-10-21 18:27:02 Chuck Hagenbuch Comment #11
Assigned to Horde DevelopersHorde Developers
Taken from Chuck Hagenbuch
State ⇒ Assigned
Reply to this comment
I suggest we play with that in the new interface since
the form is created from scratch there anyway, and adapt it to the
traditional UI once we're happy with it.
Okay.
2008-10-21 18:18:13 Chuck Hagenbuch Comment #10 Reply to this comment
This could easily circumvented by using the duration setting instead
of the end time setting. I don't see how this could become a regular
scenario, and if it did, the user would get used to using the
duration setting for such adjustments.
My experience (and Jenn's) is that you don't get used to the duration 
setting; it's very easily overlooked. I had even forgotten about it 
when discussing this issue with her.
2008-10-13 09:40:49 Jan Schneider Comment #9 Reply to this comment
It occurs to me, though, that this confusion would be entirely
eliminated if we got rid of End Time in the form, and just had
Duration. I think that would be simpler for all single-day events,
and multi-day events are doable - and they are far from the norm.
I strongly disagree, unless you are talking about all-day events only. 
I don't want to have to calculate the duration of an event in the head 
if I only have the start and end date/time. This is different for 
all-day events of course, and I already played a bit with it in the 
past. But it didn't work well without some major edit form redesign. I 
suggest we play with that in the new interface since the form is 
created from scratch there anyway, and adapt it to the traditional UI 
once we're happy with it.
2008-10-13 09:36:23 Jan Schneider Comment #8 Reply to this comment
there's an existing event from 8-11pm. you move it one hour later
from 9pm-12am, which is the next day. if you then try to adjust it
back from 12am/midnight to 11pm, the event is now not 2 hours long,
as expected, but 26 hours long.
This could easily circumvented by using the duration setting instead 
of the end time setting. I don't see how this could become a regular 
scenario, and if it did, the user would get used to using the duration 
setting for such adjustments.
2008-10-13 02:17:02 Chuck Hagenbuch Comment #7 Reply to this comment
Part of the problem with this scenario is that we do a poor job of 
representing that multi-day events are the same event; it's very easy 
for someone who's just created a 26 hour event to think that they have 
a copy of their event instead, and delete the "second one"; now 
they've deleted the original, and don't know what happened. I'll open 
another ticket for making it clearer when events are the same on the 
calendar view.



It occurs to me, though, that this confusion would be entirely 
eliminated if we got rid of End Time in the form, and just had 
Duration. I think that would be simpler for all single-day events, and 
multi-day events are doable - and they are far from the norm.



As it is now, looking at the event edit form, there is a lot of 
complication; just now it struck me that the radio buttons aren't 
grouped at all, so End, Duration, and Alarm seem to be on the same 
level. Getting rid of End Date would help with that.
2008-10-13 02:06:02 Chuck Hagenbuch Comment #6 Reply to this comment
By automatically adjusting into the next day, if you shorten the event - say:



there's an existing event from 8-11pm. you move it one hour later from 
9pm-12am, which is the next day. if you then try to adjust it back 
from 12am/midnight to 11pm, the event is now not 2 hours long, as 
expected, but 26 hours long.



the argument is that we should force the user to change the date if 
the user wants to change the date.
2008-10-12 11:29:07 Jan Schneider Comment #5 Reply to this comment
What's the rationale for that exception?
2008-10-11 23:12:08 Chuck Hagenbuch Comment #4 Reply to this comment
Okay - what about not automatically adjusting into the next day, though?
2008-10-11 13:25:49 Michael Rubinsky Comment #3 Reply to this comment
I agree with Jan, FWIW.  There are very few times when I change an 
event start time AND the duration. Usually it's the same duration.
2008-10-11 09:48:29 Jan Schneider Comment #2 Reply to this comment
I'm against that. If I change start times of an event, it's most 
likely because, well the start time has changed. The event duration 
stays the same. The end time being adapted is one of the best 
usability feature of the event form IMO.
2008-10-11 03:04:34 Chuck Hagenbuch Assigned to Chuck Hagenbuch
 
2008-10-11 03:04:24 Chuck Hagenbuch Comment #1
Type ⇒ Enhancement
State ⇒ Feedback
Priority ⇒ 1. Low
Summary ⇒ Tweak event editing form time logic
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
consider not adjusting events past the end of the day when 
automatically adjusting end times (event from 9-11pm, move it to 11pm, 
it goes to 1am the next day; instead, have it go until midnight?). or, 
only adjust end times when creating events; when editing existing 
events, make time adjustments all manual

Saved Queries