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

Implement UI part for List Styles feature #7803

Closed
pomek opened this issue Aug 7, 2020 · 7 comments
Closed

Implement UI part for List Styles feature #7803

pomek opened this issue Aug 7, 2020 · 7 comments
Assignees
Labels
package:list squad:core Issue to be handled by the Core team. type:feature This issue reports a feature request (an idea for a new functionality or a missing option).

Comments

@pomek
Copy link
Member

pomek commented Aug 7, 2020

Part of #1031.

@pomek pomek added type:feature This issue reports a feature request (an idea for a new functionality or a missing option). package:list squad:core Issue to be handled by the Core team. labels Aug 7, 2020
@pomek pomek added this to the iteration 35 milestone Aug 7, 2020
@pomek
Copy link
Member Author

pomek commented Aug 7, 2020

Blindly estimated as 2.

@oleq oleq self-assigned this Aug 12, 2020
@oleq
Copy link
Member

oleq commented Aug 13, 2020

Designs

Unordered list styles

Ordered list styles

Button states

I followed the hover styles first implemented in special characters and combined them with heading dropdown active styles.

The question of default/revert

Context and Problem Statement

My designs contain the "reset/default/revert" button although I haven't found any WYSIWYG editor out there that would use such a thing. I wanted to see how would it look. The button is a tricky thing because it's a feature of CSS world but a potential UX anti-pattern.

Decision drivers

  • The feature should be as useful as it is possible to the users (they should be able to do everything with it – apply styles, change and reset them).
  • Users should not be confused about what each button does.

Considered options

Use the "reset" button

  1. When clicked, the "reset" button removes the attribute completely from the model.
  2. In this scenario, all buttons work one way (previous style -> new style). Clicking the same button twice will not toggle/reset the style.

Don't use the "reset" button

  1. In this scenario, assuming that if a selection is inside a list but there's no style applied in the model, simply none of the buttons will be active.
    1. Alternatively, we can activate the "most likely style". If a list is numbered, we can assume that most CMSs/UAs/web pages will style it as "numbered" ("1.").
  2. If a style has already been applied, the only way to reset it back to the CSS cascade/inherit is clicking its button once again.
    1. So in this scenario buttons work as toggles.

Pros and Cons of the Options

Option 1 (use the "reset" button)

👍 The button is logical from the CSS perspective – removing the inline style falls back to the inherited (UA) style and this makes sense.

👎 The button is totally illogical from the UX perspective – you need to understand CSS to know what's going on there. Non-technical users will be confused about what it is for – they see a numbered list in the content but the numbered list button is not active. Why? (they do not know that the style isn't in the model, it's just a UA/CMS default list style)

👎 No one uses this kind of button in their UI.

Option 2 (do not use the button)

👍 There is no confusion around what the button is for because... there is no button.

👍 Cleaner, uncluttered UI.

👎 If we go with the "no style in the model, no active button" approach, users may be confused why their list is numbered but "numbered" style in the drop-down is inactive (they don't know its a browser/CMS default style being rendered).

👎 If we go with the "no style in the model, activate the most likely button" approach, users may be confused why their list is numbered using roman letters (I. II. III.) but the Arabic (1. 2. 3.) style in the drop-down is active (the default browser/CMS style for <ul> was roman).

👎 (unlikely) But if someone wanted to reset their list style back to the browser/CMS default, they have to discover they need to click the active style again (low discoverability).

@niegowski
Copy link
Contributor

If we are voting, then I'm for the 2nd option. 

👎 If we go with the "no style in the model, no active button" approach, users may be confused why their list is numbered but "numbered" style in the drop-down is inactive (they don't know its a browser/CMS default style being rendered).

The same happens for the font family feature when supportAllValues is activated. If there was some font in the editor data that wasn't configured then none of the options is selected. Also, there is the "Default" option that is for the no-attribute state.

👎 (unlikely) But if someone wanted to reset their list style back to the browser/CMS default, they have to discover they need to click the active style again (low discoverability).

Users always can use the "Remove Format" button.

@oleq
Copy link
Member

oleq commented Aug 13, 2020

Users always can use the "Remove Format" button.

A side-question to @pomek: Do the list styles have the isFormatting property?

@Reinmar
Copy link
Member

Reinmar commented Aug 13, 2020

Thanks @oleq for the research.

I think I'd go with the 2nd option as well. I feel that we can always add the reset button if we see that "click the active option to remove" is not discoverable.

👎 If we go with the "no style in the model, no active button" approach, users may be confused why their list is numbered but "numbered" style in the drop-down is inactive (they don't know its a browser/CMS default style being rendered).

This applies to both options, right?

👎 If we go with the "no style in the model, activate the most likely button" approach, users may be confused why their list is numbered using roman letters (I. II. III.) but the Arabic (1. 2. 3.) style in the drop-down is active (the default browser/CMS style for <ul> was roman).

OK, now I understand the previous point :D Yeah... I think I'm for "no style in the model, no active button".

@pomek
Copy link
Member Author

pomek commented Aug 14, 2020

A side-question to @pomek: Do the list styles have the isFormatting property?

Not yet but I'll add it.

pomek added a commit that referenced this issue Aug 18, 2020
Internal (list): Created the list styles UI. Closes #7803.
@pomek
Copy link
Member Author

pomek commented Aug 18, 2020

Done in #7845.

@pomek pomek closed this as completed Aug 18, 2020
jodator added a commit that referenced this issue Aug 21, 2020
Feature (list): Introduced the list styles feature that allows customizing the list's marker of the list item elements. Closes #7801.

Feature (theme-lark): Creates styles for the `ListStylesUI` plugin (see #7803).

MINOR BREAKING CHANGE (ui): It is now possible to override existing components when [adding new ones](https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_componentfactory-ComponentFactory.html#function-add) to the [component factory](https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_componentfactory-ComponentFactory.html) (previously an error was thrown) (see #7803).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:list squad:core Issue to be handled by the Core team. type:feature This issue reports a feature request (an idea for a new functionality or a missing option).
Projects
None yet
Development

No branches or pull requests

4 participants