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

[Style dropdown] Confusing UX in the grid of styles #11579

Open
Tracked by #14274
oleq opened this issue Apr 7, 2022 · 4 comments
Open
Tracked by #14274

[Style dropdown] Confusing UX in the grid of styles #11579

oleq opened this issue Apr 7, 2022 · 4 comments
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:style squad:core Issue to be handled by the Core team. support:2 An issue reported by a commercially licensed client.

Comments

@oleq
Copy link
Member

oleq commented Apr 7, 2022

Currently:

  • only those styles that can be applied in the current selection are enabled,
  • the rest is disabled

There are a few problems with this approach:

  1. The user must be aware that the "Heading XYZ" is not available because the selection is in a paragraph.
    • This is wrong and will only bring frustration: we cannot expect this kind of knowledge from the users even though they could figure it out eventually.
    • Proposed solution A: just like in desktop word processors, applying a style should rename the element in the model, for instance, if a paragraph is selected, clicking "Heading XYZ" should convert the paragraph into a heading and apply the style
      • Risks
        • Converting a paragraph into a table sounds weird (and vice-versa). Some cases may remain impossible but my point is that at least the majority of them should work like this.
        • Converting a paragraph into a heading could mean that some paragraph content might not be allowed in a heading (by the schema) and could be damaged/removed. CKEditor 5 is not as permissive as desktop word processors in this matter so this must be thought through before we proceed.
  2. The list of styles gets bloated if only a few are available and the rest is disabled (sort of connected to 1.)
    • Often you need to scroll and be very careful not to miss your applicable style among many inactive ones.
    • Proposed solution A: Hide inactive styles.
      • Risks:
        • This is very bad for a11y (the UI becomes unpredictable). 
        • This is also bad for people with muscle memory who expect the same thing to remain in the same place if they use the same style 100 times each day.
    • Proposed solution B: Collapse inactive styles and display them at the end of the category.
      • Risks: Probably the same risks as in A.
    • Proposed solution C: A checkbox that would filter out inactive styles.
      • Risks: Additional complexity to the UI.
  3. Whether styles are active or not, navigating 30+ of them could be very hard.
    • Lots of scrolling every time you want to apply the 24th one + hard to tell one style from another if the visual difference is subtle.
    • Proposed solution A: search input that would filter styles by name
      • Risks: Bloats the UI. 
    • Proposed solution B: a dedicated section with "recently used" styles.
      • Risks: This will look weird when there are 5 styles in total (but OK when there are 30 of them).
    • Proposed solution C: styles organized as a tree (+ maybe some way to collapse branches)
      • Risks:
        • Feels like using a sledgehammer to crack a nut, especially when there are just a few styles.
        • Does not left much room to display previews (maybe this could be an alternative look of the dropdown then?)
          • Or even better yet, this could become a styles sidebar (like comments, or track changes) and exist next to the standard dropdown. There would be enough place for a search input, recently used, and previews. A tool for advanced integrations.
@oleq oleq added squad:core Issue to be handled by the Core team. package:style domain:ui/ux This issue reports a problem related to UI or UX. labels Apr 7, 2022
@wimleers
Copy link

wimleers commented May 5, 2022

  1. The user must be aware that the "Heading XYZ" is not available because the selection is in a paragraph.

🤔 I though this was one of the pain points of StylesCombo in CKE4 that the CKE team wanted to avoid porting to CKE5? That's what the Format dropdown was for in CKE4. And it's what the Heading plugin in CKE5 does to a limited extent.

I think it is reasonable to expect that a paragraph is not a heading — first a paragraph must be converted to a heading, then a heading style can be applied using Style. Is that really unreasonable?

  1. The list of styles gets bloated if only a few are available and the rest is disabled (sort of connected to 1.)

Proposed solution D: reduce the visual prominence/screen real estate of the unavailable styles. That way, the order remains the same, (keyboard) muscle memory remains applicable, but visual scanning is accelerated.

  1. Whether styles are active or not, navigating 30+ of them could be very hard.

I think this is a premature problem to solve. Let's wait for people to run into this problem and optimize the UI for them then?

@oleq
Copy link
Member Author

oleq commented May 9, 2022

I think it is reasonable to expect that a paragraph is not a heading — first a paragraph must be converted to a heading, then a heading style can be applied using Style. Is that really unreasonable?

Honestly, I'm also having second thoughts about it. On one hand, I think this would greatly improve the UX. On the other hand, this is another layer of complexity on top of what we already have. Maybe some sort of information as to why the particular style in unavailable would help? (a tooltip maybe) 

Proposed solution D: reduce the visual prominence/screen real estate of the unavailable styles. That way, the order remains the same, (keyboard) muscle memory remains applicable, but visual scanning is accelerated

This makes sense 👍 But I identified two problems with this approach:

  1. The first one comes down to 1.. How do we explain that some styles look like this and do that and the rest looks different and does nothing? The latter will probably lose previews to save space. Is this enough to drive the point home?
  2. What the layout should look like? 
    1. ATM we're having main categories (block vs text) as a two grids. 
    2. This enhancement will bring active vs inactive sub-categories inside each main category. 
    3. Also, inactive ones must look different to save space (posting the screenshot to bootstrap the creative process 🙂). 

Removing preview and changing height will create a weird layout (first row) and moving "Large paragraph" down to the next row will break the muscle memory patters. Also, this assumes that there's sorting enabled which will break the muscle memory patterns in the first place.

I think this is a premature problem to solve. Let's wait for people to run into this problem and optimize the UI for them then?

👍

@oleq
Copy link
Member Author

oleq commented May 9, 2022

I'm also cross-linking #11580 because I noticed that removing styles when multiple have been applied becomes a chore (click the dropdown, remove style A, click the dropdown, remove style B, ...). 

  • On one hand, we could stop hiding the dropdown when the style is applied and removed.
    • OTOH I suppose the majority of users will apply one style at a time and they expect the UI to hide.
  • I think this may go beyond integration with the "Remove formatting" button (which is fine). We may need a dedicated UI in the style dropdown to get rid of all styles with a single click.

@aldonace-wu aldonace-wu added the support:2 An issue reported by a commercially licensed client. label Nov 17, 2022
@wimleers
Copy link

FYI: this continues to be raised frequently in the #ckeditor5 Drupal Slack channel!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:style squad:core Issue to be handled by the Core team. support:2 An issue reported by a commercially licensed client.
Projects
None yet
Development

No branches or pull requests

3 participants