[Autoembed] UX and a11y

[Olek Nowodziński]

While the new feature is quite innovative and I really do like it, I found some UX issues worth discussing:

Double undo mechanism

At the moment, if the user pastes a link and it gets converted into an embeddable widget, they got to undo twice to get back to the initial state of the editor. The first undo step removes the widget, then the second one – the link.

However, if the user decides to change something in the contents after the first undo step, there's no way to convert the link into a widget again, unless you remove it completely and paste again. Thus the user is stuck with a link which supposed to be an embeddable content but there's no way to achieve that because the flow of the actions (state shifting) is broken.

Possible solutions:

• One–step undo: If the link is just an intermediate form of an embeddable content, a way to communicate the editor that something is supposed to be embedded (it is, isn't it?), there should be just a single undo step. CTRL+Z and both widget and the link are gone.
  • Pros: It's so simple.
  • Cons: There's no way for the user to decide if the link is supposed to be embedded or simply pasted in the content. It gets converted into embeddable widget whether they like it or not. TBH, I think this is rather the right way – if the administrator enabled the autoembed plugin, they expect such content to be embedded. It's a deliberate action. There's no need to leave an option to keep the link instead of embeddable to the users because they're not supposed to pollute the content with an intermediate data. And if they are desperate to do this anyway, there's still a possibility of using the "Source" or "Link" buttons.
• Context menu on links and embeddable widgets: Right–clicking the link which is prone to becoming an embeddable could display a context menu item like "Embed". It would do the same magic the autoembed plugin does when the link is pasted. At the same time, widgets containing embeddable content, would expose "Convert to link|Linkify|Collapse|Whatever..." context menu item, which would be an equivalent to the first undo step.
  • Prons: The flow of the actions (states) is no longer broken – users can go back and forth between the states of embeddable content (link<->widget), which means that double–undo system remains.
  • Cons: Hardly any. It could give too much freedom to the content creators, which I find rather unnecessary (explained above).

Batch autoembed

If one pastes

https://twitter.com/reinmarpl/status/573118615274315776

then it's converted into a Twitter embeddable. However pasting

https://twitter.com/reinmarpl/status/573118615274315776 https://twitter.com/reinmarpl/status/573118615274315776

is followed by no magic action. No autolink, no autoembed.

• What if the user wants to embed the entire list of tweets?
• Entire gallery of images?
• Dozens, hundreds of links to embed?
• A paragraph with a link like

  Hey, check this out: https://twitter.com/reinmarpl/status/573118615274315776
  

  ?
• Or they accidentally copied some white space like

  <WS>https://twitter.com/reinmarpl/status/573118615274315776
  

  ?

Since we support parallel embedding (there's a progress bar indicating the status of things) and we support embedding of multiple items in a row (just hold CTRL+V), which is not perfect (#13413) but it works, why not multiple items at the same time?

Possible solutions:

• Tune the RegEx mechanism to embed multiple items at the same time.
  • Pros: Simple as that.
  • Cons: Additional complexity of the code (?).
• Include a drop–down menu under the "Insert Media Embed" button (just like SCAYT), with a "Detect embeddables in selection|Whatever..." button. Such a magic button would let users select some content (i.e. 250 links pasted from the clipboard) and make them all embeddable with a single click.
  • Pros: It's a powerful tool.
  • Cons: Hardly any. It seems quite simple to implement.

TBH, I'd like to see both solutions implemented alongside, complementing each other.

Accessibility

I played a little bit with JAWS and my impression is that it could be confusing for some people that when a link is pasted it is immediately converted into something else. I wonder what is the right solution for such magic and whether there are mechanisms to notify the user about the transformation. In real life, the transformation (embed request) could take a lot of time and once the user received an audible confirmation from the synthesizer that the contents have been pasted from the clipboard (once pressed CTRL+V), they could move across the document, unaware of the transformation of the link which is yet to happen or which has just happened. WDYT?

---

EDIT: There's no context menu entry for embed widgets. There should be one to edit the widget.

[Piotrek Koszuliński]

Double undo mechanism

It's definitely imperfect, but the reason for that is that you can never know what user wants to achieve. This problem will apply to all UX-related issues of this feature.

One-step undo

I absolutely disagree about this: "the administrator enabled the autoembed plugin, they expect such content to be embedded". Autoembedding is a UX enhancement, not a restriction. The user must be able to decide. Therefore there must be a way to revert the auto embedding.

And this way is by using CTRL+Z. I agree that it isn't always super obvious and if the request takes significant amount of time, user may also need to revert other changes that they made. So, context menu option would be pretty useful. But there's a very important problem - embed is a block widget, so it splits a block. "Unembed" option would be tricky to implement and we would end up forcing user to fix the content manually anyway. Moreover, context menu is impossible to use on touch devices, so this cannot be the only solution.

Therefore, I don't see much that we can do here. I think that we are doing well with the most important and popular case, when user immediately sees that something went wrong. Pressing CTRL+Z is a natural solution and users will learn that first CTRL+Z reverts embedding.

[Marek Lewandowski]

Context Menu vs Auto Upcast

Looks like automatical link feature is now extracted to a separate plugin autoembed, which is cool. And it work decently.

I do like the idea of adding an option to the context menu. I can see that it might work for some part of our users.

Talking about UX aspect, when comparing autoembed to context menu based upcast, I'd pick autoembed, just because it makes it soooooo easyyyy to insert these links - and that's basically all I would do with it. Context menu allows me to achieve the same goal, by putting me in charge, but requiring few more clicks, keystrokes.

I want my plugin to add some external media stuff to my webpage or a blog post. Autoupcast seems to be just more convenient for me.

Summarize

I'd give +1 for context menu in the generic embed plugin. It's a good candidate for 4.5.1. For now we can start without it, and suggest autoembed.

BTW: if we would create a context menu for embeds, then we also need a refresh option there.

Bulk Insertion

Well, as for bulk media insertion: I'd say our intention was from the very beginning to start with as simple plugin as possible, and continue to enhance it in next minor releases.

I'd say that not many people will like to use embed plugin to insert a lot of stuff at once. Lets wait for user feedback, and if there will be some request for that feature, then we'll have reasons to implement this.

And hey, some of people out there might implement this part on their own.

Accessibility

-- I'll check that today / tomorrow and update the comment --

[Marek Lewandowski]

Updated a11y findings in comment #2.

[Olek Nowodziński]

Related ticket about obtrusive notifications #13421.

[Piotrek Koszuliński]

OK, it became quite clear that this plugin will not get more love in the near future. We are still planning to review it before 4.6.0, but that's nothing concrete right now. Therefore, removing the milestone.