4 ms·

I have to deal with exactly this issue at work on a project that emulates spreadsheet behavior for number formatting. I learned immediately that you have to for

by pault 8y ago

I have to deal with exactly this issue at work on a project that emulates spreadsheet behavior for number formatting. I learned immediately that you have to format on blur, because anything you do to the input value while the user is typing will move their cursor to the end of the input, and no amount of clever prediction will put it back in the right place in all cases. Always format on blur unless you want your users to hate your app.

Zarel 8y ago
You can detect where the cursor is before editing the input value, and place it in the correct place afterwards. This is a pretty basic trick used in many different places, including by Cleave itself.
- pault 8y ago
  I think my comment has been validated by the dozens of comments here complaining about broken inputs. I didn't say it was impossible; the basic trick only works in simple cases and the edge cases are numerous. If I implement a feature and it causes even one person to bounce, it's a failure.
  - Zarel 8y ago
    Well, yeah, Cleave.js isn't a very usable example, as the dozens of comments are proving. But it proves that it's _possible_. Your comment is saying that it's impossible: > no amount of clever prediction will put it back in the right place in all cases If you're instead changing your argument to say that it's impossible to do _well_, that's a different argument which I also disagree with: most implementations of tab-completion definitely have more fans than opponents. Not to mention keyboard shortcuts like Cmd+I to bold, or Cmd+B to italicize. Or even OS features like copy/paste. Many features require modifying the contents of a textbox, and it's far from impossible to do well.
    - TeMPOraL 8y ago
      Tab completion is different - it's explicit, you have to choose a completion. Bolding, italicizing, copying, pasting, etc. are all explicit actions here. This here is implicit alteration of user input, and the real question is not whether it can be done correctly (in this case, I vote for "maaaybe in theory; impossible in practice"). The real question is why do it at all? It only confuses and irritates people, which makes them make more errors and also break their flow. (Hell, it's not an issue if that's just one field on a random sign-up field of some fly-by-night shop. But those "brilliant" UX ideas tend to find their ways to software people use for work - say, managing listings in ecommerce shops. There, such ideas cause many people to lose a lot of time, and by extensions their employers to lose a ton of money.)
      - Zarel 8y ago
        Why do it at all? Because users like the feature, because the grouping numbers makes typoes easier to spot, etc. If you want to narrow it down to implicit alteration: Syntax highlighting is implicit alteration. And people love it. So are a lot of WYSIWYG features, like Enter inserting a new paragraph or a new bullet point depending on context. Or tab completion itself, in the sense that it replaces the "insert tab" feature of the Tab key. Or URLs automatically transforming into links. Explicitly with regards to Cleave.js-style auto-formatting, I personally like it (for the same reason I like syntax highlighting) and I assume many other users do too. Someone further downthread mentioned an AB test showed improved conversions: https://news.ycombinator.com/item?id=19234805 https://news.ycombinator.com/item?id=19234805
        TeMPOraL 8y ago
        > If you want to narrow it down to implicit alteration: Syntax highlighting is implicit alteration. And people love it. That's only a change of formatting that's otherwise inaccessible to the user. Effects like colors and bold/italics aren't part of the code, users can't and won't try to insert them manually - they're an extra data channel, orthogonal to what users type in, and thus free for the application to use. You want Cleave.js-style implicit? Think automatic autocorrect on Windows and MacOS. That one generates quite a lot of justified criticism - besides being a huge annoyance when dealing with proper names, brand names, peoples' names, addresses, etc., it can create life-threatening situations[0]. > Someone further downthread mentioned an AB test showed improved conversions: They did, but I honestly don't buy it - not without knowing much more about the scope and methodology of the test in question (see my response somewhere in that thread for details). "A/B test told us that" is the new "I was only following orders". -- [0] - https://twitter.com/slatestarcodex/status/944739157988974592?lang=en https://twitter.com/slatestarcodex/status/944739157988974592...
- tylerhou 8y ago
  I’ve spent tens of hours trying to create inputs which do this in an intuitive manner but I have always failed. There is always some edge case where it’s nearly impossible to determine user intent.

by pault 8y ago

Zarel 8y ago

You can detect where the cursor is before editing the input value, and place it in the correct place afterwards. This is a pretty basic trick used in many different places, including by Cleave itself.

pault 8y ago
I think my comment has been validated by the dozens of comments here complaining about broken inputs. I didn't say it was impossible; the basic trick only works in simple cases and the edge cases are numerous. If I implement a feature and it causes even one person to bounce, it's a failure.
- Zarel 8y ago
  Well, yeah, Cleave.js isn't a very usable example, as the dozens of comments are proving. But it proves that it's _possible_. Your comment is saying that it's impossible: > no amount of clever prediction will put it back in the right place in all cases If you're instead changing your argument to say that it's impossible to do _well_, that's a different argument which I also disagree with: most implementations of tab-completion definitely have more fans than opponents. Not to mention keyboard shortcuts like Cmd+I to bold, or Cmd+B to italicize. Or even OS features like copy/paste. Many features require modifying the contents of a textbox, and it's far from impossible to do well.
  - TeMPOraL 8y ago
    Tab completion is different - it's explicit, you have to choose a completion. Bolding, italicizing, copying, pasting, etc. are all explicit actions here. This here is implicit alteration of user input, and the real question is not whether it can be done correctly (in this case, I vote for "maaaybe in theory; impossible in practice"). The real question is why do it at all? It only confuses and irritates people, which makes them make more errors and also break their flow. (Hell, it's not an issue if that's just one field on a random sign-up field of some fly-by-night shop. But those "brilliant" UX ideas tend to find their ways to software people use for work - say, managing listings in ecommerce shops. There, such ideas cause many people to lose a lot of time, and by extensions their employers to lose a ton of money.)
    - Zarel 8y ago
      Why do it at all? Because users like the feature, because the grouping numbers makes typoes easier to spot, etc. If you want to narrow it down to implicit alteration: Syntax highlighting is implicit alteration. And people love it. So are a lot of WYSIWYG features, like Enter inserting a new paragraph or a new bullet point depending on context. Or tab completion itself, in the sense that it replaces the "insert tab" feature of the Tab key. Or URLs automatically transforming into links. Explicitly with regards to Cleave.js-style auto-formatting, I personally like it (for the same reason I like syntax highlighting) and I assume many other users do too. Someone further downthread mentioned an AB test showed improved conversions: https://news.ycombinator.com/item?id=19234805 https://news.ycombinator.com/item?id=19234805
      - TeMPOraL 8y ago
        > If you want to narrow it down to implicit alteration: Syntax highlighting is implicit alteration. And people love it. That's only a change of formatting that's otherwise inaccessible to the user. Effects like colors and bold/italics aren't part of the code, users can't and won't try to insert them manually - they're an extra data channel, orthogonal to what users type in, and thus free for the application to use. You want Cleave.js-style implicit? Think automatic autocorrect on Windows and MacOS. That one generates quite a lot of justified criticism - besides being a huge annoyance when dealing with proper names, brand names, peoples' names, addresses, etc., it can create life-threatening situations[0]. > Someone further downthread mentioned an AB test showed improved conversions: They did, but I honestly don't buy it - not without knowing much more about the scope and methodology of the test in question (see my response somewhere in that thread for details). "A/B test told us that" is the new "I was only following orders". -- [0] - https://twitter.com/slatestarcodex/status/944739157988974592?lang=en https://twitter.com/slatestarcodex/status/944739157988974592...
tylerhou 8y ago
I’ve spent tens of hours trying to create inputs which do this in an intuitive manner but I have always failed. There is always some edge case where it’s nearly impossible to determine user intent.