18 ms·

Why the Gov.uk Design System team changed the input type for numbers

556 points by joelanman 7y ago

alexrage 7y ago
It's good to see UX design problems analyzed from a technical perspective. Designers working on the web should be proficient at understanding the medium on which they work, and look beyond generating static images to toss over the wall for implementation.
rini17 7y ago
This is another reminder that floating point numbers are just a hack that should never be used by default. We have enough CPU, memory and bandwidth that we are able to transmit/store exact representation of numeric user input, and convert it to float only when necessary, as designed by programmer.
- ivanbakel 7y ago
  Indeed. Just like 32-bit integers, having fixed size floats as the default representation of numbers with a decimal component is a bad holdover from days of limited hardware. Let programmers use floats when they have the performance analysis to justify it. Before then, it's just another kind of premature optimisation - and high level languages should be avoiding it.
  - lolc 7y ago
    Then what do you propose happens when one writes 1/3 in Javascript?
    - egdod 7y ago
      It gets promoted to a fractional type.
      - lolc 7y ago
        Ok, what would happen if one then multiplies by Math.PI?
        mafuy 7y ago
        int times float results in float. No problem, is it?
        lolc 7y ago
        Well it's a fractional type. How do fractional types behave with floats?
        dragonwriter 7y ago
        Ideally, to maintain maximal correctness, it would be in a symbolic representation until an inexact rendering was called for, but simply resorting to floats for irrationals is not entirely unreasonable though it's still a premature optimization, but not as bad as resorting to it for rationals.
        lolc 7y ago
        Maintaining symbolic values could quickly blow up. For example when using iterative methods. Are you aware of any languages doing symbolic representation with standard types? I don't see how irrationals as floats is premature optimization. If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature. Though now I do wonder how the headaches stack up against the float headaches :-) Don't get me wrong I like the idea of symbolic representation. It's just that in everyday use it seems very impractical to me. Granted, limited forms of it like the fractional type don't have the complexity problem. But in many cases things devolve to floats quickly anyway. The people that care can use libraries and deal with the complexity.
        ivanbakel 7y ago
        "could" is the operative word. How many programs do enough calculation to make the tradeoffs of floats worthwhile? Conversely, how many programs need correctness more, and get caught out by float gotcha? This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.
- rocqua 7y ago
  It would be cool if more languages had support for fixed-point fractional numbers. Rolling your own requires re-implementing display and multiplication code, which is a decent reason for people to just use floats instead.
throwaway-q2233 7y ago
Better option is graceful degradation, just Target those specific problematic UAs for the other input type.
- shakna 7y ago
  As with most accessibility problems... Checking my User Agent won't tell you how I'm interacting with the site. How do you detect I'm using NVDA? It'll still look like Firefox. Or Chrome if I'm bypassing a broken UA detection. Nowhere will you see NVDA, even though it is the problem.
- inanutshellus 7y ago
  Unless I'm missing something, the graceful degradation is the `pattern="[0-9]"`. Certainly `input type="text"` is about as "degradation friendly" as you can get in HTML land...
ChrisSD 7y ago
In summary the main issue is that, according to the spec, `<input type="number">` is only for numbers that are going to be parsed into a Javascript number. It has to make sense to increment, decrement or do other numerical operations on it. It's not to be used for strings or identifiers that just so happen to be numbers, e.g. credit card numbers. I'll admit this is slightly surprising to me but it does make a certain amount of sense. The solution is to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">`.
- VBprogrammer 7y ago
  I've come across this problem a number of times. The same applies in, for example, passing IDs across in JSON where I use strings if at all possible. Even money amount are typically challenging to treat as numeric as often that drops them into a float when you shouldn't be processing money amounts as floats.
- downerending 7y ago
  One good reason for this is that for things like credit card numbers, a good interface will accept leading, trailing, or interior spaces. Sites that make me type in values in exactly their own weird format are an abomination. Site A: Ah ah ah! You put a slash in your date! No soup for you! Site B: Ah ah ah! You didn't put a slash in your date! No soup for you!
  - airstrike 7y ago
    > a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
    - dmix 7y ago
      Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense. Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
