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

121–130 of 177 posts

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

#121

Post by dzhiurgis »

dmix wrote: post #51
airstrike wrote: post #46

Earlier quoted context omitted.

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

> Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.

I feel most of these things should be solved by browsers, not designers...

Problem is for something like credit card every single browser vendor will try to plug their own service in one way or another (think Apple Pay and Android Pay).

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

#123

Post by egdod »

lolc wrote: post #103
ivanbakel wrote: post #44

Earlier quoted context omitted.

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.

Then what do you propose happens when one writes 1/3 in Javascript?

It gets promoted to a fractional type.

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

#124

Post by mc3 »

DonHopkins wrote: post #80
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!

I hate it when they have drop-down menu for entering your year of birth, so the older you are, the further you have to scroll, but only infants and toddlers can select the year they were born without scrolling. A non-numeric text field is so much easier, and you should also be able enter your birth year as Roman numerals (which is even easier for millennials).

Gen Z are the ones born on MM or later.

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

#125

Post by brlewis »

Wowfunhappy wrote: post #102
brlewis wrote: post #96

Earlier quoted context omitted.

Using the same markup for desktop and mobile means less code which usually translates to fewer bugs.

It would be the same markup. It just wouldn't do anything on desktop. Which is fine because desktops generally have physical keyboards. I apologize if you already know this, but to make sure we're on the same page: what "inputmode" does is tell phones to display the onscreen keyboard as a numpad, instead of a full set of QWERTY letters and numbers. Outside of a few edge-cases, you don't generally need that on desktop…

TBH I went on autopilot looking at MDN's browser compatibility list. Also as a user of Firefox on Android I was interested in something that works there, but type="tel" doesn't behave any better. The only advantage to not using inputmode is getting rid of an HTML validator warning, so you're right.

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

#126

Post by Izkata »

lmkg wrote: post #71
elcomet wrote: post #64

Earlier quoted context omitted.

you can add farenheihts or celcius.

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…

> The difference between two ZIP codes is nonsensical.

Not completely, there's a rough east-to-west pattern: https://d33wubrfki0l68.cloudfront.net/979d9b9012d8bbb1e4f14b...

So the difference is extremely crude geographic distance.

/evil

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

#127

Post by smcl »

roel_v wrote: post #105
BrianB wrote: post #78

Earlier quoted context omitted.

> Or remember what car websites used to look like vs what they look like now. lingscars.com ?

I love this website. Can anyone from the UK explain what a 'mutti-car' is?

If it helps, I’m from the UK and I have no idea

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

#128

Post by smcl »

numpad0 wrote: post #116
DonHopkins wrote: post #80

Earlier quoted context omitted.

I hate it when they have drop-down menu for entering your year of birth, so the older you are, the further you have to scroll, but only infants and toddlers can select the year they were born without scrolling. A non-numeric text field is so much easier, and you should also be able enter your birth year as Roman numerals (which is even easier for millennials).

Can’t you just type “1984” or “Alaska” while focused on the dropdown to select on modern browsers

Not on mobile

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

#130

Post by Dylan16807 »

fallous wrote: post #62
dmix wrote: post #51

Earlier quoted context omitted.

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

Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that…

> when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number

So what? I can't imagine any possible way it would be unclear whether someone entered a credit card number or a negative number. They have different numbers of "-" in completely different places. Am I missing something?

> I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.

That sounds like such bad usability I'd assume you were joking if the rest of your post didn't sound so serious.

Post reply on HN