275253 - make timepicker widget design more intuitive

Status: NEW

(Calendar :: General, enhancement)

Description

[fantasai]

Overview:

The timepicker widget isn't very easy to understand.
  a) It's in 24h format (see bug 255668)
  b) Hours and minutes are split into stacking rows, which is the opposite
     of the way they're displayed normally (side-by-side)
  c) This random box of numbers doesn't resonate the idea of "time of day"
     the way, say, the calendar resonates "day of month". Had to spend a
     little while to grok the thing, which shouldn't be necessary.

See Also:
  bug 165963 (wrt timezones)

Comment 1

[fantasai]

attachment 156146 [details] gives a screenshot

Comment 2

[Bernd]

I couldn't say that all that am/pm stuff makes a timepicker easier
understandable ;-), at least for non anglo influenced people 24h is normal.

Comment 3

[fantasai]

Precisely why we should be getting time locale information from the OS. :)

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: screenshot of vertical timepicker

to try address point b, i rotated the timepicker. See screenshot. Does that
look better?

Comment 5

[gekacheka]

The minutes display does not match the location of minutes on a clockface, which
might make it counter-intuitive to many people.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

I see a lot of digital clocks during every daylife. analog clockfaces aren't the
only types of clocks. So i don't think that is a problem.

Comment 7

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 8

[Marko Djukic]

Attachment: A simpler drop down

I agree that the UI is very unintuitive, takes me too long to navigate around the hours and minutes laid out in multiple rows. Even more so if you get things expanded to all minutes.

The rotation done by Michiel helps a little bit, but again the multiple columns for hours and multiple columns for minutes still makes it confusing.

Is it not possible to do just a simple scrolling one column design? I'm looking at the Google calendar time picker (see attached screenshot - I've merged screenshots of the pickers for the "From" hour and "To" hour). It's simple, easily understood - you scroll down the list. Also, the To hour has the added feature of giving you the duration in brackets which I think is excellent.

Comment 9

[Lars Wohlfahrt (thetux)]

I think Marko is right. The screenshot looks nice, too :-)

Comment 10

[Bas van den Bosch]

