UX: Floating toolbars – shapes

[oleq]

Should floating toolbars look like balloon pop–ups or like detached panels?

• Are both implementations necessary?
  • What are possible use cases for each implementation?
  • Which is more intuitive?
• Is the "smart alignment algorithm" still needed (like in CKEditor 4+ – to the left, to the right of editable, depending on the viewport size and position)?
  • If so, is that enough? Could it be something even smarter?

---

With pointing arrow, balloon–like

Flat, sticky to the editable

[fredck]

Let's keep in mind that the toolbar will at some point, when scrolling the document, enter the content area. This may be tricky when it comes to the "balloon" option as it'll point to something inside the content.

[oleq]

@fredck The "balloon" could point to the editable as a whole, and get transformed into an arrow–less toolbar when approaching viewport boundary.

[jodator]

+1 Flat, sticky to the editable

[SteveTheTechie]

+1 Flat, sticky to the editable If an arrow is wanted, put it in the toolbar.

[mrmnmly]

+1 Flat, sticky to the editable

[Heilemann]

Please remember to consider how this would work on a touch/mobile device, something most editors completely fail to address.

[Reinmar]

As for mobiles, IMO we need to consider two situations – big touch devices (iPad like) and small touch devices (iPhone like).

The former are usually OK when used with a desktop-like solution if the page is styled correctly and the UI library in use has support for touch interaction. So I think we should try to design the default UI in a way that it will need only a couple customisations for touch envs to reach a good UX there. Kinda like a progressive enhancement, rather than a separate implementation. The soonest we start think in this way the batter the result may be.

Small touch devices are separate topic. They are much more demanding, especially that we cannot control the keyboard (it makes things super hard), so many times a single line of text barely fits the available space. Such environments, therefore, require a specialised approach and I guess that we'll need to propose a separate UI setup just for them.

[Reinmar]

Answering the main questions:

1. +1 for flat sticky, because it takes less space.
2. I would consider stretching it to 100% of editable's width. I think it could better indicate what's editable. If editable is narrow, then of course the toolbar can be wider, although that could be editable.
3. To make the toolbar less obtrusive, we could set its opacity to e.g. 0.8 when it's not hovered.
4. CKE4's algorithm was pretty good, although:
   • AFAIR it wasn't optimised to handle panning and zooming on touch devices. Those are pretty tricky cases and we need to decide how to handle them. E.g. do we want to handle situations where the website is styled poorly and require zooming in to be accessible? I guess we should, so the next question is how to behave? For instance, working on CKE4 I noticed that it may be better to switch to positioning to viewport's top left corner (like position:fixed; left: 0; top: 0; width: 100%) but it may make the right side of the toolbar inaccessible if the user zoomed in too much, so we could consider some horizontal toolbar scrolling for these cases.
   • The CKE4's algorithm was trying to handle the situation where the editable does not fit horizontally within the viewport. I would ignore this case as it means that the styling of the website is incorrect. In general: if something super tricky and custom is required to handle some unusual cases, we should allow the developer to adjust the implementation for his/her needs. We should not try to satisfy the whole world as it makes the implementation ridiculously complex.

[oleq]

For instance, working on CKE4 I noticed that it may be better to switch to positioning to viewport's top left corner (like position:fixed; left: 0; top: 0; width: 100%) but it may make the right side of the toolbar inaccessible if the user zoomed in too much, so we could consider some horizontal toolbar scrolling for these cases.

Not sure I got the point but I think "horizontal toolbar scrolling" isn't possible in such case (at least using pure CSS). Just because the viewport is zoomed it doesn't mean that anything else becomes scrollable (except the viewport, OFC). That's the root of problems with zooming: it crops DOM elements that you'd rather want to remain in the zoomed viewport (like toolbars, panels) and there's nothing you can do using CSS to prevent it; the geometry of the viewport does not change, only zoom factor.

[Reinmar]

Hm... I don't know how it works in fact. I tried to describe it from the user perspective. I think it would be useful if the toolbar remained sticky to the top (always visible) even tough you zoomed in. Perhaps this will be possible with JS... but then the zoom factor remains. Damn browsers :D.

[oleq]

Perhaps this will be possible with JS... but then the zoom factor remains. Damn browsers :D.

That was the problem with https://dev.ckeditor.com/ticket/8307. We spent a lot of time trying to write JS which keeps the editor maximised regardless of viewport size/zoom factor and we failed. AFAIR I focused on iOS only but I still couldn't code it properly. The conclusion was that Fullscreen API might be the right way to do it but it unavailable in iOS. It wouldn't be much help when positioning toolbars anyway, just bringing back the experience.

[Reinmar]

Do you think that we could initially focus only on correctly styled websites, so these which do not require zooming in to be accessible? That would perhaps allow us to simplify the implementation.

[oleq]

Do you think that we could initially focus only on correctly styled websites, so these which do not require zooming in to be accessible? That would perhaps allow us to simplify the implementation.

This was my first idea until I realised that web pages which does not zoom are usually adjusted for small mobile devices, which could get a completely different kind of editing UI anyway (#115), while what you see on your tablet is usually zoomable. And you zoom it a lot to read small text because developers code RWD like this: it's either mobile (not zoomable) or tablet/desktop (zoomable).

[Reinmar]

How wide must be a website so you need to zoom it on a 9"+ screen to be able to edit it if some 12px fonts were used? If the website isn't readable on such a screen without zooming in I would still consider it styled incorrectly. But yeah... if that's a popular situation then we've got a problem.

This is in fact even more sad, because we're talking here about the toolbar position, but there are other issues caused by zooming IIRC. E.g. when the editable does not fit in the viewport there's a problem with more uncontrollable scrolling when the editable gets focus or something happens to the selection. You (as an editor developer) must be extremely careful what you do with the caret and IMO, with the current state of things, it's just impossible to not fail one day.

Hence, I would still consider ignoring cases where the editable does not fit in the viewport horizontally. In other cases the whole toolbar will be visible anyway, and the editable will overflow only vertically, which is less problematic.

Does it make any sense or I'm talking nonsense here?

[SteveTheTechie]

Interesting discussion... Some thoughts/ideas to throw in:

1. Maybe for small screens, you cannot rely on the native scrollbar/scrolling mechanisms to be visible in a way that is readily usable. Perhaps you need to come up with another scrolling mechanism that you can more readily control the location of... e.g., a four-headed arrow scrolling element that overlays the editable or scrolling arrows that you can strategically locate on the border of the editable.
2. Toolbars on small screens could end up being a jumbled mess. You could maybe scroll the toolbar itself (put scrolling arrows at either end of it when appropriate) or you could maybe convert the toolbar to a slide-in panel representation that is hidden when not using it (just show panel when the toolbar needs to be used)--this latter approach puts the priority on the visibility of the editable, which I think is really important for small screens.

[Reinmar]

Perhaps you need to come up with another scrolling mechanism that you can more readily control the location of

Scroll should never be overriden. That's an anti-pattern, because it's device specific and there's no API yet that would be sufficient to control it.

Toolbars on small screens could end up being a jumbled mess. You could maybe scroll the toolbar itself (put scrolling arrows at either end of it when appropriate) or you could maybe convert the toolbar to a slide

I had a similar idea. I definitely agree that it took as little space as possible, so it could be scrollable. It sounds OK, but on the other hand it contradicts what I've written above :D. This may be the only way tough, and perhaps it won't be that disturbing as overriding scrolling the whole page.

[koleary]

This discussion entirely misses the point. Making it sticky to the editable is a half measure. The bar should be sticky to the cursor, as it is in Barley, Medium etc.

I have always been a bit dissatisfied with the way we did it in CKEditor for Drupal, perhaps we can make it better now.

[Reinmar]

Hehe :) I've got an opposite opinion, because I don't like the Medium's toolbar. I don't like that it covers the text and that I need to select something to make it appear (the latter is super frustrating). Such a solution has to solve many problems like where to display itself when the user scrolled away from the selection, or the selection is huge. Additionally, when it disappears once the selection is empty, you make your users mad when they want to do something with the empty selection. All the buttons like insert image, video, indent text, change format, turn into a list, undo, redo, paste, cut need to be placed somewhere else.

Medium's editor is very limited (e.g. there are no lists and some more advanced editing options which many of users will want to use) but still it hated writing articles in it. Even now, when testing it, I'm confused where I'm inserting an image and how to make something a heading (it seriously took me a couple of secs to find that I need to select the text, because the option is in the toolbar... even though I knew it!)

Anyway, CKEditor 5's architecture will make it easy to create such an editor but I don't think that this should be the default behaviour that we'll promote.

[koleary]

Medium's editor is very limited (e.g. there are no lists and some more advanced editing options which many of users will want to use) but still it hated writing articles in it. Even now, when testing it, I'm confused where I'm inserting an image and how to make something a heading (it seriously took me a couple of secs to find that I need to select the text, because the option is in the toolbar... even though I knew it!)

So you're saying that Medium's massive success has happened despite the fact that it's editor is hard to write in? You are the first person I have ever heard suggest that. People LOVE Medium, and the reason they love it is because of it's clean and simple authoring experience. I suspect that your reaction is not your fault but a result of the curse of knowledge effect.

A good cure for the curse of knowledge is to watch and listen to real users as they use Medium or CKEditor. I guarantee you will be surprised.

[Reinmar]

As you pointed out, I can't myself prove some fact, so my comment is only my opinion. My personal observation (which I know that it's shared with some people I talked with) as a user of some application.

Beside, you made an unproved suggestion that Medium's massive success is due to the certain trait of the UI of their editor. I don't think you can prove that.

Medium provides an awesome platform, which we use ourselves, for publishing and sharing beautiful articles. The editor is just a subset of this ecosystem (quite significant, that's for sure) and how the toolbar works is a subset of that subset. So saying that Medium succeeded thanks to that specific trait of the toolbar that it appears next to the selection and only if it isn't empty is certainly logically unjustified.

We also need to remember about one more fact – Medium creates a very limited use case for the editor. They support only couple of features and in an absolutely controllable environment, adjusted for that implementation of the editor UI. That set and configuration works great for Medium, but CKEditor will be used in incomparably more situations. So what may work for Medium, may not work as a CKEditor's default solution.

I want to stress the word "default", because I've never said that such an implementation of CKEditor will not exist. It certainly will (I hope we didn't design the architecture for naught ;)). However, the developer who will want to use such a creator will need to integrate it well with his/her website and in some cases that creator may not integrate well.

[Reinmar]

A related topic (with some implementations already described) #41.

[Reinmar]

Few more after-shower thoughts :D.

What I think that might make sense would be to move some of the controls closer to the content being edited. Not necessarily the whole toolbar with all its non-contextual content, but rather the contextual part of it. In order words, what I think could work is a hybrids solution – the toolbar at the top (sticky to the editable) plus contextual toolbar appearing next to the edited part of the content.

For instance, when an image is selected some popup could appear next to it with options like "alignment", "more", "remove", etc. When part of a text is selected, then a popup with most used styling options (bold, italic, lists, headings) could appear (like on Medium). When the selection is inside a table, then we could display all the options which now are accessible only through the context menu (add/remove row/column, merge cells, etc).

These contextual options can be displayed for all kinds of editor implementations – inline, classic, full page, etc.

There's a separate topic for contextual toolbar, so I'm going to post this also there – #99.

[koleary]

@Reinmar

Of course your solution needs to be abstracted to be as flexible as possible, we have the same challenge in Drupal, and I understand that CKEditor will be configurable to create similar experiences.

As far as Medium goes I am not tying it's success entirely to the toolbar. I think you said it well that it's "publishing and sharing beautiful articles" in a "controlled environment." But I don't think you can separate the editor from that. It is an integral part of an incredibly well crafted experience.

What I'm suggesting is that the default configuration of CKEditor should be as "controlled," as beautiful, and as simple as Medium is.

[SteveTheTechie]

I think doing any kind of contextual pop-ups over text is going to be a problem on small screens (mobile). It is ok on larger screens where there is plenty of screen space, but when you start looking at the available space (on smartphones) minus space for pop-up keyboard minus space for toolbar, you already don't have much space left to show text for context. I find that covering up text for pop-ups can sometimes be very annoying if the pop-up is large or not carefully located. I am not saying that I am against it, but I am saying that frequently "less is more".

[Reinmar]

@koleary

What I'm suggesting is that the default configuration of CKEditor should be as "controlled," as beautiful, and as simple as Medium is.

I would love if we were able to control the websites with which CKEditor is integrated. That would solve many issues, because it's much easier to code when you know how your product is going to be used. Unfortunately, we lack this knowledge and I really saw only few integrations that I liked. That's a problem which we need to address, because the editor is only a part of the final solution. A big part of what the user sees is the integration. I think that the implementations which we're gonna produce will need a documentation on when to use them and what's to be considered by the developers.

@SteveTheTechie

I think doing any kind of contextual pop-ups over text is going to be a problem on small screens (mobile).

Agree. That's why we'll need to work on small devices with on-screen keyboards separately.

[Reinmar]

Cleaning up outdated discussions. See #186