Image feature UX/UI design

[oleq]

In a F2F conversation with @fredck and @Reinmar we agreed that our approach to the images (and media in general) in the CKEditor should evolve to catch up with the needs of our users and content editing trends around the web.

We also agreed that what users expect from media in a WYSIWYG editor these days no longer corresponds with the UX CKEditor 4 can offer. People need a smart and simple way to enrich edited text, not heavy dialogs with billions of inputs and checkboxes.

Sources of media

Media are no longer stored in separate ecosystems, their URL pasted into a dedicated field in a specific dialog. It's a roundabout way of WYSIWYG editing and it's time to say goodbye to the concept of the Image dialog that we get used to in CKEditor 4.

That's why I'm for abandoning the image dialog (and URL field) and replacing it by some more sophisticated UX that handles media like a content, not an addition, which is how end–users think about images, videos and the such.

Drag and drop / paste

By default, the editor should provide a configurable API to upload/obtain images from the server.

Editing should be done in one place. Not in a separate tab or CMS panel where first media are uploaded, so a URL can be obtained and then pasted somewhere else.

Whether drag&dropped from the desktop

or pasted from the clipboard,

media should be handled by the editor and the user should not be bothered about uploading, on–line storage, URLs, etc. The experience should become as similar to native text processors as possible. It's all about the CKEditor<->server communication, not about user actions.

Paste with auto–embedding

If there's a media URL in the clipboard data that CKEditor can discover (video, image, tweet), then it should be automatically converted into a rich form as data is pasted.

Wrong URL? Delete embedded content, paste the right URL and editor will embed it again. There's no need to implement a separate dialog/UI to handle such a case.

Media browsing

CKEditor could (should?) offer a simple media browser built on top of the editor<->server API to let users browse files they uploaded, i.e. to avoid re–uploads and redundancy when another article requires the same image.

This is a tricky topic because users will immediately expect such media browser to offer media management features (delete, rename, move, create a folder, etc.). OTOH, we could limit the browser to "recently uploaded" or "editor uploads" only, with basic filtering and 2 view modes (thumbnails/list).

An afterthought: the UI could be a dialog instead of a balloon.

Moving media in edited content

I think the solution from v4 widgets is right.

Block media should be draggable using a dedicated drag handler with a magic–line placeholder displayed in possible drop places.

Inline media (if allowed – read below) should be draggable as a regular content, with drop area marked by the native caret.

Image manipulation

I propose 2 different approaches, each with some pros and cons.

Smart balloon toolbar

If we didn't need the "alt text" input, and we do need it for a11y reasons, this could be a perfect solution. I prefer it to the next one, though.

Pros:

• real space saver,
• gives an impression of smart, lightweight editing,
  Cons:
• hard to extend because of limited space and horizontal structure,
• may lead to some discoverability issues and confusion because of lack of the labels (like caption vs. alt text).

Image balloon panel

Pros:

• closest to what people are used to (dialog),
• quite clear what is what (labels),
  Cons:
• consumes more space,
• may feel bloated

Images and links

Images must be linkable. There are 2 things we can do about it:

1. Display image and link UIs at the same time, image at the top, link at the bottom. It feels like too much confusion, though. And there's the question of smart balloon panel positioning when space becomes scarce to avoid overlapping.
2. Display the image UI as a primary. When a user clicks the link button in the toolbar, the image UI is replaced by the link UI. Once the link is saved/canceled, the link UI disappears and image UI pops out again.

There's no way to put image manipulation controls and link stuff in a single container, though. If only because link requires confirmation and image not. Besides, by doing that we would unleash quite a UX monster.

I'm for option 2. with a possibility of placing link/unlink buttons inside "Smart balloon toolbar" if that's the solution we decide to adopt.

Image (media) alignment

TBH, I wouldn't mind if we decided that media are blocks only. It's a correct decision from the semantical point of view. It would also dramatically simplify drag and drop and the UI to manipulate images.

OTOH, I wonder what developers would say because we could cross the line by doing so. This decision could significantly narrow the scope of possible CKEditor 5 integrations.

To resolve the conflict, we may offer a configuration for alignment buttons, which would operate on an image (figure) class attribute only, with a possibility to disable each button, i.e. to allow only [ full–width, side media ] setup.

Image (media) scaling

There will be none. CKEditor 5 focuses on semantic content and user–scalable media certainly aren't the best example.

[oleq]

Some mockups to visualize my favorite concept (click to enlarge):

Please note that icons need refactoring.

[scofalik]

What can I say, I agree with everything and I have a feeling that as long as we don't have too many icons, discoverability in smart toolbar is not an issue. I'd rather be worried about it changing it sizes/positioning than that.

My only concern is media browsing part. I'd not discuss it right now. I know it feels natural to propose it right now together with image feature. I also understand that this was just an idea/hint/proposal. However I am sure that if we decide on this, this needs separate issue for discussion. I have a feeling this is even broader subject than the core image feature itself.

