Only show CKEditor's toolbar (in framed mode) when the editing area has focus

The study showed, that there was an increase in cognitive load? I'd gladly see the resulting study point that proved this.

Other than that, this seems like a easy tweak - not sure what to review here, this needs a patch I think to determine whether it feels right.

Also, we had this for Aloha Editor, and everybody HATED it. It was disturbing. Everything jumped around.

So I presume you want the CKEditor toolbar to be hidden, yet its space already reserved, so nothing will jump around?

#5: Hm, okay. I'm not convinced. An animation implies a delay. Which implies frustrating frequent users. A sufficiently fast (to not delay/frustrate the user) animation might still cause a jarring experience.

In short: this needs experimentation. But this is really the cherry on the cake, I think. Not sure if the "normal" priority is warranted.

This is not a bug. Nothing is broken. At best this is a task. But "feature request" feels more appropriate, because it's not even certain we should do it.

We should check this before release, because once Drupal 8 is out, we can't make such a big UX change anymore AFAIK. And as Bojhan said, this probably needs usability testing.

I improved the title.

.

edited

Untagging, not sure why this would be tied to release/beta at all.

Because We should check this before release, because once Drupal 8 is out, we can't make such a big UX change anymore AFAIK. And as Bojhan said, this probably needs usability testing., but I agree that the benefit is negligible, therefore it's appropriate to not have these tags.

I talked to @tkoleary about this:

Do you think https://www.drupal.org/node/2064491 is still relevant?

[17:40] 
It's the oldest CKE issue in D8 by far

Kevin Oleary [18:02] 
Maybe needs an update

Wim Leers [18:02] 
but you still think that should happen, ideally?

Kevin Oleary [18:10] 
Well, what I’d say is that ideally the tools should be divided in to two bars, one for adding things (eg. image) and one for editing things (eg. B ​_I_​ U). The second should be contextual and appear directly above the cursor only when a selection is made. The first ​_could_​ be hidden and appear (at the top of the text area) on focus, but that becomes less important if we move the “edit” tools into context.

Wim Leers [18:16] 
That's something of an entirely different magnitude what you describe there:

1. two bars: edit + add. This means we'd have to enforce this in the drag-and-drop UI too
2. making the second contextual is basically reimplementing the CKEditor toolbar UI logic — instead of buttons just being disabled, they'd disappear

Not to mention this opens lots of new problems:
A. the context-dependent edit-bar should only show buttons for the current context, which means EITHER buttons appearing in different places depending on context OR gaps between buttons
B. what if you have >2 rows/bars? i.e. if not everything fits?
C. on constrained screens (e.g. smartphone), this will cause positioning problems: when a bar appears, EITHER the content moves underneath you OR the bar can appear in an invisible part of the page. Either is highly problematic

[18:17] 
So, if that's what you want to do, then I think I need to move this to D9.

[18:17] 
Especially because it's not at all proven this is actually better.

[18:17] 
Seems a very risky, very big change.

Kevin Oleary [18:18] 
Yes, I’m thinking that this is CK5

Wim Leers [18:18] 
right

[18:18] 
okay

[18:18] 
so in that case, we'll need to start over anyway

[18:18] 
or we'll ​_want_​ to at least

[18:18] 
So… just close it then?

Kevin Oleary [18:18] 
My head is in CK5 since I’m commenting on CK5 issues right now

Wim Leers [18:18] 
Because yes, CKEditor 5 is ​_designed_​ with custom UIs in mind

Kevin Oleary [18:18] 
I would close it

Wim Leers [18:18] 
Ah :) That explains a lot!

[18:18] 
:D

[18:19] 
Okay, great. Glad to hear you're commenting on CKE5 issues :)