5 ms·

A well-written design system is a godsend for end-user consistency, especially for people who use assistive technologies and are easily forgotten about by inexp

A well-written design system is a godsend for end-user consistency, especially for people who use assistive technologies and are easily forgotten about by inexperienced teams. It also means that teams can focus in on the problem they’re actually trying to solve, and stop obsessing over the common components. I was only around for the first six months or so of this project, but I’ve taken so much of what I’ve learnt into my current design system, and I continue to reference GDS’s continuing work as the gold standard for researched user interface patterns.

miohtama 5y ago
Some of UX guidance is really good and should be in fact part of the HTML spec. > Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong. > Do not set the inputmode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator Also, sad to realise that some of core UX features for HTML, like entering numbers, is so broken three decades later.
- chefandy 5y ago
  The whatwg.org living standard has a note: https://html.spec.whatwg.org/multipage/input.html#when-number-is-not-appropriate https://html.spec.whatwg.org/multipage/input.html#when-numbe... > The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).
  - chefandy 5y ago
    However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful. If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases. I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.
    - miohtama 5y ago
      <input type=“strictly-speaking-not-a-number”>
      - chefandy 5y ago
        <input type=“numerals-that-feel-more-qualitative-tbh”>
    - madeofpalk 5y ago
      A phone number is not a number though. It's not an integer. Phone numbers can contain leading zeroes.
      - chefandy 5y ago
        I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.' People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
- naikrovek 5y ago
  a lot of web tech is broken like this, but we're all so used to it now that we don't notice unless we really try to.
- nojs 5y ago
  This is good advice in practice but I don’t think the HTML spec should be concerned with bad browser implementations. Writing semantically incorrect HTML in order to coax the browser to behave in a certain way should be discouraged by the spec, I would say. Instead, browser vendors should be encouraged to fix their UI.

miohtama 5y ago

Some of UX guidance is really good and should be in fact part of the HTML spec. > Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong. > Do not set the inputmode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator Also, sad to realise that some of core UX features for HTML, like entering numbers, is so broken three decades later.

chefandy 5y ago
The whatwg.org living standard has a note: https://html.spec.whatwg.org/multipage/input.html#when-number-is-not-appropriate https://html.spec.whatwg.org/multipage/input.html#when-numbe... > The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).
- chefandy 5y ago
  However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful. If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases. I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.
  - miohtama 5y ago
    <input type=“strictly-speaking-not-a-number”>
    - chefandy 5y ago
      <input type=“numerals-that-feel-more-qualitative-tbh”>
  - madeofpalk 5y ago
    A phone number is not a number though. It's not an integer. Phone numbers can contain leading zeroes.
    - chefandy 5y ago
      I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.' People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
naikrovek 5y ago
a lot of web tech is broken like this, but we're all so used to it now that we don't notice unless we really try to.
nojs 5y ago
This is good advice in practice but I don’t think the HTML spec should be concerned with bad browser implementations. Writing semantically incorrect HTML in order to coax the browser to behave in a certain way should be discouraged by the spec, I would say. Instead, browser vendors should be encouraged to fix their UI.