UX: Drop–down inputs in the toolbar

[oleq]

Are classical drop–downs too heavy in a modern UI?

Note: The initial discussion in #95.

• Could button drop–downs completely replace classical drop–downs with previews (CKEditor 3+–like)?
  • Wouldn't losing a preview for fields like "font face" or "font size" bee too much a simplification?
  • How much space could be saved?
• What are the current trends?

---

A drop–down with a preview

A preview–less, button drop–down

[SteveTheTechie]

My 2 cents: This could work if you can indicate the current style characteristics somewhere else... e.g., in a status bar or similar. However, I tend to not want to hunt around for an indication when the obvious indicator is the control I just used. If you do not use the control for indication, what would you show on the button?

[fredck]

I was originally thinking on how the button could be used to indicate the selection state. Some ideas:

1. Have on/off state, just like the bold button. This could work for features like "font", where the values are very random and too long.
2. Instead of having an icon on the button, we could use a "icon like" text. For example, the "block style" button could should "H2" for a header, "P" for a paragraph or "Q" for a blockquote. Not super intuitive at first but one would get it straight while using it.

"2" maybe would work even for fonts: "Ti" for times, "He" for helvetica, "Ge" for Georgia, etc.

We could have "2" with "1", having the button "on" when the default value is not selected. For example, it would be "off" in a paragraph, but "on" in a header.

[scofalik]

I am not sure I like this idea. It means that buttons look different depending on what you edit. This will be harder for users to grasp, because they might look after an icon they remember and not find it. I am against this.

[fredck]

It means that buttons look different depending on what you edit. This will be harder for users to grasp, because they might look after an icon they remember and not find it.

That may be true.

Maybe instead of making it look like an ordinary button it could look like something else... like a short selection box... or a slightly longer button with "icon + 2 letters"... or maybe any other creative way to represent it.

[oleq]

I'm not a huge enthusiast of replacing classical drop–downs with something else either, at least for formatting stuff like font face, font size. This kind of control seems to be a "core UI element" of any WYSI* editor in the market because it gives a clear feedback to the users.

[fredck]

This kind of control seems to be a "core UI element" of any WYSI* editor in the market

I have a bit of a different opinion. Even if this may be true, one of the biggest UX issues with online editors is that we've been trying to mimic desktop editors, like MS Word. We're proposing the same solutions in a different environment. Everybody is mostly doing the same.

The whole point of talking about UX publicly is to eventually find other possibilities, fixing the above approach.

In fact, we started to see editors that not even show a toolbar, unless anything is selected. Others use in fact the "button" approach in such features.

Additionally, we're talking here about the "default" implementation of CKEditor. I'm sure that there will be solutions that will want the traditional "selection box" way, so we may see both ways out there.

It's not my intention to force any solution though. Just wanted to reply to the "market standard" statement, for us to not take it improperly.

[quasipickle]

A loss of the preview would be a huge hit to the UX. How else would someone get an overview of the styles being applied to the current element?

I think replacing the default with a nicer looking widget would be a plus - but there's no reason the preview needs to disappear.

mrmnmly commented 8 years ago

Wouldn't losing a preview for fields like "font face" or "font size" bee too much a simplification?

Probably it will be - and I think this will slow users down (because they will have to click/hover on the button to see its value instead of just taking a look on toolbar - it's always better to minimize amounts of clicks)

What are the current trends?

I think that nowadays everyone want to replace classic form inputs with some fancy ones, not exactly very good for UX (also known as dribbblisation effect: https://blog.intercom.io/the-dribbblisation-of-design/)

This:

I tend to not want to hunt around for an indication when the obvious indicator is the control I just used

Good point.

Also this:

A loss of the preview would be a huge hit to the UX. How else would someone get an overview of the styles being applied to the current element?

Click, click (or hover over button) to preview style values - it's not so good solution for UX

And finally:

I think replacing the default with a nicer looking widget would be a plus - but there's no reason the preview needs to disappear.

+1

We can see that design market has tendency to minimalistic approach, but less not always means better.

fredck commented 8 years ago

In the other hand, we're talking about features which are not supposed to end up in the default distribution of CKEditor (Font and Font Size). These sound like "big apps" features so having select-boxes for them would fit their use case.

I would be focused on trying to find good ways to propose the default features instead. Looking at CKEditor 4, we are mainly talking about the "Block Format" (or "Block Type") feature. Maybe the "icon + 2 letters" thing would work for it?

Note that the whole point of this issue is to try to figure out if the select-boxes can be replaced by something that could help on having a more compact toolbar (wishing for a one line toolbar).

mrmnmly commented 8 years ago

wishing for a one line toolbar

Maybe there should be done some work on better tools categorization and spending some time on grouping tools into separate tabs?

fredck commented 8 years ago

grouping tools into separate tabs

The whole point for wishing for a one line toolbar is exactly to have "less UI". If we add tabs, not only we have "more UI" but we also have an additional UI element ("toolbar" vs "tabs + toolbar").

mrmnmly commented 8 years ago

@fredck oh, okay - sorry I've misunderstood this - You're right, tabs would be "more UI" in that context ;)

oleq commented 8 years ago

I would be focused on trying to find good ways to propose the default features instead. Looking at CKEditor 4, we are mainly talking about the "Block Format" (or "Block Type") feature. Maybe the "icon + 2 letters" thing would work for it?

Truth to tell, this is what we had since CKEditor 3+ (to some extent).

What the dropdown really shows is that:

There's a style applied under current selection because the label is different than default ("Special..." vs "Styles").

This is a weak indicator because user must know the initial state ("Styles" label) of the dropdown to acknowledge some custom state ("Special..." label) and, for some particular combination of content/selection, they could completely miss the default state. Then the "Styles" dropdown would become "Special..." dropdown, which is clearly a misconception – there's no distinguishing between the feature (Styles dropdown) and it's value (Special Container).

The name of the style is truncated.

There could be many styles starting with the same string (Special Kittens, Special Potatoes, etc.). It's not very helpful then.

Whatever style is applied, the user must know its name because, unlike in desktop word processors, there's no toolbar preview.

It contradicts the idea of having a styles dropdown in the toolbar, IMO. It should either provide clear preview or show nothing but the icon.

See, the styling flow is as follows:

1. My text is not styled.
2. I want to style my text.
3. I click the control responsible for styling text in the toolbar.
4. I select the style that I want to apply. I need a preview, my style is not yet applied (this is why dropdown expands).
5. My style is applied – I know this because I see my paragraph in WYSIWYG area styled.

The flow does not require a preview in the toolbar because it is either:

• in the WYSIWYG content, when the style is applied.
• in the dropdown, when selecting a new style.

So the conclusion is that the visual feedback in the toolbar (style preview) might not be so essential for the UX. And given that the label in the dropdown is not very helpful either, because it makes hard to tell what is feature and what is value (which is truncated anyway), I would seriously consider A preview–less, button drop–down scenario (icon + dropdown) despite my previous comment.

fredck commented 8 years ago

@oleq, I share most of your thoughts.

Wouldn't anyway a minimalist preview be helpful for power users, like the following idea I've proposed earlier?

oleq commented 8 years ago

@fredck I think that development effort >>> usability gain here. It's alright for H2, but for any other style it's pretty ambiguous. I mean, yes, we could implement it this way and power users surely would benefit but "regular users" may find it confusing (what is "He" when you don't know the list of styles by heart?).

:+1: for the icon though.

fredck commented 8 years ago

Well, the cool thing is that, with the new API, we'll be able to (relatively) easily bring other variations to the same solution to life, so we'll be able to test different solutions. Not in the beginning of course, but later on, if time permits.

amitev commented 8 years ago

BTW please don't use iframe for dropdowns in the editor's toolbar. Makes the testing using tools like Selenium more complicated.

Reinmar commented 8 years ago

We don't plan to use iframes any more (although such a feature may exist if someone wants to code it, because the architecture allows that).

It's not only a problem for testing with Selenium – it makes everything hard. Coding features, handling browser quirks, testing from JS, handling screen readers, supporting keyboard nav, etc.

OTOH, we lose the ability to style contents of the dropdowns using the same stylesheet which is used for contents of the editor (that's the original reason why iframes where used), but that's something that I guess everyone can live with.

Reinmar commented 6 years ago

Cleaning up old discussions. See https://github.com/ckeditor/ckeditor5-design/issues/186.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[mrmnmly]

Wouldn't losing a preview for fields like "font face" or "font size" bee too much a simplification?

Probably it will be - and I think this will slow users down (because they will have to click/hover on the button to see its value instead of just taking a look on toolbar - it's always better to minimize amounts of clicks)

What are the current trends?

I think that nowadays everyone want to replace classic form inputs with some fancy ones, not exactly very good for UX (also known as dribbblisation effect: https://blog.intercom.io/the-dribbblisation-of-design/)

This:

I tend to not want to hunt around for an indication when the obvious indicator is the control I just used

Good point.

Also this:

A loss of the preview would be a huge hit to the UX. How else would someone get an overview of the styles being applied to the current element?

Click, click (or hover over button) to preview style values - it's not so good solution for UX

And finally:

I think replacing the default with a nicer looking widget would be a plus - but there's no reason the preview needs to disappear.

+1

We can see that design market has tendency to minimalistic approach, but less not always means better.

[fredck]

In the other hand, we're talking about features which are not supposed to end up in the default distribution of CKEditor (Font and Font Size). These sound like "big apps" features so having select-boxes for them would fit their use case.

I would be focused on trying to find good ways to propose the default features instead. Looking at CKEditor 4, we are mainly talking about the "Block Format" (or "Block Type") feature. Maybe the "icon + 2 letters" thing would work for it?

Note that the whole point of this issue is to try to figure out if the select-boxes can be replaced by something that could help on having a more compact toolbar (wishing for a one line toolbar).

[mrmnmly]

wishing for a one line toolbar

Maybe there should be done some work on better tools categorization and spending some time on grouping tools into separate tabs?

[fredck]

grouping tools into separate tabs

The whole point for wishing for a one line toolbar is exactly to have "less UI". If we add tabs, not only we have "more UI" but we also have an additional UI element ("toolbar" vs "tabs + toolbar").

[mrmnmly]

@fredck oh, okay - sorry I've misunderstood this - You're right, tabs would be "more UI" in that context ;)

[oleq]

I would be focused on trying to find good ways to propose the default features instead. Looking at CKEditor 4, we are mainly talking about the "Block Format" (or "Block Type") feature. Maybe the "icon + 2 letters" thing would work for it?

Truth to tell, this is what we had since CKEditor 3+ (to some extent).

What the dropdown really shows is that:

There's a style applied under current selection because the label is different than default ("Special..." vs "Styles").

This is a weak indicator because user must know the initial state ("Styles" label) of the dropdown to acknowledge some custom state ("Special..." label) and, for some particular combination of content/selection, they could completely miss the default state. Then the "Styles" dropdown would become "Special..." dropdown, which is clearly a misconception – there's no distinguishing between the feature (Styles dropdown) and it's value (Special Container).

The name of the style is truncated.

There could be many styles starting with the same string (Special Kittens, Special Potatoes, etc.). It's not very helpful then.

Whatever style is applied, the user must know its name because, unlike in desktop word processors, there's no toolbar preview.

It contradicts the idea of having a styles dropdown in the toolbar, IMO. It should either provide clear preview or show nothing but the icon.

See, the styling flow is as follows:

1. My text is not styled.
2. I want to style my text.
3. I click the control responsible for styling text in the toolbar.
4. I select the style that I want to apply. I need a preview, my style is not yet applied (this is why dropdown expands).
5. My style is applied – I know this because I see my paragraph in WYSIWYG area styled.

The flow does not require a preview in the toolbar because it is either:

• in the WYSIWYG content, when the style is applied.
• in the dropdown, when selecting a new style.

So the conclusion is that the visual feedback in the toolbar (style preview) might not be so essential for the UX. And given that the label in the dropdown is not very helpful either, because it makes hard to tell what is feature and what is value (which is truncated anyway), I would seriously consider A preview–less, button drop–down scenario (icon + dropdown) despite my previous comment.

[fredck]

@oleq, I share most of your thoughts.

Wouldn't anyway a minimalist preview be helpful for power users, like the following idea I've proposed earlier?

[oleq]

@fredck I think that development effort >>> usability gain here. It's alright for H2, but for any other style it's pretty ambiguous. I mean, yes, we could implement it this way and power users surely would benefit but "regular users" may find it confusing (what is "He" when you don't know the list of styles by heart?).

:+1: for the icon though.

[fredck]

Well, the cool thing is that, with the new API, we'll be able to (relatively) easily bring other variations to the same solution to life, so we'll be able to test different solutions. Not in the beginning of course, but later on, if time permits.

[amitev]

BTW please don't use iframe for dropdowns in the editor's toolbar. Makes the testing using tools like Selenium more complicated.

[Reinmar]

We don't plan to use iframes any more (although such a feature may exist if someone wants to code it, because the architecture allows that).

It's not only a problem for testing with Selenium – it makes everything hard. Coding features, handling browser quirks, testing from JS, handling screen readers, supporting keyboard nav, etc.

OTOH, we lose the ability to style contents of the dropdowns using the same stylesheet which is used for contents of the editor (that's the original reason why iframes where used), but that's something that I guess everyone can live with.

[Reinmar]

Cleaning up old discussions. See https://github.com/ckeditor/ckeditor5-design/issues/186.