Have you though if it will be complicated to implement the solution with link/image UI, the one that you like better?

[wimleers]

What an excellent summary! I have nothing to add :)

[Reinmar]

By default, the editor should provide a configurable API to upload/obtain images from the server.

"Upload" yes, but "obtain" is too much. Something like media browser is, I think, beyond what we should provide, because it's a huge topic itself. We have experience developing CKFinder and it's a pretty big app itself. So I see the "insert media/image" panel as:

1. Place to drop the image or choose a file to upload from the disk.
2. Place to paste a URL (from time to time you'll want to insert an image which is already uploaded somewhere).
3. Some space for injecting a button to an online file browser (like CKFinder) or a whole online file browser. This would be a place used by various integrations.

[Reinmar]

Moving media in edited content

One thing here regarding mockups – I'm not sure that the drag handler should be on the left side of the image. This would render it invisible if someone styled left-aligned images in such a way that there's no left margin. OTOH, position above the image could be invisible in some cases as well... Optionally, we can ignore this issue now and go with what you find better (can be left) and say that you can position the handler differently by overriding certain styles.

[Reinmar]

Images and links

I'm for option 2. with a possibility of placing link/unlink buttons inside "Smart balloon toolbar" if that's the solution way decide to adopt.

+1. But I would not try to place the link button inside image's tooltip. There's a link button in the toolbar already so let's keep things as simple as possible.

BTW. I feel that image linking is a new feature (cause this one doesn't add an attribute to a text, but to an image), so it should be fairly easy to integrate it with image tooltip (which of them has priority)

[Reinmar]

TBH, I wouldn't mind if we decided that media are blocks only. It's a correct decision from the semantical point of view. It would also dramatically simplify drag and drop and the UI to manipulate images.

That's definitely the way to go. We should focus on a feature called "block images" which, from my experience, represent 99% of cases in which images are used. Note that things like smileys or inline math (equations rendered by some backend) are separate features and should never be inserted and "managed" by the original image feature.

To resolve the conflict, we may offer a configuration for alignment buttons, which would operate on an image (figure) class attribute only, with a possibility to disable each button, i.e. to allow only [ full–width, side media ] setup.

I don't how this was meant to solve inline images problem (because in this problem you need to strip <figure> and disable captioning in the first place).

But it reminded me that the alignment options should be configurable. Basically, each option is represented by a class which needs to be applied to <figure>, title and icon (needed for the button in the image tooltip). We should provide some defaults like left, right, 100%, but developers should be able to configure more options – look Medium where you also have pulled images, 150% width, etc.

Image (media) scaling

There will be none. CKEditor 5 focuses on semantic content and user–scalable media certainly aren't the best example.

+111

[fredck]

Amazing job @oleq!

Media browsing

I think you went a bit too far with this. We should handle this point in the future as a totally separate feature. It's definitely not something for the current stage.

Smart balloon toolbar

+1

I don't think a button for caption switching is needed. The caption space could simply appear when the image is selected and disappear when left empty and image is deselected. This will help with less stuff in the toolbar and open space for the "alt" field.

Images and links

+1 on your proposal.

Image (media) alignment

+1 for blocks only.

Technically, inline images have use for emojis, formulas, etc., but the only think that makes them somehow related to the "image" feature is that we use the HTML element to render them. In the user POV there is no relation between them: images are images, emojis are emojis, formulas are formulas. Therefore, when discussing the "image" feature we should not even bring in consideration mixing up the inline aspect of it.

To resolve the conflict, we may offer a configuration for alignment buttons, which would operate on an image (figure) class attribute only, with a possibility to disable each button, i.e. to allow only [ full–width, side media ] setup.

Then, when it comes to the implementation of alignment, I agree that we should use "exclusively" classes to implement them. This will leave the implementer totally free to visually design them.

As for the configuration, yes, that's for sure ;)

Image (media) scaling

+1

Scaling should be controlled by the server and by the following topic...

Responsive images

Although the feature itself will not be able to produce several different versions of the same image, let's keep in mind that the server may be willing to do so, once the image is uploaded. Therefore, we must be sure that the API is able to handle such feature.

Also, when it comes to converters, the default implementation must for sure produce scalable, responsive HTML.

"Insert Image" Pane

A discoverability concern...

Although we must certainly support pasting or dropping of URLs or images, we also need an action button at the toolbar for the insertion of images. Such button should activate a panel that allows for:

• Pasting a URL in a field.
• Dragging an image into it.

// PS: I've noticed that some of my comments may be dups of comments of others.

[oleq]

Just a quick response to @fredck

I don't think a button for caption switching is needed. The caption space could simply appear when the image is selected and disappear when left empty and image is deselected. This will help with less stuff in the toolbar and open space for the "alt" field.

It's not a good idea, really. If we implement it like this, each time the user clicks (selects) an uncaptioned image, the entire editor content will "jump" because the caption editable area became visible. Then, it will jump back again when the user de–selects the image, because the caption collapses when there's nothing there yet. Down, and up, and down, and up...

Well, of course, I'll check this idea live first. Maybe I'm just exaggerating and it's not that annoying. But in pure theory, it doesn't sound like a good plan to me.

Although we must certainly support pasting or dropping of URLs or images, we also need an action button at the toolbar for the insertion of images. Such button should activate a panel that allows for:
Pasting a URL in a field.
Dragging an image into it.

By doing so, we'd duplicate the functionality as one could always drop the image directly where they're editing or just paste a URL there. I got your point, though and I must think it through again. Maybe we should educate users instead? Maybe this toolbar button should be more educational than functional?

[fredck]

It's not a good idea, really. If we implement it like this, each time the user clicks (selects) an uncaptioned image, the entire editor content will "jump" because the caption editable area became visible. Then, it will jump back again when the user de–selects the image, because the caption collapses when there's nothing there yet. Down, and up, and down, and up...

I don't find it bad. In the moment you click an image, you're focused on it, not on the rest of the page. If it jumps (slightly), it is no big deal. I confirmed it with Medium and I never felt it as a problem. Actually, it is even better like this because there is less risk of losing the caption text.

By doing so, we'd duplicate the functionality as one could always drop the image directly where they're editing or just paste a URL there. I got your point, though and I must think it through again. Maybe we should educate users instead? Maybe this toolbar button should be more educational than functional?

I don't think it is a problem, as long as the user will be able to successfully complete their tasks. That's the main goal of UX. Having more than one way to achieve so is irrelevant. The problem is not being able to do so.

[Reinmar]

Well, of course, I'll check this idea live first. Maybe I'm just exaggerating and it's not that annoying. But in pure theory, it doesn't sound like a good plan to me.

I've got mixed feelings as well. I noticed that Medium has solved it this way immediately because this was disturbing. You simply don't expect that something like this is going to change. And e.g., if you're at the end of the page, then you cannot avoid a jumping scroll.

OTOH, none of these changes is dramatic (no more than a layout of ~2 paragraphs will change if the image is floated, although weird things can happen if you move selection from one image to another). So, theoretically, you shouldn't get lost in what's happening. But usually a jumpy interface is considered buggy and the lower the screen size the more visible the issue becomes.

I don't think it is a problem, as long as the user will be able to successfully complete their tasks. That's the main goal of UX. Having more than one way to achieve so is irrelevant. The problem is not being able to do so.

+1.

[pjasiun]

"Insert Image" Pane

A discoverability concern...

Although we must certainly support pasting or dropping of URLs or images, we also need an action button at the toolbar for the insertion of images. Such button should activate a panel that allows for:

Pasting a URL in a field.
Dragging an image into it.

Note that there is no such panel in Facebook or Twitter post editors and there is no UX problem, users know how to insert the image. On the other hand, there is a button which opens a system file dialog, what is very useful, since dropping a file from the file system is not supported very well.

[Reinmar]

Note that there is no such panel in Facebook or Twitter post editors and there is no UX problem, users know how to insert the image. On the other hand, there is a button which opens a system file dialog, what is very useful, since dropping a file from the file system is not supported very well.

Exactly. I wanted to point that out as well that in every editor I know (or next to it) there's a "browse files" button. Some also have a "drop area" where you can dnd those files (GDocs IIRC). Allowing only to paste and drop isn't enough – it creates discoverability, accessibility and usability problems.

[fredck]

I noticed that Medium has solved it this way immediately because this was disturbing.

I'm wondering if this disturbed you as a "normal user" or as an "editor developer" and, as it didn't match the way you "designed" it in your hand, you feel disturbed :)

But usually a jumpy interface is considered buggy and the lower the screen size the more visible the issue becomes.

Note that the "checkbox" will not solve this problem. The content will jump anyway... ofc, as a result of a user action... but still.

But on the other hand, it just came to my mind another issue with the checkbox... that there is no guarantee that the user will type anything in the caption. So what now?... showing that space was an "intentional" (or maybe not) user action. The "if empty it disappears" approach solves this problem then.

Finally... I'm not saying that one approach has zero drawbacks... I'm just focused on the one that sounds like less problematic.

[Reinmar]

Well, it bothered me as a normal user :P. I pedantically don't like glitches and this can lead to a buggy look.

However, your arguments convinced me. Especially the one (which you forgot to make :D) about mistakenly clicking the "toggle caption" button and losing its content (of course there's undo history, but nevertheless).

Finally, perhaps the best thing about such a solution is that it will invite the users to fill out the captions. You will see the space there, so you'll automatically start thinking what you can put there.

[fredck]

When it comes to the dragging handle, widgets that have non-editable content, like images, don't really need it as dragging could be started directly from within the widget itself. It would be more intuitive to users.

The handle could be introduced later when people will start developing widgets that have just (or mainly) editables inside.

[Reinmar]

I created a separate ticket about inserting images: https://github.com/ckeditor/ckeditor5-image/issues/16.

[Reinmar]

I think we can close this, @oleq?