Okay.

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.

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.

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.

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.

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.

What's the rationale for that exception?

Okay - what about not automatically adjusting into the next day, though?

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.

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.

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