Shared UI and UX between CKEditor 5 and Letters

[oleq]

At some point in the past Letters and CKEditor 5 diverged in terms of the UI and UX. Each project developed own solutions and at this moment this inconsistency generates lots of issues and very few benefits.

The problem

1. Two different UIs for very similar application imply there's no clear vision of what the whole thing should look and work like.
2. Two UIs mean double effort when it comes to maintenance, bug fixing etc.
3. Bringing new features means again a double design/implementation effort.

The solution

1. A single UI should be shared between the applications.
2. The UI should be simple yet beautiful. It's a good occasion to revise certain decisions, consider feedback we got and bring an even better UI.
3. The UI should be extensible.

Mockups

Note:

• The icons are under development.
• The colors are under development.
• Click to enlarge.

Icons and toolbar

The icons will be refreshed and unified. The toolbar could become totally flat.

v1

v2

Link editing UI

First step

Second step

Second step (focused), alternative back navigation

The same UI in Letters with different colors

Image editing

CKEditor 5

Letters

Balloon toolbar

[oleq]

Related issues:

• Research CSS flex box layout in the UI #642
• https://github.com/ckeditor/ckeditor5-ui/issues/144

[pjasiun]

I have to say that I love the flat UI, you proposed. All elements look modern and cool. I also believe that we should make it clear, that the color palette (background, icons, focus, etc.) should be configurable, but the rest should be unified. Great job!

[pjasiun]

Ach, one thing I need to add is that I believe that we should avoid having drop-downs in balloon panels. Of course, it is up to the developer how he will integrate CKE5 framework, but we should not have them in our demos. For sure there should not be a drop-down in Letters block toolbar:

I think that together with drop-down for styles, we should provide buttons for basic styles (P, H1-H*) and leave it up to the developer which UI he wants to use.

[oleq]

I agree that in Letters, the toolbar should be as simple as possible. The shorter path to reach the feature is the best and we can reduce the number of clicks here.

However, in CKE5 we need such dropdowns because the editor has more features and almost never goes fullscreen, so space is scarce and we must use it efficiently.

[RyszardB]

This is my UI proposal that I did in January of this year. Have been rejected..

[dkonopka]

I think it could be a good idea to give developers opportunity to get rid of dropdowns and change it to inline buttons (with custom icons).

[oleq]

This is my UI proposal that I did in January of this year. Have been rejected..

@RyszardB: Requirements change as the time goes by. What didn't make sense at that time (for whatever the reason) can make sense now because we understand the projects better. They're a living things.

[wwalc]

Ach, one thing I need to add is that I believe that we should avoid having drop-downs in balloon panels. Of course, it is up to the developer how he will integrate CKE5 framework, but we should not have them in our demos. For sure there should not be a drop-down in Letters block toolbar:

