GNOME Bugzilla – Bug 223893
Interface problems editing Date & Time
Last modified: 2021-05-19 12:13:17 UTC
(I think this is unrelated to bug 213660) Editing the Start and End time of an event can be very problematic. At very least the current UI makes it easy to change the start time accadently. For example, set the start time, then set the start time to 12:00pm, then set the end time to 11:00am. This results in the start time rolling back a day without notifying the user. Setting the end time to 1:00pm, the start time still stays at 12:00pm the day before. Experimenting with moving the start and end times around, I still can't figure out exactly what the algorithm is. Suggested solution(s): (1) Only allow end times that are after the start time. (2) Figure out a better way to pick a time than the huge drop-down menu. (3) As an alternative to End time, have a "duration" field. (4) If not a duration field, make changing the start time drag the end time with it. (This could result in lack-of-feedback problems so maby not.) If a UI person is looking into this, here are some other things to consider: (i) "Start time: [date entry] [time entry] " is an odd format because a date entry box comes imidately after the word "time". Given the context, and that that part of the dialog is called "Date & Time", "Start:" and "End:" should be sufficient. (ii) The user shouldn't be allowed to close the dialog without having a valid date and time entered. (iii) The time and date entry widgets should be smarter. * Consider date entries like "today" or "monday" or "mar 5" or even just "4/25" * Consider time entries like "1300" or "noon". Also, timezone suffixes would be nice, like "10:00am PST"
I do not see the problem you describe with it flipping back a day. The algorithm is simply: if end time is set less than start time, make start time 1 hour before end time. If start time is set greater than end time, make end time 1 hour after start time. You can use the 24 hr clock option to get things like "1300" that you request above.
UI had nothing specific to add, but we will re-examine the duration field possibility for 1.4, its too late to add it now i think.
Looking at it again in Evo 1.2, I see two improvements that could be made: (1) It's not clear how to enter times by keyboard. For example, does "5pm" work? Does "12:15AM" work? Or, does it have to be in the canonical \d\d:\d\d\s(AM|PM) form? (2) (less important) The drop-down menu is a drop-down rather than a "pop-up" menu like the "Body or subject contains". (I forget the real name for this widget.) The issue is that, if you are used to holding your mouse button down while making a menu selection, you can instantly loose one of the times in the time selector because as soon as your mouse hits the menu, 12:00 AM is selected.
I've seen the problem with the start time skipping back to the previous day as well. I think it's a combination of the "if end time before start time, set start time to 1h before end time" and the fact that the time picker *doesn't scroll to the middle of the day* (by this, I mean: when you first click on the time picker drop-down, you'll see 12AM to about 10:30AM. But you should see the currently selected time, which usually isn't in the dead of night.) Eg: You want a 1-hour meeting starting at 11:30 am. Double click on 11:30 am to get a new meeting 11:30 am to 12 noon. Now click on the time picker. If you don't pay attention, you click on 12:30 AM instead of 12:30 PM, and poof, you've scheduled an appointment 11:30PM the previous day to 12:30 AM in the morning. My suggestions: 1. Don't move the times and days around. Let me figure out what I want the start and end time to be, and check if start < end when I try to save it. 2. Fix the time picker so that it automatically scrolls to the selected time, or the beginning of the work day (as set in the prefs), and (if possible) make the night and day visually distinct (grey background for times outside the work day).
I think this boils down to "interface makes user error likely", i.e. the picking 12AM instead of 12PM, even though the previously chosen time is initially selected in the list. I would contend that AM/PM is silly and everyone should use 24-hour time :) I realize this is not an option, though. Probably, a widget that lets you select a time in a more friendly way would have to be written, a la the mini-calendar widget. I don't think this is an option for 1.4.
Neither a 2.0 goal. Futuring.
Time entry from the drop down menu is lazy and lame. I'd like to see a pop-up thing like the calendar, but it ought to have a clock on it. You move the hands to select the times.
(In reply to comment #0) > (I think this is unrelated to bug 213660) > > Editing the Start and End time of an event can be very problematic. At very > least the current UI makes it easy to change the start time accadently. > > For example, set the start time, then set the start time to 12:00pm, then > set the end time to 11:00am. This results in the start time rolling back a > day without notifying the user. Setting the end time to 1:00pm, the start > time still stays at 12:00pm the day before. > > Experimenting with moving the start and end times around, I still can't > figure out exactly what the algorithm is. > > > Suggested solution(s): > (1) Only allow end times that are after the start time. Maybe there should be a warning dialog instead of silently changing the start time in 3.2.3. > (2) Figure out a better way to pick a time than the huge drop-down menu. Well, you can enter it manually. > (3) As an alternative to End time, have a "duration" field. This does exist and is the default nowadays. > (4) If not a duration field, make changing the start time drag the end time > with it. (This could result in lack-of-feedback problems so maby not.) This is the default nowadays.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.