3 ms·

Be conservative in what you send; be liberal in what you accept. Can the text {one hundred and twenty-three million, four hundred and fifty-six thousand, seven

Be conservative in what you send; be liberal in what you accept. Can the text {one hundred and twenty-three million, four hundred and fifty-six thousand, seven hundred and eighty-nine} in any language be dragged into the input field? Can I use operators? (123e6 + o1574125) -- HN removed the trigrams I was going to put in place of <o1574125>. Consistency. Be boring. Don't do anything. It depends on the context. Preferences. Honor preferences. For example, don't automatically start a separate 3D video of the underscores spaced every four Roman numeral unless that's the preference. This preview is refreshed onkeyup. Please don't do this, unless Preferences. Consider other factors, the context. Ask the people having to use this interface repeatedly, maybe your interface makes perfect sense.

herodoturtle 4y ago
Thanks for this. Agree it depends on the context. And we like boring too ^_^ In our case, it's an optional / configurable preference, so I think we check that box. Put another way, this isn't a blanket policy applied to all numeric input fields. Instead it's just for one particular input field, where large numbers are entered. Now we don't want the users to have to enter the thousands separator manually (and besides, the raw integer is ultimately what is stored too). So what we've currently got is the input field, with the formatted preview adjacent to it, kinda like so: [123456789 ] Formatted preview: 123,456,789 And as the input box is keyup'd, the formatted preview is refreshed. I personally think this strikes the right balance, but I was curious what other good solutions the folks here on HN have seen to this problem. Thanks for your comment ^_^
- fuzzfactor 4y ago
  I would de-emphasize the formatted preview, locate it further from the input field and use smaller font for instance. Computer input was never intended to have commas. Recent Microsoft Calculator versions that display (and copy/paste!) the commas are a ridiculous failure compared to the original approach. The best fonts are those where there can no confusion between 1, I, & l or O, o, & 0. If you make it big enough for someone with poor vision to be able to see without their glasses, there will be fewer mistakes too. Also for consistency make all big numbers throughout your site text comma-free to serve as something of an example.
  - herodoturtle 4y ago
    Thanks for this :-)

herodoturtle 4y ago

Thanks for this. Agree it depends on the context. And we like boring too ^_^ In our case, it's an optional / configurable preference, so I think we check that box. Put another way, this isn't a blanket policy applied to all numeric input fields. Instead it's just for one particular input field, where large numbers are entered. Now we don't want the users to have to enter the thousands separator manually (and besides, the raw integer is ultimately what is stored too). So what we've currently got is the input field, with the formatted preview adjacent to it, kinda like so: [123456789 ] Formatted preview: 123,456,789 And as the input box is keyup'd, the formatted preview is refreshed. I personally think this strikes the right balance, but I was curious what other good solutions the folks here on HN have seen to this problem. Thanks for your comment ^_^

fuzzfactor 4y ago
I would de-emphasize the formatted preview, locate it further from the input field and use smaller font for instance. Computer input was never intended to have commas. Recent Microsoft Calculator versions that display (and copy/paste!) the commas are a ridiculous failure compared to the original approach. The best fonts are those where there can no confusion between 1, I, & l or O, o, & 0. If you make it big enough for someone with poor vision to be able to see without their glasses, there will be fewer mistakes too. Also for consistency make all big numbers throughout your site text comma-free to serve as something of an example.
- herodoturtle 4y ago
  Thanks for this :-)