Remember that we have separate issues for heading buttons (e.g. #455) so to some extent this problem will be solved.

[pjasiun]

However, in CKE5 we (..) almost never goes fullscreen, so space is scarce and we must use it efficiently.

Note, that in many cases when only P, H1, H2 and H3 buttons are needed they takes less space than then dropdown. Especially with this flat UI.

[fredck]

Very good stuff here... well done everyone!

@oleq, I remember we also took into consideration adding the url as part of the "Open link" button. I still like that idea.

[oleq]

@fredck Yes, it's still on my TODO list. It could be useful for people reviewing their document and checking the targets of the links.

[dkonopka]

Some proposal below.
We should decide how many characters will be optimal (and calculate it to max-width with overflow: ellipsis).

[wwalc]

I'd like to underline one problem with the width of input element and paste a screenshot from Google Docs:

Basically, I'm afraid that looking nice should come in pair with usability. Having to fight with the cursor to view the URL (which is the key information for a link feature) looks like a UX problem to me. And if we plan to make the input much wider, then the design should already include it, because it would simply look different.

[oleq]

@wwalc You posted the image of the intermediate "go to link" balloon and you write about the input so I'm a little bit confused here.

But if you're worried that the href input in the "edit link" balloon is not wide enough, we already had this discussion.

If you're worried that the link href in the "go to link" will be truncated (...), the answer is basically the same. No matter how wide the balloon, there would still be some cases where the href gets truncated. Our job is to satisfy the most common ones and keep the UI clean.

[fredck]

As long as the button is a real link, so the browser will show the full URL in the "status bar", it should be fine.

[wwalc]

@oleq Thanks for the explanation. It just looked like an input element for me, thus my confusion and confusing comment (I did not read previous comments). In any case it looks like I have same thoughts as @Reinmar when it comes to the size of the input and the amount of information shown, but it's a dup of https://github.com/ckeditor/ckeditor5-link/issues/56.

@fredck IMO we should not expect regular end users to treat the status bar as a part of the CKEditor interface.

[fredck]

@fredck IMO we should not expect regular end users to treat the status bar as a part of the CKEditor interface.

Hard to say... but the point is that we'll come with a good option anyway and the status bar is the fallback case if it is not sufficient.

[dkonopka]

So here are two ideas. I think the first one is a good alternative for people who don't know about existing of the status bar in the web browser. About 2nd proposal: input should be 100% width only on mouseover event. It can work with a nice smooth transition.

1. full url in tooltip

2. full url in button

[fredck]

IMHO, I don't think we should worry about it until it is a problem. KISS on the first milestone.

[wwalc]

Just to comment on @dkonopka proposal: 2nd option seems better to me as it will be usable also for people on tablets.

[oleq]

it will be usable also for people on tablets.

Touch devices most certainly will (eventually) get a completely different UI so I wouldn't use that as a point.

[Reinmar]

🎉
🎉 🎉
🎉 🎉 🎉
🎉 🎉
🎉

Bravo guys! Waiting for the summary.

[oleq]

Hurray! 🎉

Here's the quick summary of the research we did over the past two months hopefully explaining decisions we made and answering the most obvious questions about the new UI of the editor.

Note: The screen-shots below may not correspond with the current stage of development. They are slightly outdated and I used them only to present some concepts/problems that we stumbled upon. For the latest UI, go straight to master in ckeditor5 or nightly docs tomorrow.

Icon thickness

We started with 1px icons just like before refactoring. They looked great on Retina but soon we found out there are lots of rendering issues with complex shapes and curves on LoDPI screens (jagged edges etc.).

We then decided to switch to 2px icons, which solved the issue (worked well on LoDPI and Retina) but they looked very heavy as compared to other pieces of UI, e.g. fonts in dropdowns and CMSs that may use CKEditor 5.

Finally, we decided to trade-off some crispness and the feel of a lightweight UI and we stopped at 1.5px for straight lines. It's readable on LoDPI screens but still not overwhelming as 2px. Yes, we worked on the icons thrice…

There's a follow–up discussion about the icons and possible LoDPI issues.

Paddings in the UI

The very first idea was a padding-less UI e.g. with buttons using 100% height of the toolbar. But then we found out there are two main problems with that approach:

1. Such buttons collide with the arrow attaching the floating toolbar to the selection. There's no way to style the arrow to provide a smooth transition. It will always stand out in some arrangements.

2. A padding less toolbar looks weird when it wraps to the next line (narrow UI). There's no spacing between toolbar buttons and there's no way in CSS to tell which items have been wrapped and give them some spacing.

3. If we go with padding-less UI, we must stick to that approach wherever possible. And that includes forms, like the link/image form and any (possibly more complex) that come in the future. Mostly because the transition from a padding-less UI to a padded one feels just horrible (e.g. clicking link button and switching to the link form).
   

   And this is where actual hell begins:

   • A padding-less forms mean there's no way we can use labels when they are necessary (and they will be). There's no space for them.
   • Label-less inputs look strange when they have a value but no clue what the value is (the example with width/height). What is 220? An age, size or year? If we added the labels it would mean that in some languages (e.g. German), the labels will expand the UI horizontally to enormous sizes.
   • Padding-less UI means we must figure out how to tell the user that inputs are focusable (they have no boundaries, they look just like a text) and then somehow announce the focus, but there's no way to do that.
   • Padding-less UI means that if we want to advertise the focus of inputs (and there's no other way than material design approach), we'll hit the arrow (triangle) problem like in the toolbar. The input "cuts" the arrow off if it gets any side border of a different color (the "http://example.com" case).
   • In a padding-less UI we can only build the UI sideways. In truth, everything is a toolbar. If there's a form with 2+ inputs, we're doomed because it will consume most of the horizontal space available in the viewport. There's no way to switch to multi–line forms etc.
   • A padding-less UI means action buttons (save, cancel, etc.) must span 100% height of the UI. When they got background colors, we lose the contrast and a perception where the floating UI starts and what is beyond (below) it. The color (e.g. green) does not go well with the border of the balloon.

So (a very) long story short, because:

1. We want to use balloon arrows because they are great when the precision matters (e.g. they're awesome when indicating forward and backward selection in the balloon editor).
2. We want to have a freedom to use labels in complex forms that may arrive.
3. We want to be able to build mutli–row forms in the future in the balloons.

we decided to go with paddings in the UI — it's safer and gives us more possibilities.

Bright UI vs. inverted colors

The very first idea was adopting Letters–style UI which is dark (inverted) by default. Then we realized that even if it looks great it has some issues.

Most of the apps around the web use a bright UI. CKEditor 5 is a component which should work out–of–the–box for most use cases, which means it should not stand out and should not require additional work for developers.

We also considered a hybrid: white toolbar and dark balloons. The problem was the both UIs looked like pieces of a different application. They contradicted each other and the overall feeling was that the UI lacks consistency, as if the team doesn't know what is best for the project.

That's why we went with a bright UI but used a slightly gray background for the toolbar by default (a follow–up about the gradient). It's the safest decision here.

Still, in our documentation, we'll maintain an example (guide) with a dark theme created just by overriding CSS variables (which is pretty easy). We can call it now "an official customization". An inverted theme also became one of the manual tests in ckeditor5-theme-lark.

Full-height separators

We decided that at the current stage of development, we can ignore toolbars wrapping to the next line. We also decided that we will advise (in examples and default configs) the usage of toolbar separators after dropdowns (e.g. heading) and as a grouping mechanism, which especially looks awesome in the inverted theme.

2-step editing link and simplified text-alternative

We decided to refresh the way of creating links in this refactoring. Mostly because in the old UI there was no possibility to open the link in new tab/window and we already knew about that.

The refreshed UI comes with a keyboard support. What is also important, there is no difference between the toolbar height between editing steps, which would not be possible if we went with the padding-less UI. Also, the new link form saves a lot of space (143px of height vs 53px!).

What's next?

We're importing the new theme to Letters and designing some icons unique for the application. Soon we'll make a public demo. Stay tuned!

Note: Please start new discussions in the follow-ups instead of bloating this issue even further. Please mark them with the module:theme-* label, if possible.

Bonus (click to open)