search

ckeditor / ckeditor5

Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.
https://ckeditor.com/ckeditor-5
Other
9.36k stars 3.68k forks source link

Shared UI and UX between CKEditor 5 and Letters #645

Closed oleq closed 6 years ago

oleq commented 6 years ago

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.

image

image

image

image

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:

Icons and toolbar

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

v1

image

v2

image

Link editing UI

First step

image

Second step

image

Second step (focused), alternative back navigation

image

The same UI in Letters with different colors

image

Image editing

CKEditor 5

image

Letters

image

Balloon toolbar

image

oleq commented 6 years ago

Related issues:

pjasiun commented 6 years ago

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 commented 6 years ago

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:

screen shot 2017-10-31 at 13 36 58

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 commented 6 years ago

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 commented 6 years ago

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

screen shot 2017-10-31 at 13 40 57

screen shot 2017-10-31 at 13 39 51

dkonopka commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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. https://github.com/ckeditor/ckeditor5/issues/455) so to some extent this problem will be solved.

pjasiun commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

link-preview

wwalc commented 6 years ago

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

screen shot 2017-11-02 at 06 21 06

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

screen shot 2017-11-02 at 15 32 02

2. full url in button

screen shot 2017-11-02 at 15 29 17

fredck commented 6 years ago

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

wwalc commented 6 years ago

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

oleq commented 6 years ago

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 commented 6 years ago

BTW, are the new designs posted somewhere? Olek showed me them but I don't see them posted anywhere. What Olek posted here in the first message are just pieces of the design, not the whole thing together. It makes it harder to analyse it.

E.g., when I saw it all for the first time there was the editor's light toolbar and the floating dark balloon next to it. I immediately got the impression that the balloon is detached from a completely new UI. It doesn't match the rest of the UI which is light and, I think, had a different sizing.

The second problem that I had is with the icons in the toolbar. They are super bold. I don't like the current serif icons because they just don't fit our use case (serif icons may work in some specific, "classical" apps, though). But those new bold icons look heavy to me and I can see that they forced you to make "Paragraph" bold too which I'm not convinced about.

Finally, it'd be good to verify how editor would look in some contexts. In most cases it's a just a piece of existing systems and websites. Its design cannot make it hard to integrate it and I have doubts about the dark colors and heavy fonts.

scofalik commented 6 years ago

I don't like this blue tint in the dark UI.

Reinmar commented 6 years ago

I don't like this blue tint in the dark UI.

It may also cause trouble in many integrations. We always tried to use grey for the UI's body. I don't say that we must do that, but we must be careful. That's why I proposed to see integrations. It may happen that this theme doesn't even look good on ckeditor.com ;)

oleq commented 6 years ago

Related issue https://github.com/ckeditor/ckeditor5/issues/642.

oleq commented 6 years ago

Branch constellation with the refreshed theme is configured in the t/645 branch.

Critical changes

Changes with new icons

Minor changes

Changes in builds

Reinmar commented 6 years ago

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

Bravo guys! Waiting for the summary.

oleq commented 6 years ago

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).

    screen shot 2018-02-02 at 13 28 11

    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. screen shot 2018-02-02 at 13 29 50
    • 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.

screen shot 2018-02-02 at 13 48 09

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!).

screen shot 2018-02-02 at 15 49 10 screen shot 2018-02-02 at 15 49 20

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)

new-theme-transition