I think the point of the current timepicker (and mvl's proposal) is the smaller timeslots. I don't like the current one either and think mvl's proposal is better. Furthermore I agree with gekacheka about the rotation. 

Comment 11

[Marko Djukic]

The smaller timeslots are fine, but not splitting non-intuitively hours and minutes in multiple columns.

However, the granularity of the timeslots is probably questionable. Are minute increment timeslots really necessary for a picker? I think at most 10min timeslots are useful because it allows the user to pick the 10' increment and then edit the last digit for anything more precise.

Does anyone actually use the 60 different slots to click on for the exact minute? From personal experience, I use both Lightning and the Google calendar a lot, both equally as much, and it's just a lot more hassle with the Lightning picker than with just the 30' increments and the Google picker.

Comment 12

[Lars Wohlfahrt (thetux)]

don't get me wrong: mvl's proposal is much better than the actual solution!

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

I'm not quite happy with the vertical timepicker, and not sure about the simpler dropdown.

Christian, do you have an alternate proposal?

Changing the design will probably cause an overhaul of the whole picker, so its important to do the design change first, then take care of keyboard accessibility in bug 260121

Comment 14

[Christian Jansen]

(In reply to comment #13)
> I'm not quite happy with the vertical timepicker, and not sure about the
> simpler dropdown.
> 
> Christian, do you have an alternate proposal?
> 
> Changing the design will probably cause an overhaul of the whole picker, so its
> important to do the design change first, then take care of keyboard
> accessibility in bug 260121
> 

I think a simple list box (filled with hours in 30 min steps) would work perfectly. The list should pop-up with 7 entries visible.

    +-------------+
    | 20:00    \/ |
    +-------------+
    | 20:00    /\ | (Selected)
    | 20:30       |
    | 21:00       |
    | 21:30       |
    | 22:00       |
    | 22:30       |
    | 23:00    \/ |
    +-------------+

Comment 15

[Berend Cornelius]

Attachment: patch v. #1

In Gecko 1.9 there is a timepicker widget available. and the patch attached replaces our oold widget with that one. Unfortunately I ran into several problems that caused me some headache:
- The 'hideseconds' attribute is not propagated to the 'hideSeconds' property. This should be fixed in the toolkit file (easy fix). I worked around this problem in this patch.
- I don't think that the widget is really accessible: Modify a time-value by entering a new time and move the focus away from the widget undos the change. Also clicking <ENTER> does not preserve the change.
- Last but most annoying it seems that clicking the spin button of the timepicker leads to firing of several "onchange" events. In a special scenario this lead to a problem: When entering an enddate prior to the start date in the attendee dialog very often several alerts prop up indicating that the enddate occurs before the startdate. I have not yet found a solution for this problem so I am not yet asking for review.

Comment 16

[Berend Cornelius]

Attachment: Screenshot of the new timepicker

Comment 17

[Berend Cornelius]

One thing that also is not yet done in that patch is to remove the superfluous css rules. Probably the remaining datetimepickers implementations could be shifted to calendar/base/content/widgets

Comment 18

[Stefan Sitter [:ssitter]]

Can the jsdate based toolkit widgets be used now? AFAIK there were major timezone handling related issues when using jsdate.

The focus issue might not be a widget issue. We currently have the same issue with the datetime picker, see Bug 405529.

Comment 19

[Berend Cornelius]

Attachment: patch v. #2

>- Last but most annoying it seems that clicking the spin button of the
>timepicker leads to firing of several "onchange" events. In a special scenario
>this lead to a problem: When entering an enddate prior to the start date in the
>attendee dialog very often several alerts prop up indicating that the enddate
>occurs before the startdate. I have not yet found a solution for this problem
>so I am not yet asking for review.

When I further experimented with my patch I came to the conclusion that the bad behaviour seems to be related to the general behaviour of spinbuttons. I guess to achieve fast in-or decrementation the event is triggered so often. I added some changes among them I set a long timeout of 300 ms and found that the behaviour is - as far as I tested it - Ok. 
If this is not accepted my plan B is: I implement a derived binding from the timepicker widget and add a mouseup event listener upon which I fire a separate event (onspin or something like that)- in case the original target is one of the spin buttons. 
But at the moment I would prefer my solution as it uses the system as it is actually intended to.

in reply to comment #18
>Can the jsdate based toolkit widgets be used now? AFAIK there were major
>timezone handling related issues when using jsdate.
This is true. But also our own implementation of the timepicker was jsdate based. So in this aspect I don't see a difference that my implementation brings in.

>The focus issue might not be a widget issue. We currently have the same issue
>with the datetime picker, see Bug 405529.

As far as I saw I could probably overwrite the keypress handler of the timepicker to improve the situation - in a later issue.

Comment 20

[gekacheka]

PASTING/TYPING TIMES:  

The standard xul timepicker does not enable the user to paste a time in one paste, instead it requires a paste for hours, a paste for minutes, and select am/pm if displayed.  

The current calendar timepicker uses code which parses pasted or typed times in a large variety of time formats, including '9am', '9:30', '9.30', using symbols for localized am/pm, plus am/pm in roman, cyrillic, arabic, and chinese characters, as well as localized 'noon' and 'midnight', so users are likely to be able to copy and paste a large variety of times they find on the web or in email.
http://mxr.mozilla.org/mozilla/source/calendar/resources/content/datetimepickers/datetimepickers.xml#1496

(The datetimepicker enables you to workaround it by pasting the time to the side of the date in the date field, but this is probably only discovered by someone who pastes a datetime together in the date field by mistake, and it may be difficult to separately paste a time since there needs to be a space after the date.)


TYPING TIMES:  bug 407583 is a usability issue -- does not advance to next field in time when typing separator character ':'.

Comment 21

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 347547 [details] [diff] [review]
patch v. #2

Personally I'd prefer an extended timepicker binding (maybe you can even get in some toolkit fixes for 1.9.1!), using setTimeout() is quite hacky for such a case.

I can be talked into revising my decission, but I really would prefer fixing the core issue first...

Comment 22

[Christian Jansen]

Comment on attachment 347547 [details] [diff] [review]
patch v. #2

Sorry , but I can't ui+ this patch, because a spin box is from my point of view counter intuitive.

I'd like to see (even if it is the most boring solution) just two simple drop down lists one for the "Start" the other for "End" time.

- The first one should display the starting time. 
If the current time is 2:55 am the list should offer:

[3:00  |V]
+--------+
| 3:00 A |
| 3:30 | |
| 4:00 | |
| 4:30 | |
| 5:00 | |
| 5:30 | |
| 6:00 | |
| 6:30 V |
+--------+

- The second one should offer in addition to a list of hours, a list of periods. This makes sense because very often users don't wan't to calculate when a meeting has to end, but they know that the meeting should end for example in 1.5 hours.


According to 2:55 am the example the list should be as follows:

[4:00 |V]
+       --------------+
| 3:00 (0 minutes)  A |
| 3:30 (30 minutes) | |
| 4:00 (1. hour)    | |
| 4:30 (1.5 hours)  | |
| 5:00 (2 hours)    | |
| 5:30 (2.5 hours)  | |
| 6:00 (3 hours)    | |
| 6:30 (3.5 hours)  V |
+---------------------+

Comment 23

[Philipp Kewisch [:Fallen][📱📆]]

I must say I really don't like dropdown lists. Although I often see them used, I do hope we can do better than that! It feels so 90's to me. I hope I can come up with an alternative...

Comment 24

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Screenshot "Decoder Wheel" mockup

This is a mockup of a friend of mine, Alexander Ihle. Christian, what do you think? I think it looks very innovative and could give us a head start on new time picker implementations. Its probably easier to understand when in use though.

The inner circle is the hour, the outer circle is the minute. The outer circle hoveres the minute currently moused over. The time in the middle should update when being selected.

For accessibility, I think we can make the arrow keys first select the hour, then allowing to "tab" or ":" to the minute and then select a minute. pressing number keys should work too. This makes it behave basically like a spin button for the visually impaired and gives more options for users of a mouse.

Of course we should keep the combobox instead of the dropdown icon to allow display of the time when the dropdown is inactive and also to allow users to enter a time if they rather feel like doing that.

Implementation could get a bit complicated, but I think its worth it!

Comment 25

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Screenshot "Decoder Wheel" mockup

Oops wrong mockup

Comment 26

[Christian Jansen]

(In reply to comment #24)
> Created an attachment (id=348955) [details]
> Screenshot "Decoder Wheel" mockup
> 
> This is a mockup of a friend of mine, Alexander Ihle. Christian, what do you
> think?

It looks pretty interesting. My first reaction was that it is a little bit to complex, but in general I like the idea behind it.

From my point of view there is no need to specify minutes within the control. Sure, there is an use case for that, but IMO it is ok, to type minutes directly into the edit field of drop down box.

Another solution (see attachment) could be a watch which displays start and end time of an appointment. The start and end time is can be modified by moving a slider. This idea was inspired by the google stock chart gadget.

http://finance.google.com/finance?q=NASDAQ:GOOG

Comment 27

[Christian Jansen]

Attachment: Slider Clock Mock-Up

Comment 28

[Christian Jansen]

Comment on attachment 347513 [details]
Screenshot of the new timepicker

As already mentioned the spin box proposal is from my point of view not sufficient.

Comment 30

[koyama]

I suggest that the original issues a), b) and c) by fantasai are solved using minimal modification to the current version of the time picker. Note that fantasai is not complaining about the granularity (minute steps). If there is need for changes in granularity then this would be an entirely different topic.

