Saturday, August 29. 2009
Call for opinion: Widget for entering times
I recently developed (or rather redeveloped) a widget for entering times. It's basically a remake of the one you use in KOrganizer's "new event" window if you choose the starting or the ending time of an event (with a combobox-style popup to choose predefined times with a 15 minute range).
While writing such a widget there's a lot of things to consider, eg. how to check the input, which input formats to allow and what type of input to refuse. Just like the old widget the new one shows times in the time format you configured in your systemsettings. Additionally I made it accept times in plain 24h format (eg. 16:45) and military format (eg. 1645) as that's basically what the old widget already did.
Now as I live in a country where 24h format is regular, I have trouble understanding how users with a 12h time format enter times or rather what they'd expect the widget to do if they enter times. Luckily David Jarvie, the KAlarm developer, brought up the issue of "ambiguous" times, ie. times the widget could interpret in different ways. Now as I'm still unsure about how such inputs should be handled I'd like to get some 12h format user opinions on it.
What would you expect the widget to do, if you...
- ... enter "12:25"
- Accept the input and resolve it to "12:25 am"
- Accept the input and resolve it to "12:25 pm"
- Reject the input unless "am" or "pm" is appended
- Something else (please describe)
- ... enter "08:37"
- Accept the input and resolve it to "08:37 am"
- Accept the input and resolve it to "08:37 pm"
- Reject the input unless "am" or "pm" is appended
- Something else (please describe)
- ... enter "1245"
- Accept the input and resolve it to "12:45 am"
- Accept the input and resolve it to "12:45 pm"
- Reject the input unless "am" or "pm" is appended
- Something else (please describe)
- ... enter "0913"
- Accept the input and resolve it to "09:13 am"
- Accept the input and resolve it to "09:13 pm"
- Reject the input unless "am" or "pm" is appended
- Something else (please describe)
Please keep in mind that while I will consider your input thoroughly this shouldn't be understood as a "poll as to how it will be done".
I'm looking forward to hearing from you!
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Can't you make it dependent on whether the user has his time format set to 12 or 24 hours?
Yes, it will use whichever format is configured by the user (or pre-configured by the locale used).
For all the questions I think the right answer is the first.
The user is expected to fill the field if he wants to precise "pm".
The user is expected to fill the field if he wants to precise "pm".
Though I don't have an opinion for 12 hours, I agree that with 24 hours everything should resolve to a).
I also suggest that (in the 24 hour format) the following inputs should be resolved:
"745" to "7:45 am"
"11" to "11:00 am"
"3" to "3:00 am"
I also suggest that (in the 24 hour format) the following inputs should be resolved:
"745" to "7:45 am"
"11" to "11:00 am"
"3" to "3:00 am"
I'm also in a 24 h country but my thoughts on this:
In an app like KOrganizer you often have to fill out time input fields. Forcing the user to enter AM/PM everytime could quickly get annoying. Forcing the user to enter in 24 h format could be weird and ununsual for someone not used to it. Without AM/PM the time is obviously ambiguous within a 12 hour frame. Nevertheless some time values are more probable than other if you consider real world usage. 3:00 is much more likely to be a business meeting in the afternoon than in the middle of the night. This works for most people but perhaps not for say a bar or restaurant that opens in the evening. So it depends on what KOrganizer is used for. Thus, IMHO there should be only one additional application setting: Auto AM/PM detection (start of business day): The default being 8:00 AM. So, if you enter 7:30 it is interpreted at 7:30 PM. If you enter 8:45 it is being interpreted at 8:45 AM. I think this would work for a lot of people and you would only have to enter AM/PM in rare cases. I hope one additional setting wouldnt clutter the user interface of the application properties dialog too much.
In an app like KOrganizer you often have to fill out time input fields. Forcing the user to enter AM/PM everytime could quickly get annoying. Forcing the user to enter in 24 h format could be weird and ununsual for someone not used to it. Without AM/PM the time is obviously ambiguous within a 12 hour frame. Nevertheless some time values are more probable than other if you consider real world usage. 3:00 is much more likely to be a business meeting in the afternoon than in the middle of the night. This works for most people but perhaps not for say a bar or restaurant that opens in the evening. So it depends on what KOrganizer is used for. Thus, IMHO there should be only one additional application setting: Auto AM/PM detection (start of business day): The default being 8:00 AM. So, if you enter 7:30 it is interpreted at 7:30 PM. If you enter 8:45 it is being interpreted at 8:45 AM. I think this would work for a lot of people and you would only have to enter AM/PM in rare cases. I hope one additional setting wouldnt clutter the user interface of the application properties dialog too much.
I don't think this would work everywhere. After all the widget is not supposed to be solely used by KOrganizer but meant to be used by other applications as well. I think adding an extra configuration option to all of those applications would be overkill. Providing one option in systemsettings would probably "too hidden" and noone would find it.
If the widget has a 12h mode (maybe automatically set by locale) I think that number 1 should not resolve to anything - the user should be prompted to enter "am" or "pm". (on my phone alarm you only have to press they "a" or "p" key, this seems fairly intuitive to me because as soon as you press "a" it puts "am" there).
By the way 12:25 in 24h format (or 1225 military format) is the same as 12:25pm, not 12:25 am.
By the way 12:25 in 24h format (or 1225 military format) is the same as 12:25pm, not 12:25 am.
Sorry, it's not an answer to the poll as I'm in a 24h country but what about accepting input in a "12h34" form ? it's really usual in France (and maybe other country too ?) to write time like that.
I was going to suggest the same thing. Time is usually written with an h instead of a colon here.
And whatever you choose for 12 hour time entry, in a 24 hour context let the time just as the user entered it. (I assume this is what you intend to do but one never knows.
)
And whatever you choose for 12 hour time entry, in a 24 hour context let the time just as the user entered it. (I assume this is what you intend to do but one never knows.
)
The widget will use whichever format is configured in systemsettings (or the default format for your locale if you don't change it). So you can configure the format to this french format and enter times just like that.
I'm a English Canadian who, despite preferring 24 hour time, is forced to operate in a 12 hour time society. I think the most vital thing here is to not make assumptions. I certainly have had too much experience sleeping through something important after failing to check the little am/pm light on my alarm clock
For 1, I would say the safest behaviour is "c". Jan raises an interesting point, above, but I think there's too much opportunity for surprise. If the user gets used to am/pm setting itself automatically, they might stop paying attention to it, which could cause major trouble if their movie date gets scheduled for 09:00 instead of 21:00. If you've been given no hint as to which is the correct option, I think it's dangerous to start making assumptions.
Typically, leading zeros are used only for 24h times. One would almost never see (at least here in Canada) "08:37 pm" or "08:37 am". If the user took the time to type the "0, then they probably meant it. So 2 and 4 are should be "a".
3 is trickier. My gut reaction is that if you want to support military time, then do it correctly. Thus "1245" should be "b". If instead you want to treat that as a "colons are optional" setting, then the result is ambiguous and you'd have to wait for an "am/pm".
For 1, I would say the safest behaviour is "c". Jan raises an interesting point, above, but I think there's too much opportunity for surprise. If the user gets used to am/pm setting itself automatically, they might stop paying attention to it, which could cause major trouble if their movie date gets scheduled for 09:00 instead of 21:00. If you've been given no hint as to which is the correct option, I think it's dangerous to start making assumptions.
Typically, leading zeros are used only for 24h times. One would almost never see (at least here in Canada) "08:37 pm" or "08:37 am". If the user took the time to type the "0, then they probably meant it. So 2 and 4 are should be "a".
3 is trickier. My gut reaction is that if you want to support military time, then do it correctly. Thus "1245" should be "b". If instead you want to treat that as a "colons are optional" setting, then the result is ambiguous and you'd have to wait for an "am/pm".
Thanks for your suggestions. I'll certainly have to think about that.
On a sidenote, there are several time-formats which specify that leading 0, others don't. The widget will ignore a "missing" leading 0 though.
On a sidenote, there are several time-formats which specify that leading 0, others don't. The widget will ignore a "missing" leading 0 though.
B. A. B. A.
Unless otherwise specified I would assume 24-hour clock, since AM and PM don't apply to that. Perhaps rather than pop up a warning, you could have a little message below or something that highlights AM or PM as you choose, so you can see how it will be interpreted before you commit the time?
Unless otherwise specified I would assume 24-hour clock, since AM and PM don't apply to that. Perhaps rather than pop up a warning, you could have a little message below or something that highlights AM or PM as you choose, so you can see how it will be interpreted before you commit the time?
Clearly, whenever the localization says it uses the 24h format, accept the input as it is.
For 12h formats, I choose d) for all situations. Here are two suggestions of what should happen:
When done typing, say 12:25, show a drop down list with options "12:25 pm" and "12:25 am", and autoselect the first one, like when typing URLs in your browser and it suggests suitable already-known URLs.
Alternatively, when typed "12:25", do auto-completion and add "pm" but leave it highlighted to draw the user's attention to it. With a button press "a", as if you want to write "am", it changes to "am", pressing "p" changes it back to "pm".
Please, no messages, no warnings, and no not-accepting.
For 12h formats, I choose d) for all situations. Here are two suggestions of what should happen:
When done typing, say 12:25, show a drop down list with options "12:25 pm" and "12:25 am", and autoselect the first one, like when typing URLs in your browser and it suggests suitable already-known URLs.
Alternatively, when typed "12:25", do auto-completion and add "pm" but leave it highlighted to draw the user's attention to it. With a button press "a", as if you want to write "am", it changes to "am", pressing "p" changes it back to "pm".
Please, no messages, no warnings, and no not-accepting.
I agree with #11 Markus, but would, depending on application, for a diary, assume the time was in the future 12 hours, but a history of entered times could give a more probable time window (i.e. if past times entered were between 9am and 5pm, then the new time is probably in that time frame).
With the numbers (and colons) entered, I don't think you can make a sensible choice, without history or other knowledge, but you can make a easily correctable helpful guess.
Assuming business diary 9 to 5
12:25 goes to 12:25pm
08:37 goes to 8:37am
1245 goes to 12:45pm
0913 goes to 9:13am
Assuming personal diary at 6pm
12:25 goes to 12:25am
08:37 goes to 8:37pm
1245 goes to 12:45am
0913 goes to 9:13pm
Absolutely NO pop-up dialogues.
With the numbers (and colons) entered, I don't think you can make a sensible choice, without history or other knowledge, but you can make a easily correctable helpful guess.
Assuming business diary 9 to 5
12:25 goes to 12:25pm
08:37 goes to 8:37am
1245 goes to 12:45pm
0913 goes to 9:13am
Assuming personal diary at 6pm
12:25 goes to 12:25am
08:37 goes to 8:37pm
1245 goes to 12:45am
0913 goes to 9:13pm
Absolutely NO pop-up dialogues.
any entry in format
hh:mm (or) hhmm
should be interpreted as 24h format entry and converted to 12h format. With that in mind
12:15 = 12:15 pm
8:45 = 8:45 am
13:15 = 1 pm
00:15 = 12:15 am
hh:mm (or) hhmm
should be interpreted as 24h format entry and converted to 12h format. With that in mind
12:15 = 12:15 pm
8:45 = 8:45 am
13:15 = 1 pm
00:15 = 12:15 am
I know this is not exactly what you asked for, but did you take a look at the time selection widget in Sunbird/Lightning?
In pretty much everything else I find Kontact to excel Thunderbird and Sunbird/Lightning, but their time selection widget is pretty nice.
Basically you have one row (actually two) of hours and another (two) for minutes in the same popup. It looks like this then:
01h 02h 03h 04h 05h 06h 07h 08h 09h 10h 11h 12h
13h 14h 15h 16h 17h 18h 19h 20h 21h 22h 23h 24h
00m 05m 10m 15m 20m 25m
30m 35m 40m 45m 50m 55m
IMHO it's a concept that, although it would need some refining, would be quicker to enter the time.
In pretty much everything else I find Kontact to excel Thunderbird and Sunbird/Lightning, but their time selection widget is pretty nice.
Basically you have one row (actually two) of hours and another (two) for minutes in the same popup. It looks like this then:
01h 02h 03h 04h 05h 06h 07h 08h 09h 10h 11h 12h
13h 14h 15h 16h 17h 18h 19h 20h 21h 22h 23h 24h
00m 05m 10m 15m 20m 25m
30m 35m 40m 45m 50m 55m
IMHO it's a concept that, although it would need some refining, would be quicker to enter the time.
Thanks for the pointer. I'll take a look at it as soon as I find some time. Not sure if the time chooser I developed will move into that direction, but there's always room for more elaborate widgets 
I am european so I follow the 24 time, in US referred sometimes as "millitary time" (because millitary use it, it is more accurate).
So here comes my answers:
(*1.... enter 12:45*)
Why? Because 12:45 is a time of noon, what is in US (etc) a 12:45pm. It can not be 00:45 what is in US (etc) a 12:45am
(*2.... enter "08:37"*)
It would be 08:37. Because 08:37 is morning 37 minutes over 8. In US it would be 08:37am.
It can not be 20:37 what is on evening, what in US would be 08:37pm
(*3.... enter "1245"*)
I wait it will give time 12:45 what is 45 minutes over midday. Same as in US (etc) it would be 12:45pm. It would not be 00:45 what is 45 min pass midnight, same as 12:45am in US.
(*4.... enter "0913"*)
I wait it gives 09:13 time. What is 13 minutes over 9 on the morning, not time 21:13 what is on the evening. It would be in US (etc) a 09:13am.
For all questions, there is the demand it would check users lokalisation. If user clock is set to am/pm settings, it should always require the suffix and would not accept time without it.
On lokalisations (like on europe) the time would be readed exactly by the time what is typed.
0800
08.00
08:00
would be the eight on the morning.
2000
20.00
20:00
would be eight on the evening.
So here comes my answers:
(*1.... enter 12:45*)
Why? Because 12:45 is a time of noon, what is in US (etc) a 12:45pm. It can not be 00:45 what is in US (etc) a 12:45am
(*2.... enter "08:37"*)
It would be 08:37. Because 08:37 is morning 37 minutes over 8. In US it would be 08:37am.
It can not be 20:37 what is on evening, what in US would be 08:37pm
(*3.... enter "1245"*)
I wait it will give time 12:45 what is 45 minutes over midday. Same as in US (etc) it would be 12:45pm. It would not be 00:45 what is 45 min pass midnight, same as 12:45am in US.
(*4.... enter "0913"*)
I wait it gives 09:13 time. What is 13 minutes over 9 on the morning, not time 21:13 what is on the evening. It would be in US (etc) a 09:13am.
For all questions, there is the demand it would check users lokalisation. If user clock is set to am/pm settings, it should always require the suffix and would not accept time without it.
On lokalisations (like on europe) the time would be readed exactly by the time what is typed.
0800
08.00
08:00
would be the eight on the morning.
2000
20.00
20:00
would be eight on the evening.
The standard is that unless pm is specified, you assume that the time is am. So #1 is the correct choice for all of these.
Show auto completion (just like address bars etc.) of all possible solutions, so the user can pick the right one. Added bonus: remember the user's picks and sort the suggestions accordingly.
I might suggest #5: require "am" or "pm", but intelligently autocomplete it (c.f. comments #7, #11, #12):
1. if it has a leading 0 (08:37), maybe default to "am"
2. otherwise try to do something intelligent, either with the user's historical time entry pattern or perhaps just default to whatever the next 8:37 is (i.e. "am" from 8:38pm to 8:37am, "pm" otherwise)
(3. you could even have a hidden GUI-less kdeglobals setting for a few different autocomplete tactics and ask the HIG folks to see which one annoys people the least?)
1. if it has a leading 0 (08:37), maybe default to "am"
2. otherwise try to do something intelligent, either with the user's historical time entry pattern or perhaps just default to whatever the next 8:37 is (i.e. "am" from 8:38pm to 8:37am, "pm" otherwise)
(3. you could even have a hidden GUI-less kdeglobals setting for a few different autocomplete tactics and ask the HIG folks to see which one annoys people the least?)
I would expect the same thing every time. It would be set to the next time forward from the current time.
This is useful in many situations. But especially when setting alarms or appointments.
This is useful in many situations. But especially when setting alarms or appointments.
yeah, let user input the time and according to locale, give him am/pm option as buttons next to input with all that tab enter selection also possible.
that should do the trick, thanks for asking the question
that should do the trick, thanks for asking the question
I'm not sure about 1 & 2, but for 3 & 4, they should definitely be treated as 24H times, and converted to the appropriate 12H time if the user has that set.
1. ... enter "12:25"
2. Accept the input and resolve it to "12:25 pm"
2. ... enter "08:37"
1. Accept the input and resolve it to "08:37 am"
3. ... enter "1245"
2. Accept the input and resolve it to "12:45 pm"
4. ... enter "0913"
1. Accept the input and resolve it to "09:13 am"
Additionally, I would like to add:
. ... enter "9"
. Accept the input and resolve it to "09:00 am"
. ... enter "15"
. Accept the input and resolve it to "03:00 pm"
. ... enter "25"
. Reject the input
. ... enter "913"
. Accept the input and resolve it to "09:13 am"
In other words, for lack of : character:
0-23: Accept as the hour, with :00 for the minute
24-99: Reject
100-159: Accept and assume 1:00 to 1:59
160-199: Reject
200-259, 300-359, and so on: As with 100-159
2400-?: Reject
2. Accept the input and resolve it to "12:25 pm"
2. ... enter "08:37"
1. Accept the input and resolve it to "08:37 am"
3. ... enter "1245"
2. Accept the input and resolve it to "12:45 pm"
4. ... enter "0913"
1. Accept the input and resolve it to "09:13 am"
Additionally, I would like to add:
. ... enter "9"
. Accept the input and resolve it to "09:00 am"
. ... enter "15"
. Accept the input and resolve it to "03:00 pm"
. ... enter "25"
. Reject the input
. ... enter "913"
. Accept the input and resolve it to "09:13 am"
In other words, for lack of : character:
0-23: Accept as the hour, with :00 for the minute
24-99: Reject
100-159: Accept and assume 1:00 to 1:59
160-199: Reject
200-259, 300-359, and so on: As with 100-159
2400-?: Reject
3-digit times are already parsed and completed accordingly (unless they can't be parsed as a real time). I agree that parsing 1 or 2-digit numbers makes sense as well. I guess I'll integrate that, thanks!
I'm not sure this is relevant for your purpose but I prefer when there already is a value filled in so I know what format is expected.
For example it could be the current time in the locale time format.
For example it could be the current time in the locale time format.
Yes, there will be a value prefilled as that's also convenient to show the user what he's supposed to fill in.
The actual value will depend on the application using the widget, ie. KOrganizer uses 12:00pm as the default value.
The actual value will depend on the application using the widget, ie. KOrganizer uses 12:00pm as the default value.
fwiw, even those in 12hr countries get midnight and noon mixed up. I have no clue which is am and which is pm and use surrounding context to guide me.
Calendar
|
March '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