shakna 7y ago
> However the inputmode attribute is now supported by all the mobile browsers we test in. This isn't extensive, which might be a tad misleading if you don't double check. They test on Chrome & Samsung for Android, and iOS is only the one engine. And those three browsers seem to be the only mobile browsers that have implemented it. (Well, Opera Mobile as well). [0] Desktop support is also extremely spotty. This seems like it might be leaping the gun on expecting this standard to pick up the slack. Whilst they might feel the support is there for their particular audience after 2019, I wouldn't, and would suggest that you need to check your particular audience closely before following this advice for your own site. (Which is fairly generic advice, but appropriate.) [0] https://caniuse.com/#feat=input-inputmode https://caniuse.com/#feat=input-inputmode
- chrisweekly 7y ago
  Desktop support is also almost moot, though, right? What's the "desktop with virtual keyboard" use case?
  - oldmanhorton 7y ago
    Touchscreen pcs? Surface Pro users in particular would see this.
    - alkonaut 7y ago
      The fallback is a regular touch keyboard with both letters and digits. On a screen larger than a phone I think I’d prefer that to a numeric pad.
- joelanman 7y ago
  The article covers quite a few issues with type=number, including some pretty bad accessibility ones. On balance I think even if inputmode doesn't have 100% support, those users will simply get a normal keyboard, which isn't so bad. Disclaimer - I work on the team.
  - 7y ago
aglionby 7y ago
The Government Digital Service does all kinds of cool work around accessibility for both users using assistive technology and users who are less technically able. Interesting talk here from 2014 https://www.youtube.com/watch?v=CUkMCQR4TpY https://www.youtube.com/watch?v=CUkMCQR4TpY
signalsmith 7y ago
This is off-topic, but I really like the current GOV.UK (several years old now). I don't really have opinions on the visual stuff, but I find it really pleasant to use. Filing my self-assessment tax return (only required because I run a side-business) is a fantastically straightforward experience. Step-by-step information entry, pre-filled with what they already know (e.g. main employer's salary), then they give you a number at the end which you pay by card. Having done the paper version exactly once before moving over to doing them online, I feel grateful every time I see that distinctive custom font.
- jackdeansmith 7y ago
  As a US guy, I've never looked at this site before. The extreme clarity of pages like https://www.gov.uk/vat-rates https://www.gov.uk/vat-rates is really refreshing.
  - lioeters 7y ago
    Indeed, that's a nice example. I felt the design could even improve public relations. If I were a UK citizen, I'd be relieved to find the information so well-designed and presented. I've read here and there about the UK Government Digital Service, and have a very good impression. Reading a recent related article, it sounds like they have their priorities right! https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-the-future-of-digital-public-services/ https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-the-f...
    - dmix 7y ago
      The UK has long been an early adopter of proper web design for government websites. Seeing the average Canadian gov website, and hearing stories from people who've worked on some at the federal level, makes my head hurt.
      - frosted-flakes 7y ago
        The Canadian and provincial governments are getting better though. See the OSAP (Ontario Student Assistance Program) application page, which is fully mobile and vastly simplified from the hot mess it used to be. Also, just look at https://ontario.ca https://ontario.ca in general, which is clearly inspired by Gov.UK.
klingonopera 7y ago
I'm no web-dev, but shouldn't these things be sanitized server-side? In which case, except for the mobile keypad issue, all these problems would solve themselves? And shouldn't they be doing this anyway?
- jkrems 7y ago
  What makes you think they don't? But they still want good UX for entering the data.
  - klingonopera 7y ago
    Insistence on (EDIT: having used) using type=number. Given the choice of bad UI vs. (accidentally) modified data, I'd pick bad UI any day. Insistence on using number makes me suspect they require sanitation to be done client-side. EDIT: Normally, I wouldn't assume a website run by a government wouldn't be doing this, but wasn't there some scandal recently in the US about the Dems and some web-app, and that it was woefully amateuristic? Suffice to say, that has kinda changed my perception about governments and IT. Then again, "gov.uk" has a tech blog, so I'm probably misplacing my skepticism. EDIT2: Updated tense.
    - yazboo 7y ago
      The article is recommending against using type=number.
      - klingonopera 7y ago
        ...which they're only doing, after having it done.
        petepete 7y ago
        Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.
    - 7y ago
nimish 7y ago
Javascript not having proper integers strikes again! Kind of surprised they hadn't run into more issues parsing string-ids-with-numerals into numbers.
- notriddle 7y ago
  If JavaScript used 32-bit integers, then it would've just rolled over. Not much of an improvement.
globular-toast 7y ago
Using "numeric" types for strings that look like base 10 numbers is an incredibly common mistake. It's one of those mistakes that works 99% of the time, which means it can become deeply embedded in architectures. We've recently seen this problem when a database for the first time for a non-numeric system in its ids and downstream systems that converted that to an integer started to fail. My rule of thumb is that if it doesn't make sense to do arithmetic on it then it's not a number, it's probably a string.
- reggieband 7y ago
  > We've recently seen this problem when a database for the first time for a non-numeric system in its ids and downstream systems that converted that to an integer started to fail. I can add another anecdote to that list. In my case it was some code in a consuming system that expected u16 sized int which broke when the producing system increased to 32 bit sized int. I mean, no code change just the auto increment on the database finally exhausted 16 bits. Tangentially, this is why my first thought when designing a new system is to use uuid/guid stored as a string in hyphenated hexadecimal. It prevents any downstream consumer from even attempting to store it as an int. I'm now wary of things that look like int but aren't actually integers since people will often mistakenly treat them as such.
- markmark 7y ago
  They were using it to get a numeric entry pad on mobile devices because users preferred that. They knew the types weren't "numbers". Now that inputmode=”numeric” has better browser support they recommend that.
vitaliyf 7y ago
Similarly, here is your reminder than US Zip Codes aren't numbers, because many of us here in the Northeast have them start with a zero (or even two). So don't store them as integers, because Boston is 02108, not 2108. See https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes
- pwdisswordfish2 7y ago
  Some are yet to get the memo. Not so long ago, I've seen a TypeScript course that demonstrated union types with an example of representing zip codes as either strings or numbers…
- drstewart 7y ago
  My general rule is if you can't add two values together then they shouldn't be represented as number types.
  - pwdisswordfish2 7y ago
    So a temperature is a number only as long as it's expressed in kelvins?
    - elcomet 7y ago
      you can add farenheihts or celcius.
      - lmkg 7y ago
        You can meaningfully add or subtract degrees to a temperature reading, but you can't meaningfully add two readings together (unless you're averaging them!). There's a subtlety here: A temperature difference is actually a different data type than a temperature. Dates and times have similar issues: You can add 2 hours to 3 hours, and you can add 2 hours to 3 o'clock, but you can't add 2 o'clock to 3 o'clock. A better litmus test is whether you can subtract values. The difference between two times, or two dates, or two temperature readings is something that is meaningful and commonly used in everyday life. The difference between two ZIP codes is nonsensical.
gatvol 7y ago
Quite strange that propriety systems like dragon are mentioned as motivation, surely they should fix the product or standardise.
- leokennis 7y ago
  I guess that, as a government, they are required to cater for people with accessibility issues (in this case: people who cannot type but need to dictate to enter text). If you then cannot support the most popular dictating application, that’s not a good look.
  - petepete 7y ago
    This is absolutely the case. There are other areas where 'standards' aren't used because of accessibility reasons; a prime example being the HTML5 built-in validations. They just aren't reliably accessible enough across browsers/platforms. The GOV.UK Design System is extremely well thought out, there's reason and sound arguments behind every decision - and the best part is that it's all developed in the open.
ArchReaper 7y ago
EDIT: removed my inaccurate comment, misread article
- calibas 7y ago
  How is the "tel" type a solution? According to the standard (https://html.spec.whatwg.org/multipage/input.html#telephone-state-(type%3Dtel) https://html.spec.whatwg.org/multipage/input.html#telephone-...), it accepts every character except line feeds and carriage returns. Without any pattern specified, the code you posted will accept emojis as input, it's not a good choice for a numeric only field. It's also intended for phone numbers...
  - ArchReaper 7y ago
    Woops, for some reason I read the title as "Why the GOV.UK Design System team changed the input type for phone numbers" - removed my comment since it doesn't apply.
mirekrusin 7y ago
Gov UK has some great, Jakob Nielsen style UI. It’s fantastic to use, love it.
calibas 7y ago
FYI, there's a few features available with the number input type that don't work with this method. Things like min, max and step attributes.
- eat_veggies 7y ago
  min, max, and step don't make sense for things like account numbers or credit cards!
  - calibas 7y ago
    Well yes, in those cases it doesn't make sense, but the article mentions things like date fields, where you might want a min of 1 and a max of 31. It can also make sense to use step="0.1" if you need value to include tenths. Just saying there's advantages and disadvantages to each approach. I do agree with the article, their approach is better in most cases.
    - rocqua 7y ago
      In fact, the article does recommend using 'numeric' for dates!
- ulucs 7y ago
  I'm just being cheeky, but you can abuse the pattern field to enforce minimums ans maximums
maxcbc 7y ago
This is the sort of thing I love about the accessible tech team at gds. They learn something, then they share it in such an accessible way.
TazeTSchnitzel 7y ago
<input type=number> for things that are like telephone numbers and not like quantities is such a common mistake. It can be hilarious when, for example, a login form uses such a field for a Swedish personal identity number. I just need to click the up arrow ~1.996×10¹¹ times!
BurningFrog 7y ago
This number type is fine. It serves a purpose. The real problem is that there is no type for other "numeric" cases.
Fej 7y ago
Does anyone know what's going on with the Firefox implementation of inputmode, especially for Android? There isn't much on Bugzilla about it.
OisinMoran 7y ago
Really interesting article, and as with everyone else I also really admire their commitment to accessible design. One interesting this I noticed in this piece was the text (not quoted for reasons that will soon become clear): Using <input type=”text” inputmode=”numeric” pattern="[0-9]*"> allows for a degree of separation between how the user enters data (“input mode”), what the browser expects the user input to contain (type equals number), and potentially how it tries to validate it. Which has incorrectly used closing quotes and correctly used straight quotes in the same code section, and then proper opening and closing quotes in the text section. I wonder how that happened.

556 points by joelanman 7y ago

It's good to see UX design problems analyzed from a technical perspective. Designers working on the web should be proficient at understanding the medium on which they work, and look beyond generating static images to toss over the wall for implementation.

rini17 7y ago

This is another reminder that floating point numbers are just a hack that should never be used by default. We have enough CPU, memory and bandwidth that we are able to transmit/store exact representation of numeric user input, and convert it to float only when necessary, as designed by programmer.

ivanbakel 7y ago
Indeed. Just like 32-bit integers, having fixed size floats as the default representation of numbers with a decimal component is a bad holdover from days of limited hardware. Let programmers use floats when they have the performance analysis to justify it. Before then, it's just another kind of premature optimisation - and high level languages should be avoiding it.
- lolc 7y ago
  Then what do you propose happens when one writes 1/3 in Javascript?
  - egdod 7y ago
    It gets promoted to a fractional type.
    - lolc 7y ago
      Ok, what would happen if one then multiplies by Math.PI?
      - mafuy 7y ago
        int times float results in float. No problem, is it?
        lolc 7y ago
        Well it's a fractional type. How do fractional types behave with floats?
      - dragonwriter 7y ago
        Ideally, to maintain maximal correctness, it would be in a symbolic representation until an inexact rendering was called for, but simply resorting to floats for irrationals is not entirely unreasonable though it's still a premature optimization, but not as bad as resorting to it for rationals.
        lolc 7y ago
        Maintaining symbolic values could quickly blow up. For example when using iterative methods. Are you aware of any languages doing symbolic representation with standard types? I don't see how irrationals as floats is premature optimization. If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature. Though now I do wonder how the headaches stack up against the float headaches :-) Don't get me wrong I like the idea of symbolic representation. It's just that in everyday use it seems very impractical to me. Granted, limited forms of it like the fractional type don't have the complexity problem. But in many cases things devolve to floats quickly anyway. The people that care can use libraries and deal with the complexity.
        ivanbakel 7y ago
        "could" is the operative word. How many programs do enough calculation to make the tradeoffs of floats worthwhile? Conversely, how many programs need correctness more, and get caught out by float gotcha? This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.
rocqua 7y ago
It would be cool if more languages had support for fixed-point fractional numbers. Rolling your own requires re-implementing display and multiplication code, which is a decent reason for people to just use floats instead.

throwaway-q2233 7y ago

Better option is graceful degradation, just Target those specific problematic UAs for the other input type.

shakna 7y ago
As with most accessibility problems... Checking my User Agent won't tell you how I'm interacting with the site. How do you detect I'm using NVDA? It'll still look like Firefox. Or Chrome if I'm bypassing a broken UA detection. Nowhere will you see NVDA, even though it is the problem.
inanutshellus 7y ago
Unless I'm missing something, the graceful degradation is the `pattern="[0-9]"`. Certainly `input type="text"` is about as "degradation friendly" as you can get in HTML land...

ChrisSD 7y ago

In summary the main issue is that, according to the spec, `<input type="number">` is only for numbers that are going to be parsed into a Javascript number. It has to make sense to increment, decrement or do other numerical operations on it. It's not to be used for strings or identifiers that just so happen to be numbers, e.g. credit card numbers. I'll admit this is slightly surprising to me but it does make a certain amount of sense. The solution is to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">`.

VBprogrammer 7y ago
I've come across this problem a number of times. The same applies in, for example, passing IDs across in JSON where I use strings if at all possible. Even money amount are typically challenging to treat as numeric as often that drops them into a float when you shouldn't be processing money amounts as floats.
downerending 7y ago
One good reason for this is that for things like credit card numbers, a good interface will accept leading, trailing, or interior spaces. Sites that make me type in values in exactly their own weird format are an abomination. Site A: Ah ah ah! You put a slash in your date! No soup for you! Site B: Ah ah ah! You didn't put a slash in your date! No soup for you!
- airstrike 7y ago
  > a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
  - dmix 7y ago
    Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense. Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.

shakna 7y ago

> However the inputmode attribute is now supported by all the mobile browsers we test in. This isn't extensive, which might be a tad misleading if you don't double check. They test on Chrome & Samsung for Android, and iOS is only the one engine. And those three browsers seem to be the only mobile browsers that have implemented it. (Well, Opera Mobile as well). [0] Desktop support is also extremely spotty. This seems like it might be leaping the gun on expecting this standard to pick up the slack. Whilst they might feel the support is there for their particular audience after 2019, I wouldn't, and would suggest that you need to check your particular audience closely before following this advice for your own site. (Which is fairly generic advice, but appropriate.) [0] https://caniuse.com/#feat=input-inputmode https://caniuse.com/#feat=input-inputmode

chrisweekly 7y ago
Desktop support is also almost moot, though, right? What's the "desktop with virtual keyboard" use case?
- oldmanhorton 7y ago
  Touchscreen pcs? Surface Pro users in particular would see this.
  - alkonaut 7y ago
    The fallback is a regular touch keyboard with both letters and digits. On a screen larger than a phone I think I’d prefer that to a numeric pad.
joelanman 7y ago
The article covers quite a few issues with type=number, including some pretty bad accessibility ones. On balance I think even if inputmode doesn't have 100% support, those users will simply get a normal keyboard, which isn't so bad. Disclaimer - I work on the team.
- 7y ago

aglionby 7y ago

The Government Digital Service does all kinds of cool work around accessibility for both users using assistive technology and users who are less technically able. Interesting talk here from 2014 https://www.youtube.com/watch?v=CUkMCQR4TpY https://www.youtube.com/watch?v=CUkMCQR4TpY

signalsmith 7y ago

This is off-topic, but I really like the current GOV.UK (several years old now). I don't really have opinions on the visual stuff, but I find it really pleasant to use. Filing my self-assessment tax return (only required because I run a side-business) is a fantastically straightforward experience. Step-by-step information entry, pre-filled with what they already know (e.g. main employer's salary), then they give you a number at the end which you pay by card. Having done the paper version exactly once before moving over to doing them online, I feel grateful every time I see that distinctive custom font.

jackdeansmith 7y ago
As a US guy, I've never looked at this site before. The extreme clarity of pages like https://www.gov.uk/vat-rates https://www.gov.uk/vat-rates is really refreshing.
- lioeters 7y ago
  Indeed, that's a nice example. I felt the design could even improve public relations. If I were a UK citizen, I'd be relieved to find the information so well-designed and presented. I've read here and there about the UK Government Digital Service, and have a very good impression. Reading a recent related article, it sounds like they have their priorities right! https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-the-future-of-digital-public-services/ https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-the-f...
  - dmix 7y ago
    The UK has long been an early adopter of proper web design for government websites. Seeing the average Canadian gov website, and hearing stories from people who've worked on some at the federal level, makes my head hurt.
    - frosted-flakes 7y ago
      The Canadian and provincial governments are getting better though. See the OSAP (Ontario Student Assistance Program) application page, which is fully mobile and vastly simplified from the hot mess it used to be. Also, just look at https://ontario.ca https://ontario.ca in general, which is clearly inspired by Gov.UK.

klingonopera 7y ago

I'm no web-dev, but shouldn't these things be sanitized server-side? In which case, except for the mobile keypad issue, all these problems would solve themselves? And shouldn't they be doing this anyway?

jkrems 7y ago
What makes you think they don't? But they still want good UX for entering the data.
- klingonopera 7y ago
  Insistence on (EDIT: having used) using type=number. Given the choice of bad UI vs. (accidentally) modified data, I'd pick bad UI any day. Insistence on using number makes me suspect they require sanitation to be done client-side. EDIT: Normally, I wouldn't assume a website run by a government wouldn't be doing this, but wasn't there some scandal recently in the US about the Dems and some web-app, and that it was woefully amateuristic? Suffice to say, that has kinda changed my perception about governments and IT. Then again, "gov.uk" has a tech blog, so I'm probably misplacing my skepticism. EDIT2: Updated tense.
  - yazboo 7y ago
    The article is recommending against using type=number.
    - klingonopera 7y ago
      ...which they're only doing, after having it done.
      - petepete 7y ago
        Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.
  - 7y ago

nimish 7y ago

Javascript not having proper integers strikes again! Kind of surprised they hadn't run into more issues parsing string-ids-with-numerals into numbers.

notriddle 7y ago
If JavaScript used 32-bit integers, then it would've just rolled over. Not much of an improvement.

globular-toast 7y ago

Using "numeric" types for strings that look like base 10 numbers is an incredibly common mistake. It's one of those mistakes that works 99% of the time, which means it can become deeply embedded in architectures. We've recently seen this problem when a database for the first time for a non-numeric system in its ids and downstream systems that converted that to an integer started to fail. My rule of thumb is that if it doesn't make sense to do arithmetic on it then it's not a number, it's probably a string.

reggieband 7y ago
> We've recently seen this problem when a database for the first time for a non-numeric system in its ids and downstream systems that converted that to an integer started to fail. I can add another anecdote to that list. In my case it was some code in a consuming system that expected u16 sized int which broke when the producing system increased to 32 bit sized int. I mean, no code change just the auto increment on the database finally exhausted 16 bits. Tangentially, this is why my first thought when designing a new system is to use uuid/guid stored as a string in hyphenated hexadecimal. It prevents any downstream consumer from even attempting to store it as an int. I'm now wary of things that look like int but aren't actually integers since people will often mistakenly treat them as such.
markmark 7y ago
They were using it to get a numeric entry pad on mobile devices because users preferred that. They knew the types weren't "numbers". Now that inputmode=”numeric” has better browser support they recommend that.

vitaliyf 7y ago

Similarly, here is your reminder than US Zip Codes aren't numbers, because many of us here in the Northeast have them start with a zero (or even two). So don't store them as integers, because Boston is 02108, not 2108. See https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes

pwdisswordfish2 7y ago
Some are yet to get the memo. Not so long ago, I've seen a TypeScript course that demonstrated union types with an example of representing zip codes as either strings or numbers…
drstewart 7y ago
My general rule is if you can't add two values together then they shouldn't be represented as number types.
- pwdisswordfish2 7y ago
  So a temperature is a number only as long as it's expressed in kelvins?
  - elcomet 7y ago
    you can add farenheihts or celcius.
    - lmkg 7y ago
      You can meaningfully add or subtract degrees to a temperature reading, but you can't meaningfully add two readings together (unless you're averaging them!). There's a subtlety here: A temperature difference is actually a different data type than a temperature. Dates and times have similar issues: You can add 2 hours to 3 hours, and you can add 2 hours to 3 o'clock, but you can't add 2 o'clock to 3 o'clock. A better litmus test is whether you can subtract values. The difference between two times, or two dates, or two temperature readings is something that is meaningful and commonly used in everyday life. The difference between two ZIP codes is nonsensical.

gatvol 7y ago

Quite strange that propriety systems like dragon are mentioned as motivation, surely they should fix the product or standardise.

leokennis 7y ago
I guess that, as a government, they are required to cater for people with accessibility issues (in this case: people who cannot type but need to dictate to enter text). If you then cannot support the most popular dictating application, that’s not a good look.
- petepete 7y ago
  This is absolutely the case. There are other areas where 'standards' aren't used because of accessibility reasons; a prime example being the HTML5 built-in validations. They just aren't reliably accessible enough across browsers/platforms. The GOV.UK Design System is extremely well thought out, there's reason and sound arguments behind every decision - and the best part is that it's all developed in the open.

ArchReaper 7y ago

EDIT: removed my inaccurate comment, misread article

calibas 7y ago
How is the "tel" type a solution? According to the standard (https://html.spec.whatwg.org/multipage/input.html#telephone-state-(type%3Dtel) https://html.spec.whatwg.org/multipage/input.html#telephone-...), it accepts every character except line feeds and carriage returns. Without any pattern specified, the code you posted will accept emojis as input, it's not a good choice for a numeric only field. It's also intended for phone numbers...
- ArchReaper 7y ago
  Woops, for some reason I read the title as "Why the GOV.UK Design System team changed the input type for phone numbers" - removed my comment since it doesn't apply.

mirekrusin 7y ago

Gov UK has some great, Jakob Nielsen style UI. It’s fantastic to use, love it.

calibas 7y ago

FYI, there's a few features available with the number input type that don't work with this method. Things like min, max and step attributes.

eat_veggies 7y ago
min, max, and step don't make sense for things like account numbers or credit cards!
- calibas 7y ago
  Well yes, in those cases it doesn't make sense, but the article mentions things like date fields, where you might want a min of 1 and a max of 31. It can also make sense to use step="0.1" if you need value to include tenths. Just saying there's advantages and disadvantages to each approach. I do agree with the article, their approach is better in most cases.
  - rocqua 7y ago
    In fact, the article does recommend using 'numeric' for dates!
ulucs 7y ago
I'm just being cheeky, but you can abuse the pattern field to enforce minimums ans maximums

maxcbc 7y ago

This is the sort of thing I love about the accessible tech team at gds. They learn something, then they share it in such an accessible way.

TazeTSchnitzel 7y ago

<input type=number> for things that are like telephone numbers and not like quantities is such a common mistake. It can be hilarious when, for example, a login form uses such a field for a Swedish personal identity number. I just need to click the up arrow ~1.996×10¹¹ times!

BurningFrog 7y ago

This number type is fine. It serves a purpose. The real problem is that there is no type for other "numeric" cases.

Fej 7y ago

Does anyone know what's going on with the Firefox implementation of inputmode, especially for Android? There isn't much on Bugzilla about it.

OisinMoran 7y ago

Really interesting article, and as with everyone else I also really admire their commitment to accessible design. One interesting this I noticed in this piece was the text (not quoted for reasons that will soon become clear): Using <input type=”text” inputmode=”numeric” pattern="[0-9]*"> allows for a degree of separation between how the user enters data (“input mode”), what the browser expects the user input to contain (type equals number), and potentially how it tries to validate it. Which has incorrectly used closing quotes and correctly used straight quotes in the same code section, and then proper opening and closing quotes in the text section. I wonder how that happened.