Suggestion by Michiel van Leeuwen in comment 4 solves b) and c).
https://bugzilla.mozilla.org/attachment.cgi?id=169125

Suggestion by Michael Carson in bug 255668, comment 2 solves a)
https://bugzilla.mozilla.org/attachment.cgi?id=156147

Combining the two suggestions would solve a), b) and c).

I am not unwilling to discuss granularity, but again, this is another topic. Personally I prefer high granularity. I see no reason why we should reduce granularity. For me, having only 30 min steps won't do. 15 min is better, 5 min even better, but quite often I need 1 min steps.

Using the time pickers of Microsoft Outlook and Google Calendar I must resort to typing time values manually using keyboard whenever I need precision higher than 30 min. This requires significantly higher amount of efforts. Therefore, for me, these implementations are not good alternatives.

Comment 31

[fantasai]

I think the Decoder Wheel idea is really cool, and might be a good way to solve this. I've got a couple of comments on it, though.

1. The widget should display as a textbox with the time in digital notation, and have a clock button next to it (attached like the spinner buttons) to pop up the Wheel. This is similar to the way a lot of travel sites handle the calendar. If you're tabbing through or you are just more comfortable typing, typing should be immediately available. If you want a visual, you click the clock button next to the field. People are well-accustomed to reading digital times and can decode a time instantaneously off a digital display, so we don't need the Wheel displayed all the time: just when you're using the widget to change the time.

2. Ideally typing in any of the notations we have a decoder for (see comment 20) should Just Work and resolve to digital notation as soon as you focus out.

3. On computers/locales set to use 24 hour time, 12 should be 0 and the PM button should add 12 to the hours.

