Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date input #42

Open
govuk-design-system opened this issue Jan 12, 2018 · 39 comments
Open

Date input #42

govuk-design-system opened this issue Jan 12, 2018 · 39 comments

Comments

@govuk-design-system
Copy link
Collaborator

@govuk-design-system govuk-design-system commented Jan 12, 2018

Use this issue to discuss this component in the GOV.UK Design System.

Anything else

Related to the 'date picker' component issue

@davehaigh
Copy link

@davehaigh davehaigh commented Jul 13, 2018

Consider how some users might be entering a date from reading it off material where it's displayed as letters. e.g. a passport.

so consider allowing various formats for month e.g. 3, 03, MAR and MARCH

in our testing we see users enter months as numbers

Loading

@manalishi79
Copy link

@manalishi79 manalishi79 commented Aug 1, 2018

There used to be documentation with this component explaining a hack to make inputs work as users expected in iOS (specifically activating the numeric keyboard on number inputs). Is this still relevant? I notice it's not in the current page

Loading

@36degrees
Copy link
Member

@36degrees 36degrees commented Aug 2, 2018

There used to be documentation with this component explaining a hack to make inputs work as users expected in iOS (specifically activating the numeric keyboard on number inputs). Is this still relevant? I notice it's not in the current page

Hi Paul,

It's still relevant – I believe that guidance was removed because we are now providing code examples, which we were not able to do when this content was in the service manual, and so it was more important to document 'implementation details' like that.

The code examples on the date input all use the pattern="[0-9]*" attribute, which triggers the keyboard on iOS.

Loading

@charge-valtech
Copy link

@charge-valtech charge-valtech commented Aug 22, 2018

Testing the "Apply for a Blue Badge" service. We saw two users with Voiceover on iOS run into issues when entering their date of birth. The first user expected it to auto-tab, getting stuck in the day field and then had issues getting back into the month field. The second user wasn't sure of what to do after entering the day, they said “I didn’t hear that one. Do I have to put dot there for month? Oh I have to go, ok. I’ve just done the day, and then” he then tried to find the dot button and gets stuck in the International keyboard, swiping the screen he finds year… swipes the screen until he finds the month input “I just want to go to month”.

Loading

@Soundman32
Copy link

@Soundman32 Soundman32 commented Oct 8, 2018

I don't think the documentation specifically shows how to display a formatted date. It has "31 3 1980" in the examples, but this is not specifically spelt out in date patterns or a-z style guide. One of the reasons this has come up is that in my 30 years of non-government development, I've never come across a date format (anywhere in the world) where spaces are the separator!

Loading

@jfhector
Copy link

@jfhector jfhector commented Oct 23, 2018

Hello all. I'd like to understand why the text input based date picker is more usable / accessible than more a select element, or a calendar. Could you tell me or point me in the right direction?

I remember that there's been usability findings pointing to that direction, but it'd help me to understand what the these findings so I can be convinced myself and convince colleagues. Is there an article / blog post anywhere recapping on this?

(Thanks for the excellent work on the design system and its documentation).

Loading

@joelanman
Copy link
Member

@joelanman joelanman commented Oct 24, 2018

Hi @jfhector that's a good question, you can read some research here:

https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/

We found similar problems with dropdowns regularly, which is why we generally recommend against them.

In terms of calendar controls, we haven't found a need when it comes to asking for a memorable date (like a date of birth), though it could be useful in other situations. The problem then is, if you use built-in browser calendars the user experience can vary wildly. If you use a custom calendar control you need to make sure it's fully accessible.

Loading

@stevenaproctor
Copy link

@stevenaproctor stevenaproctor commented Oct 24, 2018

I always point people at @alicebartlett's talk about dropdowns from 2014. https://www.youtube.com/watch?v=CUkMCQR4TpY&t=1s

Loading

@jfhector
Copy link

@jfhector jfhector commented Oct 24, 2018

Thanks a lot @joelanman @stevenaproctor , really helpful.

Loading

@joelanman
Copy link
Member

@joelanman joelanman commented Oct 25, 2018

Loading

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Nov 6, 2018

Have any prototypes / services considered a 'today' option on a date entry screen, so a user can - for example - select a 'today' radio button rather than enter data into the date fields under it? I realise it would often be inappropriate but for some services where a user can cancel / deregister on that particular day it might be helpful?

Loading

@dashouse dashouse mentioned this issue Nov 15, 2018
@HughePaul
Copy link

@HughePaul HughePaul commented Feb 7, 2019

is there a way to add attributes to date items, such as maxlength=2 and aria-required=true

Loading

@36degrees
Copy link
Member

@36degrees 36degrees commented Feb 8, 2019

is there a way to add attributes to date items, such as maxlength=2 and aria-required=true

This isn't possible using the macros at the minute – this is being tracked as an issue in the GOV.UK Frontend repo – alphagov/govuk-frontend#995.

If you're using the HTML directly, then you can add the attributes as you normally would.

Loading

@manalishi79
Copy link

@manalishi79 manalishi79 commented Feb 12, 2019

