-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UX: Contextual toolbars #99
Comments
There is a good chance that the contextual toolbar will, if ever implemented, add more items on top of the default set on most of the "special content" cases like the one exemplified (e.g. text inside list). A reduction may be seem on "object" selections, like images or tables. |
I think that contextual set of UX elements works best on floating toolbar (be it anchored to caret position or to selected element, like image or table cell). I think that hiding part of UI items is bad in stuck toolbar. Maybe usable ("new") contextual UX items could be show in an extra tab (auto-selected), that would otherwise be not available. |
Yes, I've seen them only after I commented here. |
You could also add a contextual tab containing special toolbar items like MS Word does with its "ribbon". I tend to think end users will want some consistency in the UI, so having a lot of disappearing and appearing toolbar items in a frequently used toolbar could lead to confusion. You need at least one "main" toolbar to be consistent and familiar. |
+1 for what @scofalik wrote. A fixed toolbar with many disabled buttons is confusing/overwhelming/ugly. But @SteveTheTechie of course makes a good point too. |
@SteveTheTechie Something like "In–toolbar editing (super–contextual toolbar)" in #97? |
Yes... you could do something like that. |
I posted some ideas about contextual toolbars in #98 (comment). |
Cleaning up old discussions. See #186. |
Does CKEditor 5 need contextual toolbars?
"Default" context toolbar
Specific context toolbar
The text was updated successfully, but these errors were encountered: