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

161–170 of 177 posts

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

#161

Post by bcrosby95 »

hibbelig wrote: post #146
bcrosby95 wrote: post #135

Earlier quoted context omitted.

Yes, I'm rather glad I haven't had to deal with localizing decimal inputs, just displaying them. I have had to deal with localizing date inputs though. Ugh.

Why is this "ugh"? The way I see it, we're building software for users, and we try to make it useful for them. And part of that is trying to come up with a pleasing and easy to understand design language. And another part of it is catering to different cultures and languages. For example, afaik, the standard way Chinese dates are written is something like "2020Y02M28D" but with the Chinese characters (words) for year…

I enjoy creating software users find useful.

But it goes beyond "this is what they do". Users tend to do a wide range of things when entering dates and you kinda have to guess what they mean. Throw in guessing what localization should be used (it's not always clear) on top of that fuzzy system and it can become a frustrating experience for everyone involved.

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

#162

Post by kevin_thibedeau »

patio11 wrote: post #147
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…

A fun edge case, of the million edge cases for credit cards: If you have Japanese users, their browser/input method editor may send full-width characters by default, such as 4321 instead of 4321. You should probably honor those, but unless you wrote code to do this, you almost certainly won't. Even most Japanese sites are user-hostile here, either failing to detect them as numbers or telling the user "You wrote your…

For reference by others: You want to apply NFKC or NFKD Unicode normalization to collapse full-width Latin letters and digits to their usual form. This also widens half-width kana.

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

#163

Post by lolc »

mafuy wrote: post #139
lolc wrote: post #134

Earlier quoted context omitted.

Ok, what would happen if one then multiplies by Math.PI?

int times float results in float. No problem, is it?

Well it's a fractional type. How do fractional types behave with floats?

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

#164

Post by dmix »

frosted-flakes wrote: post #114
dmix wrote: post #52

Earlier quoted context omitted.

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.

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 in general, which is clearly inspired by Gov.UK.

All it takes is one group to do it right and everyone wants to copy them.

Good job UK, this Ontario site looks like a semi rip-off of the gov.uk sites (which is a good thing).

Everything slowly gets better online, it just takes time.

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

#165

Post by lolc »

dragonwriter wrote: post #143
lolc wrote: post #134

Earlier quoted context omitted.

Ok, what would happen if one then multiplies by Math.PI?

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.

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.

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

#166

Post by maxcbc »

kwhitefoot wrote: post #156
maxcbc wrote: post #75

Earlier quoted context omitted.

I’m biased, I used to work at GDS. The lack of a ‘login’ button is a huge issue IMHO, but the main blocker to it isn’t the tech teams, its at the ministerial/senior civil service level. The problem isn’t the button itself but the infrastructure behind it. I.e. it requires a single database of users (i.e. a national register of citizens). This needs doing, but politicians come out in hives because it involves setting…

> it involves setting up a system similar to national ID cards No it doesn't. We have a register of everyone resident or tax paying here in Norway and no ID cards. The government keeps on trying to make ID cards happen but the relevant departments always seem to be dragging their feet. You already have a national register in the UK: National Insurance numbers. The difficulty is that it is simply not properly joined u…

Its seen as setting up a system similar to national ID cards.

Weirdly National Insurance numbers are not always unique, and people can have more than one. Also while they are used by for tax and benefits (HMRC and DWP) other departments have a different ID number, the biggest being NHS numbers, military service numbers, passport numbers and driving license numbers (DHSC, MOD, Home Office, Department for Transport). So you’d need to unify it, under one of these, effectively creating a ‘National ID Number’, even if you don’t call it that it’d be spun as that by opponents (libertarians, big brother watch etc). You’re probably right in that the public probably aren't too worried about it, and would probably be appalled to see the waste that goes on as a result of it not existing. But politicians and parts of the media will get riled up by it.

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

#167

Post by Dylan16807 »

fallous wrote: post #159
Dylan16807 wrote: post #130

Earlier quoted context omitted.

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

Note that my post isn't limited to credit card inputs, nor do I say that the request for clarity is mandatory in all fields. What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer. Too many times I've had to deal with data that someone optimistically sanitized…

> Note that my post isn't limited to credit card inputs

Not your entire post, but the part about the '-' key was pretty specific and narrow-scoped.

> What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.

'explicit intent' sounds like a nice goal but asking the user inside the form is not going to give you good info, and it will very often annoy them.

> only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules

It wouldn't hurt to store the original. Even if the user told you what they meant, they might have said the wrong thing.

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

#168

Post by ivanbakel »

lolc wrote: post #165
dragonwriter wrote: post #143

Earlier quoted context omitted.

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.

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

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

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

#169

Post by DonHopkins »

mc3 wrote: post #124
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).

Gen Z are the ones born on MM or later.

OK, MMer! ;)

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

#170

Post by kwhitefoot »

maxcbc wrote: post #166
kwhitefoot wrote: post #156

Earlier quoted context omitted.

> it involves setting up a system similar to national ID cards No it doesn't. We have a register of everyone resident or tax paying here in Norway and no ID cards. The government keeps on trying to make ID cards happen but the relevant departments always seem to be dragging their feet. You already have a national register in the UK: National Insurance numbers. The difficulty is that it is simply not properly joined u…

Its seen as setting up a system similar to national ID cards. Weirdly National Insurance numbers are not always unique, and people can have more than one. Also while they are used by for tax and benefits (HMRC and DWP) other departments have a different ID number, the biggest being NHS numbers, military service numbers, passport numbers and driving license numbers (DHSC, MOD, Home Office, Department for Transport). S…

> would probably be appalled to see the waste that goes on as a result of it not existing.

There's no probably about it. I breath a sigh of relief every time I get back home to Norway after visiting family in the UK (which I left 34 years ago). So much is just simpler here.

Post reply on HN