While testing this pattern in the design system with Safari and Voiceover, I've noticed that the text inputs offer a number input as an incrementable input (stepper). I can't see how this input format is described in the markup.

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Apr 1, 2019

At https://design-system.service.gov.uk/patterns/dates/ the first example is '01 08 2007' and the second example is '31 3 1980'. This is a minor inconsistency but we should fix it.

I've encountered users who believe they must use leading zeros because it's in the example on the service they're using. Even though the day and month are labelled, I think it's beneficial for the example to emphasise the distinction between day and month by using a day number that can't be a month number.

I propose the guidance is updated as follows:

  1. Day and month fields should accept input with and without leading zeros
  2. The example month number should illustrate a leading zero isn't mandatory i.e in the range 1 to 9.
  3. The example day number should illustrate it's day before month rather then month before day i.e. in the range 13 to 31
  4. The examples in the guidance should be updated to reflect the above.

Loading

@36degrees
Copy link
Member

@36degrees 36degrees commented Apr 15, 2019

Hi Terry,

That sounds like a sensible improvement. Would you be interested in creating a pull request with those changes?

I think you'd need to edit…

This line to update the first example:
https://github.com/alphagov/govuk-design-system/blob/master/src/patterns/dates/default/index.njk#L19

This line to update the last (error state) example:
https://github.com/alphagov/govuk-design-system/blob/master/src/patterns/dates/error/index.njk#L20

And add any additional guidance to the pattern itself:
https://github.com/alphagov/govuk-design-system/blob/master/src/patterns/dates/index.md.njk

Let me know if I can help at all.

Thanks,

Ollie

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Apr 16, 2019

Thanks Ollie. I've never done a pull request before but I'd like to try. I'll ask a colleague for help and give it a go. Hopefully in the next week.

Terry

Loading

@dashouse
Copy link

@dashouse dashouse commented Apr 17, 2019

