UX: Quick content editing

[oleq]

Are dialogs still the right way of editing content?

• How about inline editing in floating balloons?
  • How complex editing could take place in such component? How many fields is too many?
  • Which content can be edited that way, which should be edited that way and which cannot be edited that way?
    • Why?
  • How about general a11y of this component?
    • How to activate this kind of editing? I.e. should the balloon pop up automatically when a selection is in a link?
  • Should the balloon have a title?
  • Should the balloon have a "closing X" in the upper–right corner (like a dialog)?
  • Is "Save" button enough? Is "Cancel" also necessary (a11y)?
  • How to unlink? (toolbar button vs. an extra button in the balloon)
• Editing in dialogs (like CKEditor 3+)?
  • Pros/cons?
• Editing in toolbar? (see more in UX: Contextual toolbars #99)
  • Pros/cons?
• What other solutions can be offered?

---

Inline (balloon–like) editing

Dialog editing

In–toolbar editing (super–contextual toolbar)

[fredck]

There is also the current tendency to have small floating panels under links, like GDocs. They add very little Ui cluttering. Should we enlarge the samples with it?

[oleq]

Should we enlarge the samples with it?

@fredck Those panels in GDocs show the url of the link and "Change" button. When clicked "Change", they convert into "Inline (balloon–like) editing". So I think we already consider this option and there's no such need.

[scofalik]

I really like ideas of balloons. I think they do not break user experience as much as dialogs. To answer your questions:

1. I think that three one-line text inputs is max. The whole idea of balloon is not breaking user experience, so we can't cover half of the screen. It would be best if changes done in balloon won't drastically (or at all) affect how the edit thing looks like (so, again, user won't feel that something is "jumping" and he/she loses control). Link URL is the best example for a balloon.
2. Besides of links, which are perfect, also images come to my mind (however changing image size affects the view). Autoembeded content is nice too. And that's it what comes to my mind.
3. I have no experience with a11y but want to comment on opening. It could pop-out automatically when link is focused OR we could treat it like context menu, which now appears when something is right-clicked.
4. Balloon should not have a title. It's not needed. Balloon is already pointing to what you are editing at the moment.
5. It depends how it will be shown and whether it will have cancel button. I don't know whether I prefer cancel button or X. Maybe this could be just Theme thing (possible to style through CSS)? After all both have the same meaning.
6. See 5)
7. We could either have a button next to "Save" or remove the link. Or both.
8. I think editing in dialogs should be treated as worst case scenario, something that is used when all other options fail. We should craft UX experience for features. Example: Code widget we have in CKE4 is now (AFAIR) edited in separate dialog. We would have better UX if double clicking would change the code widget into textarea with monospace font. Textarea would change back into widget when focus is lost. It is not really connected with balloons but shares my view on how we should approach UX. Maybe links, images and autoembeds is enough to justify implementing balloons and using them only for those features.
9. Toolbars are better when it comes to breaking user experience but there is not a lot you can do, unless you use very contextual toolbars (a special tab that appears when you focus on link, where you can even change link URL).

[SteveTheTechie]

Balloons are nice, but may not work depending on the content since they require both the affected content and the balloon to be shown (more screen space needed).

Personally, I like the ckeditor dialogs. Very flexible and w/ tabs can contain a lot of good stuff.

[wimleers]

+1 for considering alternatives to dialogs. Dialogs don't work on smartphones. (Or at least I haven't seen them work yet.)

+1 for balloons. But they e.g. don't work for images I think.

---

What about a CKEditor Widget-like approach combined with the "Show Blocks" button's ability to show the structure, but then enhanced? I can imagine keeping everything super simple, but upon adding new non-simple-text content, this newly added content is displayed in "structure mode", which causes a "Widget-slash-Show-Blocks-like" view, which therefore shows the image's alt text inline, for example. i.e. it would visualize both the structure as well as non-visible attributes.

Benefits:

1. no need for any sort of pop-over (balloon, dialog …)
2. stresses the structure and semantics of content, hence discouraging using the editor as a pure design tool (== "pure WYSIWYG")

[oleq]

I can imagine keeping everything super simple, but upon adding new non-simple-text content, this newly added content is displayed in "structure mode", which causes a "Widget-slash-Show-Blocks-like" view, which therefore shows the image's alt text inline, for example. i.e. it would visualize both the structure as well as non-visible attributes.

Sounds like a fun. But what to to when a number of "inline inputs" is needed (like alt, width, height, url, upload button, etc.)? It would end up with an "inline monster".

[mrmnmly]

In my opinion dialogs just do the work.

Tabs could also be a good solution but.. (reason below)

Baloons looks very nice, but I have doubts about them:

• if user click anywhere else but baloon/tab then baloon/tab will disappear? (dialogs has button to close so they remove accidental random missclick events right? (or not?))
• what will happen when user will start to scroll really long text (when baloon is opened)? Should baloon auto-hide and auto-show when selected word will appear in visible text area?

[SteveTheTechie]

What I see is that maybe a progressive enhancement type of strategy is called for. I can see where dialogs would not work on smartphones, but I think they do work fine on the desktop. It is clear that a UI strategy that fully embraces mobile is needed. However, please don't forget about desktops in the process and what the ckeditor UI already does well on the desktop. After all, I take issue with any one that believes they can do much more than basic editing with basic formatting on a smartphone. IMHO, things like embedding an iframe... things that dialogs are actually helpful for, are still best done on a larger screen.

So maybe a different approach is called for on smaller screens. However, can you do the progressive enhancement approach (or similar) to enable what works better on a larger screen to be used?

Also, keep in mind that a lot of extra stylistic "bling" may make ckeditor more difficult to integrate stylistically into a finished, polished web application. I treat ckeditor as functionality that acts a lot like a full application, but really isn't. Please do not forget that in most cases, ckeditor and its UI need to be able to be integrated into someone's web application. Thus, I tend towards the "keep it simple" thinking but hope you will implement provisions to allow for "bling" to be added as needed.

[fredck]

I couldn't agree more that dialogs are a better deal.

At the same time, I don't understand why you guys keep pointing that dialogs are not good for smartphones and why a ballon would make it work there. Actually, I feel that's quite the opposite. It would be simpler to find a way to show a dialog full screen in a smartphone than having the user to control scrolling to see the ballon contents.

Other than that, I think that a "quick editing" solution like the one presented in GDocs for links is definitely welcome but I seet this is a different feature for a separate discussion.

[mrmnmly]

Actually, I feel that's quite the opposite. It would be simpler to find a way to show a dialog full screen in a smartphone than having the user to control scrolling to see the ballon contents.

Good point!

[oleq]

At the same time, I don't understand why you guys keep pointing that dialogs are not good for smartphones and why a ballon would make it work there. Actually, I feel that's quite the opposite. It would be simpler to find a way to show a dialog full screen in a smartphone than having the user to control scrolling to see the ballon contents.

Please, don't confuse desktop UX with mobile at the moment. CKEditor 5 may end up with completely different solutions for these environments i.e. balloons and dialogs, as seen on the desktop, may become one and the same "fullscreen dialog" on mobile. So let's focus on desktop UI first because mobile is a separate topic, to be discussed later.

[koleary]

So let's focus on desktop UI first because mobile is a separate topic, to be discussed later.

So what you're saying is "let's take a desktop-first approach."? :)

[koleary]

How to activate this kind of editing? I.e. should the balloon pop up automatically when a selection is in a link?

Yes. That's the common expectation set by Google etc.

Should the balloon have a title?

Not if the field label is sufficient as it is here.

Should the balloon have a "closing X" in the upper–right corner (like a dialog)?

Yes, it should have the "x". And cancel is not absolutely necessary. AFAIU for A11y "cancel" can be the Aria name of the "x" button that is read out.

Also clicking "away" from the bubble should close it. This is becoming expected behavior.

How to unlink? (toolbar button vs. an extra button in the balloon)
Editing in dialogs (like CKEditor 3+)?

Dialogs are old school. Users are comfortable with the bubble pattern. It appears all over the web.

[wimleers]

I don't understand why you guys keep pointing that dialogs are not good for smartphones

I've not once seen a dialog in a browser working well on a smartphone. Especially when the keyboard is also visible.

Can you post screenshots of example dialogs in web browsers on smartphones that work well?

[Reinmar]

So let's focus on desktop UI first because mobile is a separate topic, to be discussed later.

So what you're saying is "let's take a desktop-first approach."? :)

Not precisely. I'm not sure whether there's an issue for that already, but we've been discussing that desktop and bigger touch devices are one case and small touch devices are a second case. So what @oleq meant was that for now we'll focus on the UI for bigger screen resolutions. The small screens like iPhone introduce such limitation (there's so little space when the on-screen keyboard is visible, that you can barely display anything) that they have to be solved separately, because no normal solutions will work there. Please note also that we're not talking here about designing a webpage where you have the full area of the iPhone's screen and you can simply make your webpage responsive and be happy. Editor needs the keyboard (on which we don't have any control), selection (which sets some design requirements as well), ability to open dropdowns and other panels without ultimately breaking the selection, etc. Hence, in our opinion we won't be able to design a single solution that will work for all types of devices without making the UX on some of them worse than it could be.

So no – no "desktop-first approach" ;).

[oleq]

tl;dr for @Reinmar's response is:

"There will probably be a totally separate UI for small mobile devices because WYSIWYG on mobile is extremely hard to implement.".

[Reinmar]

That wasn't a lossless compression :P.

[koleary]

Sure, but if there are to be two approaches always better to tackle the harder one first. Especially if the process leads to discovery of a solution that does indeed work for both, something which is impossible to rule out.

[Reinmar]

Cleaning up outdated discussions. See #186