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

Telephone numbers #101

Open
govuk-design-system opened this issue Jan 15, 2018 · 33 comments
Open

Telephone numbers #101

govuk-design-system opened this issue Jan 15, 2018 · 33 comments

Comments

@govuk-design-system
Copy link
Collaborator

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

Telephone numbers

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

image

Contributors

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (Agreed) Jan 15, 2018
@timpaul timpaul moved this from Agreed to In progress in GOV.UK Design System Community Backlog Mar 5, 2018
@timpaul timpaul self-assigned this Mar 5, 2018
@timpaul
Copy link
Contributor

@timpaul timpaul commented Mar 5, 2018

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?

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 5, 2018

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.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 5, 2018

@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).

@timpaul
Copy link
Contributor

@timpaul timpaul commented Mar 13, 2018

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?

@timpaul
Copy link
Contributor

@timpaul timpaul commented Mar 13, 2018

@quis from the GOV.UK Notify team has added extra spacing between numbers in telephone number fields, to help users read them: alphagov/notifications-admin#1545

@quis
Copy link
Member

@quis quis commented Mar 13, 2018

@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.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 14, 2018

@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.

@timpaul
Copy link
Contributor

@timpaul timpaul commented Mar 16, 2018

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?

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 16, 2018

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.

@quis
Copy link
Member

@quis quis commented Mar 16, 2018

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.

@timpaul
Copy link
Contributor

@timpaul timpaul commented Mar 16, 2018

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.

@govuk-design-system
Copy link
Collaborator Author

@govuk-design-system govuk-design-system commented Mar 29, 2018

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)
@timpaul
Copy link
Contributor

@timpaul timpaul commented Apr 9, 2018

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:
image

This enhancement has been proposed here

@timpaul
Copy link
Contributor

@timpaul timpaul commented Apr 13, 2018

OK, I've updated the pattern and examples and hopefully addressed the issues raised by the working group.

The new version:

  • 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.

@ignaciaorellana
Copy link
Contributor

@ignaciaorellana ignaciaorellana commented May 1, 2018

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."
@timpaul
Copy link
Contributor

@timpaul timpaul commented Jun 4, 2018

I have implemented the recommendations from the design review above. You can preview the guidance here

@36degrees
Copy link
Member

@36degrees 36degrees commented Jun 12, 2018

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.

@frankieroberto
Copy link

@frankieroberto frankieroberto commented Jun 14, 2018

@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).

@ZabeAziz
Copy link

@ZabeAziz ZabeAziz commented Nov 28, 2018

As requested sharing international phone number pattern :)
international phone numbers

@amyhupe
Copy link
Contributor

@amyhupe amyhupe commented Feb 12, 2019

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.

image

Example of handling international phone numbers from Amazon

image

@robinwhittleton
Copy link

@robinwhittleton robinwhittleton commented Feb 24, 2019

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?

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Feb 24, 2019

@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.

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Jul 9, 2019

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.

@joelanman
Copy link
Member

@joelanman joelanman commented Jul 9, 2019

Google Trends seems to show 'phone' being the main term:
graph showing 'phone' more popular than 'telephone'

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Jul 9, 2019

Google Trends seems to show 'phone' being the main term:
graph showing 'phone' more popular than 'telephone'

Cheers Joe - hadn't thought about trying GT.

Maybe worth considering changing the content for the (tele)phone pattern?

@36degrees
Copy link
Member

@36degrees 36degrees commented Jul 9, 2019

It'd probably make sense to keep this in sync with the content style guide which currently uses 'telephone number'?

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Jul 9, 2019

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'.

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Jul 9, 2019

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').
image

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Jul 15, 2019

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').
image

My preference too. We're trying 'phone' in UR sessions and will examine what users think.

@jonathaninch
Copy link

@jonathaninch jonathaninch commented Jul 15, 2019

9dfa25ae93b08c4fd48616cd05829a68

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'.

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Sep 11, 2019

Can we update the guidance to recommend the use of 'phone' rather than 'telephone'? Can we update the examples to match that?

@CSTDev
Copy link

@CSTDev CSTDev commented Mar 9, 2020

On Do not display telephone numbers as links on devices that cannot make calls

We've found that Chrome on Android and iOS do not detect phone numbers and make them links, which is a large portion of the market. Also a number of users do have applications that can make phone calls from desktops. Not having the link seems to be more of a hindrance than the popup asking which application to use for users who don't have means to call from their devices.

@rachel-robson
Copy link

@rachel-robson rachel-robson commented Jan 27, 2021

Hello,

I have seen some designers struggling with this piece of guidance in the pattern:
"Explain why you need a telephone number
Tell users why you might contact them and when."

The pattern isn't clear where this information should be on a page asking for a telephone number.

It doesn't seem right that it's part of the hint text, as the hint needs to be direct reference to what the user is entering into the input field.

Would it be best if information on how the phone number will be used was it's own paragraph, separate to the hint text and input field?

Could there be some elaboration on that within the pattern guidance?

Thanks.

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