4. The quarter-hour targets need to be bigger and easier to hit. While it's great that we have full granularity here, most of the time people will be hitting 00/15/30/45.

5. It feels like the space inside the minute ring isn't used very efficiently. I'm not sure what to suggest here, though.

If we don't need minute-by-minute granularity in the visual picker, then a set of concentric circles with the hours on the outside, 00/15/30/45 in the middle, and an AM/PM switch in the center would probably be sufficient. (If the text box is displaying the digital time, we don't need it displayed in the center.)

The wheel should probably be called an Encoder rather than a Decoder, actually...

Comment 32

[koyama]

I do not want to be the party popper, but I think the "Decoder Wheel" would be the wrong approach for implementing a time picker. 

1. Selection of an option is achieved fastest when the options are displayed vertically under each other. That is the reason why we like (vertical) drop-down menu's. Horizontal / circular menus are not easy to scan through with the eye.

2. In the "Decoder Wheel" the minute and hour dividers are not placed at the positions they would be on a real clock like this. That is why the "Decoder Wheel" looks like a rotated clock at first sight. It is difficult to locate e.g. the "5 min" area just by looking. This could perhaps be solved by changing the layout a bit.

3. For people who are used to military time (like me), the AM/PM selector will seem awkward. Preferably, they should not be confronted with such a selector.

I think we should be careful forcing the "historic watch" analogy. The circular watch was not designed with time picking in mind. Just my two cents...

Comment 33

[Marko Djukic]

What is wrong with just keeping it simple, eh? One or two vertical drop downs, case closed. Fixes the current unusable UI. Nothing wrong with bringing back 1990s feel if it means that it works for the masses and that's how it already is in oh so many other time pickers out there.

We can continue talking in the meantime about enhancements, wheels, sliders, fancythingymajiggy etc.

Comment 34

[Philipp Kewisch [:Fallen][📱📆]]

Although there is much discussion on this in different directions, if we want something cool an innovative, this could possibly be a student project.

Comment 36

[Markus Adrario [:Taraman]]

The decoder Wheel looks cool, but I think a standard Analog clock would do the trick.

Everyone (at least nearly) knows it, setting the time could be done by dragging the clock hands.

Comment 37

[Markus Adrario [:Taraman]]

A simple example for that is here:
http://www.nogray.com/time_picker.php#

Comment 38

[koyama]

(In reply to comment #37)
> A simple example for that is here:
> http://www.nogray.com/time_picker.php#

I just tried that one. With all respect I found it way too difficult to use. It required drag-drop ninja mouse skills. Also, it is probably not suitable for users without a mouse. Moreover, the presence of a AM/PM indicator wouldn't be suitable for most European users who are used to military time 00:00-23:59.

Is this topic dead? There were many good suggestions, but nothing of this has been implemented?

Comment 39

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #38)
> Also, it is probably not suitable for users without a mouse.

The timepicker only used by people with a mouse. If you don't have (or use) a mouse, you would just type the time in the box. So that's not a problem.

Comment 40

[koyama]

(In reply to comment #39)
> The timepicker only used by people with a mouse. If you don't have (or use) a
> mouse, you would just type the time in the box. So that's not a problem.

My bad...

Comment 41

[Markus Adrario [:Taraman]]

(In reply to comment #38)
> I just tried that one. With all respect I found it way too difficult to use. It
> required drag-drop ninja mouse skills. Also, it is probably not suitable for
> users without a mouse.

Sure, it should just have been an example.
I would have thought of something without AM/PM switch, this can be done otherwise.
Also I imagined something where the hour-hand is also moved if you moved the minute-hand - just like in a real clock.
Setting the clock would be the most intuitive thing to me...

Comment 42

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to comment #38)
> Is this topic dead? There were many good suggestions, but nothing of this has
> been implemented?

This is just a matter of missing time. We have quite a few other bugs to take care of. If anyone wants to implement one of these solutions, I'd appreciate :-)

Comment 43

[Markus Adrario [:Taraman]]

As I already said, I would imagine a Analog-clock-style Timepicker.

The basic features are:
- Minutes selectable in 5 Minute-Steps. (The example I linked in Comment #37 uses single minutes which is somewhat hard to handle. Anyway my idea is to put that value in a variable so it is easy changeable, maybe even make single minutes available through right mouse-button or any modifier-key.
- If you move the minute-hand, the hour-hand will be moved with it.
- you should be able to move the mouse outside the clock and continue dragging the hands.
- left click on the scale would set the hour to the corresponding position, right click set the minute.
- fully skinnable.

I was also thinking if it is easier to handle if you set the hands by moving the mouse up/down or left/right. Although this might be easier, it does not seem too intuitive.

If this outline can be agreed upon, I will come up with a mockup.

Comment 44

[Markus Adrario [:Taraman]]

I put together a working mockup.

You can find it at:
http://www.adrario.de/mozilla/Timepicker.html

There is also a newgroup post on it:
http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/31a9455dd6aba3e3#

Comment 45

[Markus Adrario [:Taraman]]

Attachment: The Source for the Mockup

This is the source code for the above mockup.

Comment 46

[Marcel Berteler]

Attachment: Pimlical TimePicker

Time Picker as found on http://www.pimlicosoftware.com/pimlicalscreenshots.html

Times are handled with a dialog that can display any number of different analog clock faces for 12 and various 24hr clock faces (a Digital clock will be added shortly). A time can be set either by tapping on the inner and outer rings, or by just directly keyboarding a time value. Timezones are handled - in this case the event is at 5pm in its native time zone, but will display at 8pm based upon the current timezone settings. Times can be entered either as the native time in that appointment's timezone, or as an adjusted time in the current timezone. A duration button allows a time to be set as an duration offset from another time (for example, setting the end time to 4 1/2 hours after the start time).

Comment 47

[Markus Adrario [:Taraman]]

The Mockup is updated.

for location see comment #44

Additional information in Newsgroup:
http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/4db728b111cd9ff9

Comment 49

[Nathan Murphree]

As a North American (US) user, I can also relate to those complaining about the 24hr format selection. It isn't an issue of understanding it, it's an issue of time waste for those of us that don't ever use it.

In all other calendaring applications I have used so far, for us en-US users, the format has been as such;

Drop down lists, with the following choices:

---------    ------    ------
| 1:00  |    | 00 |    | AM |
| 2:00  |    | 15 |    | PM |
| 3:00  |    | 30 |    ------
| 4:00  |    | 45 |
| 5:00  |    ------
| 6:00  |
| 7:00  |
| 8:00  |
| 9:00  |
| 10:00 |
| 11:00 |
| 12:00 |
---------

Philipp, I can understand that you do not like them, but I believe for most, this is an issue of "If it isn't broke, don't fix it....."

In closing, thank you for all the hard work you guys do to make Lightning, and subsequently, calendaring in Thunderbird, a reality and great experience.

Comment 50

[Nathan Murphree]

(In reply to [e-mail] from comment #49)
> As a North American (US) user, I can also relate to those complaining about
> the 24hr format selection. It isn't an issue of understanding it, it's an
> issue of time waste for those of us that don't ever use it.
> 
> In all other calendaring applications I have used so far, for us en-US
> users, the format has been as such;
> 
> Drop down lists, with the following choices:
> 
> ---------    ------    ------
> | 1:00  |    | 00 |    | AM |
> | 2:00  |    | 15 |    | PM |
> | 3:00  |    | 30 |    ------
> | 4:00  |    | 45 |
> | 5:00  |    ------
> | 6:00  |
> | 7:00  |
> | 8:00  |
> | 9:00  |
> | 10:00 |
> | 11:00 |
> | 12:00 |
> ---------
> 
> Philipp, I can understand that you do not like them, but I believe for most,
> this is an issue of "If it isn't broke, don't fix it....."
> 
> In closing, thank you for all the hard work you guys do to make Lightning,
> and subsequently, calendaring in Thunderbird, a reality and great experience.

I forgot to add;

These drop down lists also provide the option of manual entry, for when someone has 15 minutes free that you need to make an appointment with, during some oddball time slot of like 1:20p - 1:35p (I am in a company with over 15k employees, so it does happen).

Comment 51

[Josh Nijenhuis]

Here is a video showing my current implemented solution for my program, Users like it and it works well and fast.
https://www.youtube.com/watch?v=bzWmsAvQEdo

Comment 52

[Richard J. Turner]

I've found Google Calendar's new time-picker to be very intuitive. Presumably Google did some decent acceptance testing before they released it too, so I imagine most people react well to it. It's not dissimilar to the wheel mockup mentioned above, although it's cleaner in appearance. See an image here:

http://googlesystem.blogspot.co.uk/2013/05/new-google-calendar-controls-for-android.html

Comment 53

[Philipp Kewisch [:Fallen][📱📆]]

I know I uploaded the wheel mockup myself, but note that these pickers are optimized for mobile, where its easier to use due to the touch display.