Recording an issue from @andysellick (alphagov/govuk-frontend#1250) and a PR from @colinrotherham (alphagov/govuk-frontend#1257) we need to consider how this component should adapt based on available size.

While the component holds together inside a single column at our minimum supported breakpoint (320px) it will break if put inside a container smaller than this (such as a search filter panel), especially on tablet or desktop as the font size will be bigger (we are sizing the inputs with the ex unit the input width changes based on font-size).

Things to potentially consider when the space available cannot contain the 3 inputs inline:

  • Stack all 3 inputs on top of each other
  • Reduce space between inputs
  • Change the input size (It's currently slightly oversized)
  • Consider mobile breakpoint design vs limited width container design
  • Consider using flexbox / grid

Loading

@paulwaitehomeoffice
Copy link

@paulwaitehomeoffice paulwaitehomeoffice commented Apr 23, 2019

When used with a Welsh translation, the day and month fields do not have adequate spacing between them:

welsh

(Reported on Slack by Jonathan King, Content Designer at DWP)

Loading

@dashouse
Copy link

@dashouse dashouse commented Apr 23, 2019

@paulwaitehomeoffice As @colinrotheram has pointed out this example appears to be from an alternate frontend. GOV.UK Frontend behaves like this:

Screen Shot 2019-04-23 at 13 26 23

Loading

@paulwaitehomeoffice
Copy link

@paulwaitehomeoffice paulwaitehomeoffice commented Apr 23, 2019

@dashouse Ah, sorry, I missed that.

Loading

@philsherry
Copy link

@philsherry philsherry commented Dec 7, 2019

Why are we using a pattern attribute on a number input type?

The pattern attribute is an attribute of the text, tel, email, url, password, and search input types.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/pattern

Loading

@36degrees
Copy link
Member

@36degrees 36degrees commented Dec 9, 2019

@philsherry although it's technically invalid according to the specification, this was the best way to reliably trigger the numeric keyboard on older versions of iOS (< iOS 9.3 IIRC) – unfortunately using input type="number" doesn't do it by default.

Thankfully things have moved on, and we now have an issue open to update the date input to use inputmode, but we've been able to prioritise it yet.

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Mar 19, 2020

  1. The page uses '11' as a month number. I propose it's amended to bring it in line with the guidance: "If you give an example date, use 13 or more for the day and 9 or less for the month - for example ‘27 3 2007’. This helps users enter the date in the correct order and shows them they do not need to include leading zeroes." https://design-system.service.gov.uk/patterns/dates/. Is this possible?

  2. When I started looking for guidance, I didn't realise it was in two places: https://design-system.service.gov.uk/patterns/dates/ and https://design-system.service.gov.uk/components/date-input/. This meant I only followed guidance on one of the pages. Perhaps others have a similar experience. What would happen if the two pages were merged?

Loading

@tbrd
Copy link

@tbrd tbrd commented Mar 24, 2020

Has anyone, by any chance, implemented this as a react component?

Loading

@frankieroberto
Copy link

@frankieroberto frankieroberto commented Jul 24, 2020

Couple of quick questions from me:

  1. What should the error message be if the user enters a non-numeric date part (or parts), eg:

Screenshot 2020-07-24 at 16 55 11

  1. Should we try to parse known month strings like "March" or "DEC" or not?

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Jul 24, 2020

image

[Whatever it is] must have a year that is a number.

The full list of error messages we use currently is:

Day field and month field blank = "Effective date must include a day and month"
Day field and year field blank = "Effective date must include a day and year"
Day field only contains a non-digit = "Effective date must have a day that is a number"
Day field contains an unacceptable number (leading zero is acceptable) = "Effective date must have a day that is a number between 1 and 31"

Month field only is blank = "Effective date must include a month"
Month and year field blank = "Effective date must include a month and year"
Month field contains a non-digit = "Effective date must have a month that is a number"
Month field contains an unacceptable number (leading zero is acceptable) = "Effective date must have a month that is a number between 1 and 12"

Year field only is blank = "Effective date must include a year"
Year field contains a non-digit = "Effective date must have a year that is a number"

All three fields blank = "Enter an effective date"

Date not between 1 april 1993 and today = "Effective date must be between 1 April 1993 and today"
Year is not four digits = "Effective date must be between 1 April 1993 and today"

We don't translate 'March' or 'DEC'. Research has been done on this topic and I saw a presentation showing significant disadvantages. Maybe somebody can give you a reference.

Loading

@Soundman32
Copy link

@Soundman32 Soundman32 commented Jul 25, 2020

"Effective date must have a day that is a number" - why are you allowing them to type in non-numbers in the first place?

Loading

@anevins12
Copy link

@anevins12 anevins12 commented Jul 25, 2020

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Aug 27, 2020

Guidance on date input says "If there's more than one error, show the highest priority error message. In order of priority, show error messages about: missing or incomplete information; information that can't be correct (for example, the number '13' in the month field); information that fails validation for another reason" What it says appears generally applicable rather than only true for dates.

I raised this no Slack and the consensus appears to be that: (a) it's generally applicable and may belong in general guidance about error handling; and (b) it may need amending to reduce the chance of a user encountering one error message after another.

@StephenGill

Loading

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Feb 8, 2021

Mac Voice Control (and possibly Dragon?) will insert a space after each numeral you dictate. So a user will end up typing 2 0 2 1. I suspect the majority of services would then fail this when validating.

Should the guidance explicitly state that services should strip whitespace before validating? I don't think we would have caught this if it weren't for @abbott567's great Voice Dictation guide.

Loading

@philsherry
Copy link

@philsherry philsherry commented Feb 8, 2021

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Apr 9, 2021

The example on https://design-system.service.gov.uk/patterns/dates/ has hint text 'For example, 27 3 2007'.
Guidance on that page states: "If you give an example date, use 13 or more for the day and 9 or less for the month - for example ‘27 3 2007’. This helps users enter the date in the correct order and shows them they do not need to include leading zeroes."

The example on this page has hint text: 'For example, 12 11 2007'. This is not consistent with the guidance.

  1. This inconsistency would be eliminated if we merged 'Dates' and 'Date input'. I appreciate that's not a trivial task.
  2. In the short term propose we update this page to replace 'For example, 12 11 2007' with 'For example, 27 3 2007'

Loading

@meg-thomas
Copy link

@meg-thomas meg-thomas commented Apr 28, 2021

In user research, for 'send documents for a customs check' we have had a number of users expecting the date field to auto-tab, and the logs show it is one of the fields where users most often encounter errors.

Our date needs to within the last 6 months, so we have dynamic hint text that always gives a valid example date, and also meets the guidance criteria of using 13 or more for the day and 9 or less for the month.

Loading

@paulwaitehomeoffice
Copy link

@paulwaitehomeoffice paulwaitehomeoffice commented Apr 28, 2021

we have had a number of users expecting the date field to auto-tab

I've had users expect that too, presumably because they've encountered other fields that do it.

I think WCAG 2.1 requires you to warn the user that you're going to auto-tab before you do it — see https://www.w3.org/WAI/WCAG21/Understanding/on-input.html

Loading

@joelanman
Copy link
Member

@joelanman joelanman commented Apr 28, 2021

might be a good experiment to implement auto tab (accessibly!) and see if the error rate changes

Loading

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Apr 28, 2021

It gets mentioned by users from time to time in my research too.

Guidance says: "Never automatically tab users between the fields of the date input because this can be confusing and may clash with normal keyboard controls." https://design-system.service.gov.uk/components/date-input/

The reason appears to be: "At the moment, we don’t know a way to implement auto-tabbing that works for all our users."
https://userresearch.blog.gov.uk/2017/04/18/why-we-care-more-about-effectiveness-than-efficiency-or-satisfaction/

Loading

@lburnett88
Copy link

@lburnett88 lburnett88 commented Aug 24, 2021

In user research today we had two people mention automatic tabbing as a preference; and another person say they prefer a date picker / calendar. The info above on tabbing is interesting; but can anyone tell me about calendar picker research?

Loading

@lfdebrux
Copy link
Member

@lfdebrux lfdebrux commented Aug 24, 2021

Hi @lburnett88, there is information about calendar/date pickers in the date picker backlog entry. I hope this helps!

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet