Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

technology.blog.gov.uk

Post reply on HN
Print view View original

51–60 of 177 posts

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

#51

Post by dmix »

airstrike wrote: post #46
downerending wrote: post #29

Earlier quoted context omitted.

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!

> a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?

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.

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

#52

Post by dmix »

lioeters wrote: post #43
jackdeansmith wrote: post #27

Earlier quoted context omitted.

As a US guy, I've never looked at this site before. The extreme clarity of pages like https://www.gov.uk/vat-rates is really refreshing.

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-t…

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.

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

#53

Post by drstewart »

vitaliyf wrote: post #30

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

My general rule is if you can't add two values together then they shouldn't be represented as number types.

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

#54

Post by petepete »

leokennis wrote: post #49
gatvol wrote: post #42

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

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.

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.

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

#55

Post by brlewis »

downerending wrote: post #29
ChrisSD wrote: post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

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!

This may not be semantically pure, but I think type="tel" is a simple and ergonomic approach to credit card input. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

EDIT: Also more widely supported than https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

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

#56

Post by petepete »

klingonopera wrote: post #34
yazboo wrote: post #32

Earlier quoted context omitted.

The article is recommending against using type=number.

...which they're only doing, after having it done.

Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.

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

#57

Post by samatman »

pwdisswordfish2 wrote: post #31
ChrisSD wrote: post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities , not mere strings of digits . It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.

You can't entirely avoid referring to JavaScript semantics here, type="number" is for values appropriate to represent and work with as IEEE 754 doubles.

That covers a lot of ground, by design. But a 'number' it isn't.

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

#58

Post by bobthepanda »

pwdisswordfish2 wrote: post #31
ChrisSD wrote: post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities , not mere strings of digits . It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.

I mean, this could've been solved by the spec using type="quantity".

Many languages have generic, ambiguous umbrella terms, it's the sloppiness of the spec picking one.

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

#59

Post by jsjohnst »

pwdisswordfish2 wrote: post #31
ChrisSD wrote: post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities , not mere strings of digits . It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.

The spec could’ve used type=“quantity” and there wouldn’t be as much or any confusion.

Point being, blaming the language used for writing the spec, when you readily offered up a better alternative, feels misguided to me.

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

#60

Post by samatman »

vidarh wrote: post #15
joelanman wrote: post #7

Earlier quoted context omitted.

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.

Yeah, for my current work app we've just unceremoniously dropped type=number for most things, without inputmode or anything, and the experience is overall so much better even then.

I wish you'd use inputmode.

I find it vaguely unsatisfying when I'm asked to input a pure string of digits using a full keyboard on mobile. It feels half-baked, and my estimation of the quality of the software goes down.

Post reply on HN