govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Telephone numbers
Use this issue to discuss this pattern in the GOV.UK Design System.
Contributors
- @edwardhorsford
- @quis
- @timpaul
Hey @edwardhorsford. I'm developing this pattern (above) for telephone numbers. It's based on the guidance we have drafted in Dropbox Paper. There's nothing about validation yet though - is this anything you have knowledge of?
My sense is that validation depends on whether you accept international numbers or ones with area codes. If you don't, then it's easier to detect the right number of digits (after stripping formatting characters). If you do, you have to allow a pretty large range of digits.
In the UK I think you can reasonably easily detect mobile vs landline numbers - I don't think the same holds true for international numbers though (it definitely doesn't in the UK). Extensions also complicate the matter.
If helpful, here's a gist (I found on a blogpost somewhere) of various UK telephone formats - could be useful for unit testing.
@timpaul has asked for more comments.
Type
Suggest the input type should be tel - it's a perfect use case.
Scope of pattern
Is this about collecting phone numbers, display of phone numbers or both? If it's both, can examples of both be at the top?
Displaying the user's number as written
I'm unconvinced on the guidance to retain formatting - do we have evidence that this is important? I don't particularly mind it, but it may be quite a bit of extra work for teams to implement (storing one value but validating against another) - and it's ultimately not what's going to get stored in the database.
Services will be sanitising this data (removing whitespace / brackets, etc) - is it useful to display this sanitised value to the user?
Formatting other numbers
This is content in the content style guide - can we link out to that? Can we show some examples as well as describing it?
Other
It may be useful to call out some of the more challenging areas to think about - that we don't currently have patterns for. These include: country codes / internationalisation, extensions, weird numbers (sms shortcodes, etc).
Input masking
Rather than retaining the user's formatting, an alternative (would need to be tested) would be to swallow whitespace and special characters as they're typed and mask the input live to an agreed format. Done well, this can look really good (Stripe / Apple come to mind).
Thanks for the comments above @edwardhorsford - I've updated the draft version accordingly. We've also piloting hypothes.is as a way of capturing feedback about draft guidance - feel free to use it (it's over on the right hand side of the draft).
Our content designer Amy will start writing up the finished guidance now. Would you like to review it once it's done?
@quis from the GOV.UK Notify team has added extra spacing between numbers in telephone number fields, to help users read them: https://github.com/alphagov/notifications-admin/pull/1545
@edwardhorsford couple of points:
Displaying the user's number as written
This is a good idea.
On Notify we store the number in the database as the user gives it to us. We normalise it before we use it to send a text message, but on the frontend we play it back in the format it was provided. We’ve seen problems with people not recognising numbers played back in a different format.
Input masking
This is a bad idea, and I haven’t seen a need for it, even if it can be an ooh that’s nice moment.
It makes things harder for people typing a number in a certain way, eg typing spaces to help them keep track of their position. It makes it harder to transcribe or copy the number from another place and check that you’ve got it right.
@quis
Displaying as written
Interesting - we didn't observe that on passports. I think we stripped whitespace / brackets though, so perhaps they were still recognisable to users.
Input masking
I defer to your research here. Really interesting to hear.
Yes, thanks @quis and @edwardhorsford. Here's a question - assuming we distill the above conversation into the published guidance, how would either of you feel about the comments above then being deleted?
We're trying to decide how aggressively we should maintain the backlog. Eg. is it a verbose record of every conversation ever had, or a succinct summary of the outstanding issues?
Undecided!
I like the idea of comments / discussion living on, but right now these comments will be the first thing people read. Might a system similar to wikipedia work? where comments get archived, and only the newest are shown?
In this case these particular comments probably aren't so valuable that they need keeping, but later other discussions might well be valuable to be kept.
Loosely held opinion:
I would scope this discussion to being about adding the pattern for phone numbers.
Once the pattern is published this discussion should be closed (but not deleted). Then future revisions start as new backlog items. For example, someone could add ‘dealing with country codes’ as a new thing in the backlog. It might result in updates to the same pattern, but it’s a new discussion.
Sounds good, and close to what we'd discussed as a team. The only variation was that we keep this issue in the backlog project as an index for all issues relating to this pattern - so we'd link to them all from the top comment. It's a bit manual, but it means we'd get a kind of threaded discussion out of it. We'll try a few approaches and see what works.
Design review
This proposal was reviewed by a panel of designers from GDS, HMRC, DWP and Home Office on 22 March 2018.
The panel agreed that the pattern should not be published in the GOV.UK Design System until the following changes have been made.
Recommendations
- Provide more examples of specific error types and messages
- Give guidance on how to handle international numbers
- Provide a list of safe example international telephone numbers
- Make sure the code uses the ‘tel’ attribute
- Apply a fixed-width class to the field (once GOV.UK Frontend supports this)
In order to create an example of an international telephone number input we are likely to need to be able to add prefixes to form inputs. For example:
This enhancement has been proposed here
OK, I've updated the pattern and examples and hopefully addressed the issues raised by the working group.
- Provides more examples of specific error types and messages
- Gives guidance on how to handle international numbers
- Uses the ‘tel’ attribute
- Applies a fixed-width class to the field
The international telephone number example doesn't rely on the prefix component, so is no longer dependant on this being approved.
For validation we now reference Google's libphonenumber library rather than the GOV.UK Notify code, as this is a fully supported open source project that handles international numbers.
The only issue not addressed is 'Provide a list of safe example international telephone numbers'. As every country has it's own rules around telephone number formats there is no single example of an international telephone number. Desk research failed to find a reliable list of safe numbers for different countries.
This proposal was reviewed by a panel of designers and frontend developers from GDS, HMRC, DWP, EA and Home Office on the 26 of April, 2018. It was reviewed against the criteria for implementation Thanks to the contributor @timpaul with the support of @edwardhorsford and @quis
Design review
The panel agreed that the pattern should be published in the GOV.UK Design System after implementing the following recommendations.
Recommendations
- Explain what 'input masking' is
- For ‘Always tell users when and how they’d be contacted’. I’d like to see an example of that before it was published.
- Consider explaining why we use type:tel?
- Make the scope clearer: what it cover and what it doesn’t
- Explain that there are known gaps that will need to be developed further (so people understand this)
- Revisit some of the content to make it shorter:
- Remove negative contractions from the telephone guidance so we can follow our own advice.
- Split "It’s also not necessary - most modern mobile browsers automatically detect telephone numbers and display them as links anyway." in to 2 sentences.
- Is "If you need to mark up your telephone number as links to support a device that cannot auto-detect them, you must make sure they don’t display as links on devices that cannot make calls." necessary? It is largely the same as the heading.
- "The GOV.UK Notify team has observed some users becoming confused when presented with a reformatted version of a telephone number that they provided, for example, with the +44 country code added." is a little long. How about "The GOV.UK Notify team observed some users becoming confused when presented with a reformatted version of a telephone number they provided. For example, this happened when we added the +44 country code to the number."
I have implemented the recommendations from the design review above. You can preview the guidance here
I still find it a bit weird that we talk about presenting phone numbers (e.g. "Don’t display telephone numbers as links on devices that can’t make calls") in a section about asking users for telephone numbers – it doesn't feel like it's in the right place, as I'd imagine a lot of service teams might be displaying phone numbers (e.g. on a contact us or error page) but would never have any reason to read this particular guidance as they don't ask their user for a phone number in their service.
@36degrees there's also no guidance on how to (reliably) detect which devices can make calls, and which can't. I'm not sure that's even possible (eg a desktop browser may have an extension installed enabling calls via VOIP).
Dropbox Paper audit
On 12 February 2019 the Design System team reviewed a Dropbox Paper document discussing the Telephone numbers pattern.
The aim was to reduce the number of places containing guidance and code by:
- migrating relevant, useful content into the Design System itself
- recording important research findings in the community backlog
- removing the original Dropbox Paper page
Below is a record of the outcomes of that review.
If you need to, you can see the original Dropbox Paper content in the internet archive.
Research and examples from Dropbox Paper
The following examples were taken from the original Dropbox Paper file:
Example of handling international phone numbers from Google
Google uses a select-list combined with a country icon. It will likely introduce other problems for people who struggle with select lists. Having a default, like "UK" appears to work well and makes it obvious which it is, and how to change it.
Example of handling international phone numbers from Amazon
One of the things I remember seeing in a research presentation at GDS was deaf / hard of hearing users filling in telephone number fields that were marked as required with “Please do not call me, I’m deaf”. How does that fit into these validation plans, or should there be a note to never make telephone fields mandatory? Or a requirement to request alternative ways of realtime communication if phone calls don’t work for people?
@robinwhittleton I'd suggest more the latter - that services should offer people a range of methods to communicate with. With that said - that's a tricky one to mandate.
Genuine question - do many people still refer to 'telephones' as opposed to just 'phones'? Feels a bit old fashioned to be asking for the former to me.
Google Trends seems to show 'phone' being the main term:
Cheers Joe - hadn't thought about trying GT.
Maybe worth considering changing the content for the (tele)phone pattern?
It'd probably make sense to keep this in sync with the content style guide which currently uses 'telephone number'?
It'd probably make sense to keep this in sync with the content style guide which currently uses 'telephone number'?
Interesting that a quick search on GOV.UK shows nearly 13k references to 'telephone' but still a considerable 9k+ references to 'phone'.
Google ngram viewer searches books. It shows 'phone' dominant in US books but subdominant in UK books (although reaching parity). I'm glad this topic came up here because we use both terms and I'd like guidance on which one to choose (my vote would be for 'phone').
Google ngram viewer searches books. It shows 'phone' dominant in US books but subdominant in UK books (although reaching parity). I'm glad this topic came up here because we use both terms and I'd like guidance on which one to choose (my vote would be for 'phone').
My preference too. We're trying 'phone' in UR sessions and will examine what users think.
Searching 'phone' v 'telephone' but looking beyond 2000 (2008 seems to be as far as it will go), Google Books Ngram Viewer shows a big divergence from 2001 or so onwards, with the preference being 'phone'.