Skip to content
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

Closed
oleq opened this issue Jan 19, 2016 · 10 comments
Closed

UX: Contextual toolbars #99

oleq opened this issue Jan 19, 2016 · 10 comments

Comments

@oleq
Copy link
Member

oleq commented Jan 19, 2016

Does CKEditor 5 need contextual toolbars?

  • When buttons should disappear? In which situations?
  • When buttons shouldn’t disappear? Are disappearing buttons confusing?
    • Should there be an indicator in the toolbar which would identify the context (state) of the toolbar (like "editing table at the moment")?

"Default" context toolbar

image

Specific context toolbar

image

@fredck
Copy link
Contributor

fredck commented Jan 19, 2016

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.

@scofalik
Copy link

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.

@oleq
Copy link
Member Author

oleq commented Jan 19, 2016

@scofalik Something like "In–toolbar editing (super–contextual toolbar)" in #97?

@scofalik
Copy link

Yes, I've seen them only after I commented here.
Which maybe is a point that the idea is good :P

@SteveTheTechie
Copy link

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.

@wimleers
Copy link

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

@oleq
Copy link
Member Author

oleq commented Jan 21, 2016

@SteveTheTechie Something like "In–toolbar editing (super–contextual toolbar)" in #97?

@SteveTheTechie
Copy link

@SteveTheTechie Something like "In–toolbar editing (super–contextual toolbar)" in #97?

Yes... you could do something like that.

@Reinmar
Copy link
Member

Reinmar commented Feb 19, 2016

I posted some ideas about contextual toolbars in #98 (comment).

@Reinmar
Copy link
Member

Reinmar commented Apr 20, 2018

Cleaning up old discussions. See #186.

@Reinmar Reinmar closed this as completed Apr 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants