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

Dates #43

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

Dates #43

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

Comments

@govuk-design-system
Copy link
Collaborator

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

Also known as: 'Ask users for dates'

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

Anything else

@gazjoy
Copy link

@gazjoy gazjoy commented Jul 20, 2018

For the "Year" field should users be able to enter "80" if they were born in "1980" or should there be a minimum length of 4 characters imposed?

@hannalaakso
Copy link
Member

@hannalaakso hannalaakso commented Jul 20, 2018

The GOV.UK Design System does not currently contain any specific guidance about the formatting of years as numbers. The GOV.UK Styleguide does not specifically mention it either but as it only includes examples in the 4 character format so, it would appear safer to do that.

If you have a specific use case where you think there is a clear advantage for collecting years as two digit numbers please add it here as it could definitely be something to include in our guidance.

@joelanman
Copy link
Member

@joelanman joelanman commented Jul 20, 2018

It's a good question. As Hanna says we don't currently have published guidance on using 2 digits.

Personally I think it'd be nice to support users who enter 2 digits if it's unambiguous. However I guess there's always the chance that for example if someone enters 30 in year and meant to put it in month. Requiring 4 digits would avoid that.

@stevenaproctor
Copy link

@stevenaproctor stevenaproctor commented Jul 20, 2018

I agree with @hannalaakso that it is safer but it is clearer too. There are situations where ‘80’ could mean ‘1980’ or ‘1880’.

@adrianbiskupski
Copy link

@adrianbiskupski adrianbiskupski commented Nov 7, 2018

What about use of two digit format in case of days / months ? https://design-system.service.gov.uk/patterns/dates/ suggests that there should be a single digit in situations where two-digit would have 0 at the beginning. (ie. 03 07 1999)

@stevenaproctor
Copy link

@stevenaproctor stevenaproctor commented Nov 8, 2018

@adrianbiskupski The pattern is flexible so 03 07 1999 and 3 7 1999 should both be accepted. But you should not force leading zero on days and months between 1 and 9.

The leading zeroes are not needed. Like @joelanman said not adding them is "ever so slightly quicker, and more natural - dates in the real world, calendars etc, don't tend to have leading zeroes. It's a 'computery' pattern and we try and stay away from those."

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Feb 7, 2019

It was incredibly common for people to enter two digit years when I tested passports - even with the hint text. This might be related to passports showing a 2 digit year on the document - though most users will of course know their date of birth.

It was common enough I specified that we should accept two digit years - but I think I only allowed it where we thought it was unambiguous. For dates of birth of living people it's easier than years in general - no people born in 1880 are renewing their passport now.

If we hadn't done this, I think we'd have seen at least 50% of people on the page fail validation. It's not a major fail, but one we were able to avoid.


For many services if you're collecting a date in recent years, you can pretty unambiguously cast it to 4 digit year. - but this would be something the service would have to think about it. I don't think we'd want to do it by default.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Feb 7, 2019

I wonder if anyone has looked at how we might offer commonly set dates. I'm currently pondering something like this:
screenshot 2019-02-07 at 14 12 56

@selfthinker
Copy link

@selfthinker selfthinker commented Mar 20, 2019

When this pattern was in GOV.UK Elements, it had a note to explain the invalid HTML this pattern uses. It would be good to also have it in the Design System as the question about it keeps on coming up:

Note: The pattern attribute is not valid HTML for inputs where the type attribute is number. It is added deliberately to force numeric keypads on iOS devices.

@colinrotherham
Copy link

@colinrotherham colinrotherham commented Mar 20, 2019

@selfthinker To double check, the latest HTML 5.1 spec still lists pattern as an attribute that must not be specified on number fields (just in case the spec was changed).

https://www.w3.org/TR/html51/sec-forms.html#ref-for-element-attrdef-input-pattern-16

Would definitely be good to add a note that we're non-standard here for a reason.

@ChazUK
Copy link

@ChazUK ChazUK commented Apr 22, 2019

Just a small point that the example given for Date of Birth contradicts the autocomplete information that is given below it.

@amyhupe
Copy link
Contributor

@amyhupe amyhupe commented Apr 23, 2019

Hey @ChazUK – could you clarify how it does that? Thanks

@ChazUK
Copy link

@ChazUK ChazUK commented Apr 23, 2019

@amyhupe I haven't delved to far into autocomplete before but my instinct tells me that it works on the name attribute of the input field. In the example code given for Date of Birth https://design-system.service.gov.uk/patterns/dates#asking-for-memorable-dates, the input fields are given the prefix dob, whilst in the section below that states autocomplete should be used for Date of Birth the fields are prefixed with bday https://design-system.service.gov.uk/patterns/dates#use-the-autocomplete-attribute-when-asking-for-a-date-of-birth

It might be a small point but just something I spotted.

@amyhupe
Copy link
Contributor

