Having touched adjacent technologies to this as well, I could not shake the feeling that text editing on the web, and WYSIWYG text editors especially, would be very well served by some sort of common understanding and agreement of output given certain inputs. As alluded to in the article, the devil really is in the details in this domain. When one knows what to look for, most rich text inputs really miss the mark in understanding intent and doing something reasonable on behalf of the users.
An interesting example is the recent trend to start interpreting selection of text + pasting of a link as "turn this text into a link using the URL in the clipboard". It just makes complete sense. When would I ever want it to be "please delete the selection, and instead paste the URL"? Probably not very often. This is just one tiny example, but there are lots and lots of those in text editing.
My gut feeling is a lot of the time this is all left to individual engineers to try to decipher the user intent; I would assume for the most part they either copy their peers or do a best effort guess.
What if there was some sort of test suite one could run instead? Like a large number of test cases built upon interactions with actual users.
>> the recent trend to start interpreting selection of text + pasting of a link as "turn this text into a link using the URL in the clipboard". It just makes complete sense.
Ugh, no no no no no. Modes like this are the opposite of making sense. Highlight something, and press paste - of course it is a replacement of the highlighted text, because that's what pasting does.
Now, we want highlighting something and pasting to contextually mean "insert markup specific to some markup language, after parsing what's on the clipboard and deciding that it looks like another part of that markup language." And it'll work one way on Jupyter notebooks and another on Slack and I can guarantee you that all of them will confuse my screenreader and I'll spend 5 minutes trying to fix whatever stupid web stuff just happened.
I agree, but that is generally not referred to as modes. A mode in UI is, when it switches and the inputs behave different. For example the "Insert" key is a mode. One could argue that Editing and Debugging (of code) are two different modes.
What you (and me) dislike are "assistants". It is when a UI decides upon something.
If you take close attention you can see clippy flash up and give a helping hand. /s.
If you want to delete the highlighted text, then why not press backspace or delete? Those already have the explicit action you're looking for.
>> Now, we want highlighting something and pasting to contextually mean "insert markup specific to some markup language, after parsing what's on the clipboard and deciding that it looks like another part of that markup language."
Not really sure what you're trying to say. You don't think they do this already? WYSIWYG-editors on the web almost all have normalization and sanitization built in when you paste something, and depending on where you paste the content will get merged with existing rich text blocks.
I think in general editors should be unsurprising.
If there's a general expectation of "if text is selected, and you do a WRITE_TEXT action, then the selected text is replaced with text"; and if CTRL_V is a WRITE_TEXT action; then doing CTRL_V after selecting text should replace the selected text.
Then again, the above rule already has exceptions; eg writing a parenthesis in some editors will surround the text with parentheses.
The problem here is “you can’t quickly make a link in our wysiwyg”. Screwing paste is not a correct answer to that. Let it detect that a clipboard text is a link and tooltip-hint a user that they can combine it with a selection by pressing ctrl-alt-v, or something similar. Nobody is against your easy editing, but not at the cost of a cognitive overload. I wish UI/UX designers read some books on how human mind works or how to do UI/UX at least.
>selection of text + pasting of a link as "turn this text into a link using the URL in the clipboard"
Seems like an interesting UX debate. It's a handy shortcut, but it makes "paste" modal depending on what's in the clipboard. Pasting might replace the selected text, or might link it. And because the behavior depends on whether the clipboard text "looks like" a URL, there's an element of DWIM (Do What I Mean) in there. Does it only handle http:// links? What about www.? Or mailto:? etc.
I haven't experienced the behavior described but reading it, I instantly hate it. It would differ from every other program I use.
I'd counter with there should be two different paste actions in every program: plain and smart. I almost always don't want to preserve rich formatting when I paste text. It looks like my cat walked over the keyboard while I was typing. The action to paste as plain text versus a fancier/DWIMy method is often different from program to program.
> all left to individual engineers to try to decipher the user intent
When it comes to a lot of text rendering, Unicode does specify most of it along with test suites.
While text input is really mainly two large teams: one at Microsoft and one at Apple. While they probably don't talk to each other much, they probably do wind up copying each other for the benefit of users.
I'm not really sure what open-source GUI's do, but probably mainly try to copy Microsoft+Apple.
recent trend to start interpreting selection of text + pasting of a link as "turn this text into a link using the URL in the clipboard". It just makes complete sense
I had to reread this 5 or 6 times to get the meaning, not joking. Please no, or at least use custom plugins for that and leave our generic text input alone.
An interesting example is the recent trend to start interpreting selection of text + pasting of a link as "turn this text into a link using the URL in the clipboard". It just makes complete sense. When would I ever want it to be "please delete the selection, and instead paste the URL"? Probably not very often. This is just one tiny example, but there are lots and lots of those in text editing.
My gut feeling is a lot of the time this is all left to individual engineers to try to decipher the user intent; I would assume for the most part they either copy their peers or do a best effort guess.
What if there was some sort of test suite one could run instead? Like a large number of test cases built upon interactions with actual users.