Time input

[dashouse]

What

A pattern for your users to specify a time or time period.

Why

It's potentially quite common for booking appointments, recording events, applying for licences

Related: Date input

[dashouse]

Research with patterns team (Temporary event notice prototype)

The patterns team included a basic time entry - we didn’t do significant work on the design, but were interested in how users used it, and will use the findings for future patterns. Our pattern looked like this:

This design did not test well.

In the scenario, participants were told they were working on an event from 6pm to midnight
Things we learnt:

• Users were often unclear on 24hr clocks or 12hr clocks.
• Some users tried to enter the range in both boxes. eg 6pm or 18:00 in one box, and 12pm in the next box.
• Lots of confusion around what midnight is - some users entering 12:00, some 00, some 24.
• Our screen reader users were excellent at entering it. They paid much more attention to the example time format.

Some takeaways for a future design:

• Make am / pm clear and explicit
• Consider a single box solution or otherwise allow for some users trying to use two boxes to provide a range
• Provide clear time formats in examples
• Possibly explore a dropdown / ui element to limit the input to range.

[dashouse]

The GOV.UK Pay team have done one round of user research (6 users) on this time picker application so far. Generally, it tested pretty well.

There was confusion with some users around how to select a 24 hour period, with some users selecting the prescribed date in both fields and selecting 00:00 in the first time field and typing 23:59 in the second time field.

We are looking at ways we can address this. It's not a big issue however.

[ghost]

We're currently trying out the following (but need a colon between hour and minute fields)

Previously we played about with using one input box with input type="time" in the markup because almost all of our users will be using smart phones.

This would bring up the time selector on the phone's UI, this way the users phone knows what preference to asking for time in (24 hour clock vs am/pm).

However we found this was too unpredictable on desktop browsers, I think Firefox asked for it in am/pm, Chrome asked in 24 hour and Safari wouldn't accept anything with a colon in it and expected the user to enter the time as '1330' for 1:30pm.

[cathydutton]

The fishing licence service lists out the available times to help users who were confused by midnight, 12:00, 00, 24 etc.

[ghost]

We're thinking about using the native time input when users are browsing on mobile and something similar to the date input when people are using desktop (Hour input, minute input select am or pm).

Has anyone ever thought about doing something similar for mobile users? Wondering how accessible mobile native input is?

[edwardhorsford]

Noticed this pattern isn't listed on the backlog page. Can it be added?

[peteryates]

We (School Experience) came across this too.

I'm leaning towards just using the standard inputs and providing a polyfill - see a demo here.

Yes, a polyfill isn't ideal, but it's only IE11 and (desktop) Safari amongst the commonly-used browsers that don't support it.

[soniaturcotte]

We (Content Publisher) have gone with a dropdown + type approach. This was to give users the ability to set more detailed times, but remove the higher risk of error by having it as an open text field, especially if a user inputs the wrong time (for them) but in a technically valid format.

A few considerations:

• AM/PM tested really well and users commented on how much they prefered it to 24hr clock. (We didn't test a 24hour version explicitly)
• The dropdown starts with 00:01am. This removes the confusion about whether it's the day before. Again, users were super positive about it.
• We also accept 24hour time if users input it in correctly, but play it back as am/pm

[terrysimpson99]

@soniaturcotte I mentioned this in a slack channel but I'll repeat it here for the benefit of github users. Did you test it with a space character to the left of 'am' or 'pm'?

[soniaturcotte]

@soniaturcotte I mentioned this in a slack channel but I'll repeat it here for the benefit of github users. Did you test it with a space character to the left of 'am' or 'pm'?

We didn't, but I can't imagine it would make a great deal of difference.

[terrysimpson99]

Thanks. I think it's better without a space. This is consistent with how to display units of measure e.g. '11 kg', some style guides, and this article:
http://overthinkingdesign.com/2015/02/how-to-write-am-and-pm/

If we create guidance on Design System, I propose:

• Make 'am' and 'pm' lower case without punctuation
• Use a space e.g. '11 am'
• Do not use leading zeros e.g. '7 am'

I'd like to see 24 hour format mentioned as an option if supported by evidence.

[fofr]

@terrysimpson99 The GOV.UK style guide doesn't use spaces between the number and am/pm:
https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style#times

[terrysimpson99]

Oh yes. Thanks for pointing that out. I'll suggest the change over there.

[terrysimpson99]

I can't find a github for https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style#times

Does anybody know what the mechanism is?

[soniaturcotte]

@terrysimpson99

Considering that all of GOV.UK has been using the style guide without a space, I’m not sure a change is warrented. What value do you think it would add ?

[terrysimpson99]

It doesn't add significant value. GDS style isn't static and is made up of many small pieces of guidance which don't add much value individually and some of which have changed. I was just sharing my thoughts on how to make it better. I know the mechanism for commenting on patterns but I don't know the mechanism for commenting on the style guide. Does anybody here know?

[amyhupe]

@terrysimpson99 this is the place to send feedback about the GOV.UK style guide or content design guidance.

[terrysimpson99]

Thanks. Done.

[meg-thomas]

We have had a number of discussions around whether or not we should use the 24 hour entry format.

• We think that most of our customs users use the 24 hour clock, as does their software. Most users will be very frequent users.
• In HMRC comms prior and post this service, we also use 24 hour clock, as do internal teams in their comms with users.
• There is a standard for playing back time - the 12 hour clock - so by presenting 24 hour time entry we are being inconsistent
• So far in research, 1 user made a mistake entering a time with this pattern- they put 12:30 in the first text box, then noticed and corrected it.
• We are unable to offer time ranges - the minutes need to be exact

[terrysimpson99]

The only guidance I'm aware of is: '5:30pm (not 1730hrs)'. See: https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style

That guidance doesn't merely express a preference or a default for the 12 hour clock. It's expressed as a ban on the 24 hour clock. Meg suggests the 24 hour clock is appropriate for customs users, it is normal in transport, healthcare, police, fire. There are a variety of ways to write guidance and that particularly piece of guidance is more emphatic than it needs to be. The guidance should be changed to eliminate the ban.

[meg-thomas]

We have now changed the time display on our service to the 24 hour clock to match our 24 hour time input. Our research showed that this is what the users are used to, and want, and it seems sensible to adhere to the industry standards. We are always playing back 4 digits, with a colon (e.g. 23:59, 02:01).

[danallenhmrc]

We (Content Publisher) have gone with a dropdown + type approach. This was to give users the ability to set more detailed times, but remove the higher risk of error by having it as an open text field, especially if a user inputs the wrong time (for them) but in a technically valid format.

A few considerations:

• AM/PM tested really well and users commented on how much they prefered it to 24hr clock. (We didn't test a 24hour version explicitly)
• The dropdown starts with 00:01am. This removes the confusion about whether it's the day before. Again, users were super positive about it.
• We also accept 24hour time if users input it in correctly, but play it back as am/pm

Is this component still in use? We are looking at an option like this with our service re: inputting optional time and would want to bring in the same code.

[terrysimpson99]

Thanks @danallenhmrc. Did you gain any insights into 12 hour clock confusions related to the two hours 1200-1259 am and 1200-1259pm? For example people will say something like 'We have a 1 hour meeting which runs from 1130am to 1230am'.

[danallenhmrc]

@terrysimpson99 from what was shared with me, our users are more familiar with the 24 hour clock (transport industry, Europe) so no such insights I'm afraid

[frankieroberto]

Here’s how the Manage teacher training service asks for time, when scheduling an interview with a candidate:

It uses:

• A single text input
• Hint text to encourage 12 hour clock with "am" or "pm" suffix
• Hint text to tell users to use "12pm for midday", as people can be unsure if midday is AM or PM.

A space, full stop or colon can be used between hours and minutes. The hours do not need to be zero-padded

There was also some debate about whether 24 hour times past midday should be accepted (12:01 to 23:59), but otherwise any times without a am or pm suffix display an error. We also debated whether 12:00am should display an error, given that it's very unlikely that an interview would be scheduled for midnight.

See time input in the design history for the service.

[anandamaryon-gov]

@frankieroberto This looks nice and simple from a UI perspective but do you have an example of the validation/regex on this? Is this being used in a live system? Thank you

[jrmedd]

Here’s how the Manage teacher training service asks for time, when scheduling an interview with a candidate:

It uses:

• A single text input
• Hint text to encourage 12 hour clock with "am" or "pm" suffix
• Hint text to tell users to use "12pm for midday", as people can be unsure if midday is AM or PM.

A space, full stop or colon can be used between hours and minutes. The hours do not need to be zero-padded

There was also some debate about whether 24 hour times past midday should be accepted (12:01 to 23:59), but otherwise any times without a am or pm suffix display an error. We also debated whether 12:00am should display an error, given that it's very unlikely that an interview would be scheduled for midnight.

See time input in the design history for the service.

@frankieroberto @anandamaryon-gov I used a similar pattern to ask for time on a project with the British Red Cross with some success (unfortunately not visible to the public) but I ended up creating a simple dependency-free package on the back of it that parses time from a range of different inputs that's quite forgiving: https://www.npmjs.com/package/user-time

We then just show that time back to the user for them to confirm we've interpreted their input properly.

[terrysimpson99]

I propose any solution allows designers to specify:

• 24 hour clock priority. It will not support indication or selection of am or pm.
• 12 hour clock priority. It indicates am or pm. It allows optional input of the characters 'am' and 'pm'. If 'am' or 'pm' is not input, it will interpret numerical values up to 1159 as 'am' and numerical values between 1201 and 2359 as 'pm'. It should interpret 1200 as midday.

I also propose

• input does not require a leading zero but tolerates it.
• input does not require a colon between hours and minutes but tolerates it
• it is a single text field

I'm open to debate on how many digits are mandatory in each version

[edwardhorsford]

@terrysimpson99 I don't think you can have both a lack of a leading zero and not having a colon. You need one or the other to be able to read a time.

I think to be robust we'd want to enforce a separator - and if not be very careful in validation.

Examples:
112 - is this 1:12 or 11:02 or 11:20?
12 - is this 12:00 or 1:20 or 1:02

Please let me know if I've misunderstood your suggestion and my examples don't apply.

[terrysimpson99]

A lack of leading zero should be interpreted the same as if a leading zero were present prior to the first digit.

Q. 112 - is this 1:12 or 11:02 or 11:20?

I would always interpret 112 the same as 0112 and 01:12 However I do agree it looks a bit odd. I was thinking more of '7:00'
However, I'm open to a fixed number of digits (ie no leading zero)

Q. 12 - is this 12:00 or 1:20 or 1:02

I would always interpret 12 the same as 1200 and 12:00
Describing the hour with just one or two digits is common 12 hour formats. It's also common in 24 hour formats (not so common in UK). I didn't suggest doing this but I'm open to it if the design is only capable of taking two digits (ie is only specifying the hour).

Specifying a colon is additional user effort because it requires a shift key on UK keyboards and is not immediately available on mobile keypads. It's worth noting that ISO 8601 does not require a separator so 23:59 and 2359 are both valid expressions.

[cristina-agramunt]

We (Content Publisher) have gone with a dropdown + type approach. This was to give users the ability to set more detailed times, but remove the higher risk of error by having it as an open text field, especially if a user inputs the wrong time (for them) but in a technically valid format.

A few considerations:

• AM/PM tested really well and users commented on how much they prefered it to 24hr clock. (We didn't test a 24hour version explicitly)
• The dropdown starts with 00:01am. This removes the confusion about whether it's the day before. Again, users were super positive about it.
• We also accept 24hour time if users input it in correctly, but play it back as am/pm

Hiya - Have you, or anybody in the blog done any accessibility testing on this pattern?! I like the solution, but Im concerned that its a very long dropdown and with so many options, it could represent an accessibility issue - but I am not a pro, so I am just curious to understand if anybody has some info. Thanks

[adamsilver]

As @frankieroberto shared above, in the ‘Manage teacher training applications’ we designed a single input for time.

While we were conscious at the beginning to forgive trivial mistakes we did further analysis and found we could allow a wider range of input formats for interview time.

[terrysimpson99]

There's a conflict:

• That example says "enter 12pm for midday"
• Content guidance says "midday (not 12 noon, noon or 12pm)". See: https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style

See also: https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

[joelanman]

@terrysimpson99 thats a style guide for what we publish, not the input we accept from users.

[terrysimpson99]

@adamsilver You mentioned https://bat-design-history.netlify.app/manage-teacher-training-applications/allowing-a-wider-range-of-input-formats-for-interview-time/

I see it says user input of '12' will be interpreted as '12am'. Can you confirm that?

[terrysimpson99]

If '12' will be interpreted as '12am' then * @cristina-agramunt 's comment "We also accept 24hour time if users input it in correctly" is not true.

[Hannah-Dryden]

Thought I'd share error messages I've used when asking for time input before as this isn't covered in current error message guidance.

This is based on 2 field input where one or both fields are missing (and it's a mandatory field) or you are only accepting either 12 hour or 24 hour clock inputs and the input isn't valid.

12 hour clock
Enter an hour between 1 and 12 and minutes between 0 and 59

24 hour clock
Enter an hour between 0 and 23 and minutes between 0 and 59

Not yet tested with users.

[querkmachine]

Gonna toot @adamsilver's horn before he gets a chance, but he wrote up a pretty nice blog post on designing time inputs here: https://adamsilver.io/blog/designing-a-time-input/

[CharlotteDowns]

We've just added some guidance on how to 'share findings about your users' with us 📝. This will help us learn more about how your users input time within your service.