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 · 19 comments

Comments

8 participants
@govuk-design-system
Copy link
Collaborator

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 added the candidate label Mar 5, 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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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 timpaul added the pattern label May 21, 2018

@timpaul

This comment has been minimized.

Copy link
Contributor

timpaul commented Jun 4, 2018

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

@36degrees

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

ZabeAziz commented Nov 28, 2018

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

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