@amyhupe amyhupe commented Apr 23, 2019

Hi @ChazUK — thanks for explaining.

Just to clarify, the dob prefixes are used on the id and name attributes, which aren't part of the autocomplete functionality.

The autocomplete attribute uses the bday prefix as the guidance specifies. I hope that makes sense but please let me know if not.

Thanks

@ChazUK
Copy link

@ChazUK ChazUK commented Apr 23, 2019

My bad! Just seen that the example does give that.

Thanks

@peteryates
Copy link

@peteryates peteryates commented Nov 10, 2019

Are there any prior examples of how people are capturing fuzzy dates? In the Design System docs it says

For example, allow users to enter ‘December 2017’ for a field that says ‘the date you lost your passport’.

I assume people aren't following this to the letter and offering a text field then having to deal with the aftermath. After a request from one of our DfE teams we've opted to use the regular date pattern but omit the day, like this. It seems like a sensible approach, would be nice to see if there are others too.

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Nov 11, 2019

We do exactly what you suggest: use the normal pattern without the day number. It's simple but isn't a solution in all cases:

  • Users who know the exact date sometimes put the day number in the first field.

  • A reduction in precision isn't the same as a reduction in accuracy. Users still want to let us know that dates aren't necessarily accurate.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Nov 11, 2019

@peteryates GOV.UK uses 'fuzzy dates' on some of the finders (example here)
Screenshot 2019-11-11 at 10 25 44

On my service I added a details link to expand a more fuzzy date:
Screenshot 2019-11-11 at 10 27 12

So far it's been through one round. We didn't test it explicitly, but I think most / all participants mentioned it and seemed clear on the purpose.


One thing that's not stated, is that I feel services should know that the date they've been given is approximate. I recall a service from a few years ago that whilst it asked for the approx date, stored an exact date as a result, and then kicked off all sorts of legal things about that specific date that the user didn't even choose.

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Dec 4, 2019

There's a number of discussions here about what we allow users to enter, but I'm wondering about how we should play back dates a user has previously input or selected.

(1) a user enters the date 1st Jan 2000 as '01' in the day field, '01' in the month field and '2000' in the year field. On a subsequent CYA page, should we play that back to the user exactly as they input it (e.g. 'Date of payment: 01/01/2000'), or strip out the zeroes (e.g. 'Date of payment: 1/1/2000')? The latter obviously looks better, but it isn't what the user literally entered and date guidance seems to suggest we shouldn't assume what the user means when it comes to entering dates.

(2) if a CYA page has a mix of date styles - for example, one line on the CYA page replays the date as '1/1/2000' and another line replays a quarter date chosen by radio button as '1 Jan to 31 Mar 2019' - do we accept this as is or should we be looking rejig the dates to a matching format e.g. change the '1/1/2000 to '1 Jan 2000' so it matched the '31 Mar 2019' format?

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Dec 4, 2019

@jonathaninch I'd suggest when displaying date you use the gov.uk house style for dates.

So in this case it would be 1 January 2000. This is also good as it would help users spot if they've transposed days and months.

@R-Derby
Copy link

@R-Derby R-Derby commented Jan 10, 2020

I've been working on a service that has been testing with screen reader users. We discovered that users who skipped the hint text got confused as to how to enter the date.

"Do I type it as letters or numbers, like 'January' or 'JAN' or '01', 'Monday' or '06'?"

Did not see these issues with the user when they did not skip the hint, that includes an example.
To help users that skipped the hint we have added a visually hidden content of " in numbers" to the labels.

<label class="govuk-label govuk-date-input__label" for="passport-issued-day">
            Day<span class="govuk-visually-hidden"> in numbers</span>
          </label>

Currently still testing.

@36degrees
Copy link
Member

@36degrees 36degrees commented Jan 10, 2020

@R-Derby can you check whether the hint text is associated correctly with the fieldset using aria-describedby? If that relationship is set up correctly the hint text should be read by the screen reader when the first date field is focused.

@R-Derby
Copy link

@R-Derby R-Derby commented Jan 16, 2020

@36degrees Thanks I've feed that backs the development team.
The user behaviour we had seen was to tab manually very quickly. In some cases even before the H1 would end.

Still testing

@edwardhorsford

This comment has been hidden.

@36degrees

This comment has been hidden.

@edwardhorsford

This comment has been hidden.

@meg-thomas
Copy link

@meg-thomas meg-thomas commented Nov 25, 2020

For 'send documents for a customs check' we wanted to have hint text where example day was >13 and month <9, but we also wanted to show an example date that would not cause an error if entered - so the date would need to be in the past, and ideally be very recent (within the last month).

We have settled on showing the 23rd of the previous month as the example, and for months when the previous month contains 2 digits, showing the 23rd September (23 9 2020).

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

Successfully merging a pull request may close this issue.

None yet