The default heading title is confusing... still

[Reinmar]

When I saw that and moved my caret around without seeing any label's changes I was about to report a ticket that the state od the dropdown isn't updated for some reason. It was really like my 3rd thought that – wait, this doesn't say "Heading 1" but just "Heading" which is the default title meaning "no heading".

So the "Heading" meaning "no heading" is somehow confusing. I don't know if you agree but I think that we still need to do something about it...

One idea that came to my mind was that perhaps the label should be dimmed to look like a placeholder or something ("chose a heading level" just like "type here" in an editable). Or we could use a different text. Or something... :D

[fredck]

GDocs has a nice way for this... it calls "Normal text" everything that is not a heading, including paragraphs. I would go that way as well.

[oleq]

GDocs has a nice way for this... it calls "Normal text" everything that is not a heading, including paragraphs. I would go that way as well.

It's not gonna work. Note that they completely remove non–related toolbar items e.g. when the image is selected. They can name it "normal text" because they don't display it at all when non–text objects are selected.

We don't have such luxury, so we either we stay with what we have or we must figure out a better name. Or implement a totally dynamic toolbar...

One idea that came to my mind was that perhaps the label should be dimmed to look like a placeholder or something ("chose a heading level" just like "type here" in an editable). Or we could use a different text. Or something... :D

The label must be short. "Heading level" would be enough, I suppose.

[Reinmar]

Isn't "Normal text" like "Paragraph" in GDocs? It's also enabled when you are in paragraphs. So we won't follow this practice precisely because we have a special dropdown position for paragraphs (unless we'd changed this too).

But as a label itself "Normal text" may be good. OTOH, what would it change comparing to the current "Heading" label? We won't call list items "headings" which is a good thing. But we'll also lose the label – it won't indicate that it's a heading dropdown.

[fredck]

Q1: Would renaming "Paragraph" to "Normal text" be that bad? It sounds less technical and as we can see it fits more cases.

Q2: Would leaving the select-box empty in case of object selections be that bad? There would be the tooltip to help, if one really forgets what was there, and one doesn't really care about that when selecting an image because the (person) focus is somewhere else.

[Reinmar]

Q1: Would renaming "Paragraph" to "Normal text" be that bad? It sounds less technical and as we can see it fits more cases.

"Normal text" is more general because it can include paragraphs and also list items. It just says "I'm not a heading" which is better than saying "I'm a paragraph". The former works in lists and will work in table cells. The latter not.

So, I think I like this.

Q2: Would leaving the select-box empty in case of object selections be that bad?

You mean – no label? I think it'd be odd. And you'd need to hover it to understand what it is (if you happened to forget and you noticed it while being in lists or somewhere). I think I like the "Normal text" solution more.

[oleq]

We can't use "normal text" or "paragraph" when the selection is not in a heading.

Think of block objects, which are NOT a heading AND not a "normal text/paragraph" either. Like an image.

Q2: Would leaving the select-box empty in case of object selections be that bad?

I'll pretend I didn't read this ;-)

---

Long story short:

• we can rename "paragraph" to "normal text".
• we cannot use it for all non-heading content, though
  1. remember about the image case
  2. remember that what is displayed in the button is active for the selection. We cannot display "paragraph" or "normal text" when in the list item because it's not a paragraph or normal text. It's a list item and to confirm it, if you open the dropdown you'll see the "paragraph/normal text" item is inactive.
  3. we must display the active value corresponding with the selection AND description of the feature when selection has nothing to do with Heading feature (list, image, table, etc.) AND deactivate it when the Heading feature can't be applied.

[Reinmar]

But what's the problem with "normal text". It's a "text" – everything like list, inline captions, tables, etc. contain text. So "normal text" applies well to those situations. "Paragraph" would not, but it has a much more specific, narrower meaning.

The only problem for me is object selection, but in such a case the button should be disabled anyway so it can display anything or nothing.

[oleq]

So "normal text" applies well to those situations. "Paragraph" would not, but it has a much more specific, narrower meaning.

The problem is as follows:

1. You're in a list item.
2. Dropdown button displays "normal text".
3. You open the dropdown and find out it's inactive (so why it's displayed in the button?).
4. You click it and activate it.
5. You clearly changed something. Because you did. But the button still says it's a "normal text".
6. So you go to the dropdown and deactivate it.
7. The button still says you're in a "normal text".

Can't you see the madness behind this?

[Reinmar]

Note that when you do "4", then the list item is converted to a paragraph so it actually does something. The label may not change, but now the dropdown item will be selected.

Steps 6-7 won't happen – you can't deactivate this particular style.

But I agree – it's not perfect. Still – do we have any better idea?

[oleq]

But I agree – it's not perfect. Still – do we have any better idea?

Yes. When the selection doesn't include any heading, the button's label should fall back to "Chose heading" or similar.

[fredck]

I'll pretend I didn't read this ;-)

Actually, I should pretend not having read this :(

[fredck]

Q2: Would leaving the select-box empty in case of object selections be that bad?

You mean – no label? I think it'd be odd. And you'd need to hover it to understand what it is (if you happened to forget and you noticed it while being in lists or somewhere). I think I like the "Normal text" solution more.

I wasn't mentioning the list case but object selections, like images and anything that is not text.

[fredck]

Additionally, what about disabling the select-box on context it can't be used (lists, images, etc)?

[Reinmar]

Additionally, what about disabling the select-box on context it can't be used (lists, images, etc)?

If we'd disabled it on the lists then we'd lose the ability to quickly convert lists into other types of blocks (which works now just fine). You'd first need to remove the list and then apply the format. This is not like a super popular use case but I've never seen the format dropdown disabled and I think it might be confusing.

[fredck]

If we'd disabled it on the lists then we'd lose the ability to quickly convert lists into other types of blocks (which works now just fine). You'd first need to remove the list and then apply the format. This is not like a super popular use case but I've never seen the format dropdown disabled and I think it might be confusing.

Ah, true... I forgot that this is the current behavior of it. I thought that right now it was doing nothing.

But to tell you the truth, I would not expect it to remove the list item and change it to a heading. I would instead expect that the contents of the list item would be transformed into a heading, remaining the list item. I think we have confusion here anyway.

[Reinmar]

But to tell you the truth, I would not expect it to remove the list item and change it to a heading. I would instead expect that the contents of the list item would be transformed into a heading, remaining the list item. I think we have confusion here anyway.

It's a matter of a mental model. The users should understand pretty quickly that a "line" of text is a heading or a paragraph or a list item. But as we talked in the past – I know that people will ask for more. It's a question, though, how are we going to provide that "more".

So, even if item => heading conversion is a confusion, at least there's an action so the user gets something and knows that something went wrong (if his/her intentions were different). With a disabled dropdown there's no chance for an action and there are no indications what to do to achieve the intended goal.

[fredck]

With a disabled dropdown there's no chance for an action and there are no indications what to do to achieve the intended goal.

Sure... the problem is that the intended goal is having a heading inside a list item... that was my point :(

[Reinmar]

Sure... the problem is that the intended goal is having a heading inside a list item... that was my point :(

I understand. But that's a totally separate topic to me. In this model, you can have one or another, not both. Hence, the behaviour of the heading dropdown should support this.

For example, in a different model you can apply heading "style" to a part of a paragraph. You know that some developers ask to make this possible but we totally drop this from our minds when designing the behaviour our features because, despite being a viable feature for a word processor, it's not part of model.

I think we should do the same with the heading dropdown and list items here – focus on the fact that in this model you convert from item to heading, so the features should support that.

[fredck]

I just feel that, unlike the other model you exemplified, the model you support doesn't exist, in the POV of real end users, because it is kind of senseless. I really doubt there are real occasions when one wants to transform a list item straight into a heading. Therefore we can even impose this as our way, but it is hard to justify it.

Also, proposing a behavior now will make it harder in the future, if we would ever want to make it possible to have headers inside list items (generally, blocks inside list items). Users may get used to the previous behavior and get confused.

I mean, it is better to propose nothing, for now, than whatever.

[Reinmar]

Also, proposing a behavior now will make it harder in the future, if we would ever want to make it possible to have headers inside list items (generally, blocks inside list items). Users may get used to the previous behavior and get confused.

Hm... I'm afraid that one thing wasn't clear here.

These are totally separate features – article lists and document lists. I don't think there will be a gradual path from the current article lists implementation to the document lists. The implementation of document lists feature will require a lot of UX research and design anyway. And, as a developer, you'll choose either A or D, not both.

Hence, I'd really not consider document lists feature here now. This is out of the scope and this will not concern the users which will use the article lists feature.

BTW. I've just checked that Medium and Draft are doing exactly what we're doing. You can switch from a list directly to a heading and (in Draft only) from a heading to a list item.

[oleq]

I agree with @fredck that it's better to block some behavior, which makes little sense than to offer it just because we can at this stage of development.

But anyway, I think we went a little bit off–topic in this conversation. The issue is about how to advertise that heading feature offers no such option that selection is attached to. Not whether some options are applicable and what would happen if one decided to use them in some context.

So I propose:

1. "Chose heading" label when the selection is anchored in the list item and the transition makes some sense, i.e. into a paragraph.
   1. A follow–up issue to discuss whether applying header to a list item makes sense.
2. "Paragraph" label stays for <p>, nothing changes here.
3. Disable the dropdown for objects like image widget.

[Reinmar]

I agree with @fredck that it's better to block some behavior, which makes little sense than to offer it just because we can at this stage of development.

This is not "at this stage". This is forever. We're talking here about a feature which won't change. The only thing which may change is that we'll implement a second list feature in the future, but then we can align the heading dropdown behaviour to work well with that second list feature, without changing how it works with the current one.

Anyway, this is an off-topic indeed :D

"Chose heading" label when the selection is anchored in the list item and the transition makes some sense, i.e. into a paragraph.

I'm fine with that. I'm also fine with "Normal text".

Disable the dropdown for objects like image widget.

I'm fine with that too.

[fredck]

Concluding the off-topic :P

the problem is that the intended goal is having a heading inside a list item

Repeating myself :)

No matter if we say that this is another feature for the document editor, etc... the way we present it in the article editor will push users to have the above intention. That's why it's better to do nothing (disable the select-box) than providing a misleading feature.

[Reinmar]

I really don't understand your way of thinking... You want to disable a feature just because its (completely revertable) effect may be confusing for some users. This way you'll force them to figure out that to make a heading out of e.g. a pasted list item they need to first convert it to a paragraph (by removing the list) and then apply the heading.

I already showed you two editors which implement the same behaviour as we do. I showed that the change you're proposing will be confusing as well. And I replied to the only argument against the change that appeared here ("the problem is that the intended goal is having a heading inside a list item") by pointing out that by wrong assumptions regarding the model (like – "how can I style just half of a paragraph?") you can come to wrong conclusions regarding UX. And what you're doing is just assuming that my and Medium's and Draft's guys POV is wrong:

I just feel that, unlike the other model you exemplified, the model you support doesn't exist, in the POV of real end users, because it is kind of senseless.

So, concluding, you want to remove an already implemented feature which does not do any harm to anyone, it doesn't break anything, which can be useful from time to time and without which the editor may be confusing and which is present in some other editors because you feel that it doesn't exist in POV of real end users (which, on other occasions, we want to educate about many things).

I don't know what else I can do. I can't stop you from changing this, but you certainly didn't convince me.

[fredck]

Take it easy! Let's go your way, ofc. It's certainly fine.

[Reinmar]

I have a delayed (after walking the dog break) "one last thing" :D.

If we were about to disallow converting list items into headings, to be consistent, we should also disallow converting headings into list items. This would mean disabling the list buttons if the selection is in a heading.

Take it easy! Let's go your way, ofc. It's certainly fine.

I'm glad we can close this "bit" because it means less work for us now. But, I realised that we'll have to talk about those more advanced "document lists" soon. I totally agree about one thing – many users will expect to be able to create line breaks, headings, quotes, etc in the lists. Even Markdown allows that. My big hope here is that we'll be able to reuse there the rendering mechanism which we developed for the current list implementation and just work on a UX stuff. That would be amazing.

[wwalc]

Wow, you had a long discussion here :D

TL;DR & probably too late, but I just wanted to chime in regarding a small detail:

But to tell you the truth, I would not expect it to remove the list item and change it to a heading. I would instead expect that the contents of the list item would be transformed into a heading, remaining the list item. I think we have confusion here anyway.

My $0.02

I hate headers in list items, never used such construction and consider them to be both: semantically wrong and simply bad because it's impossible to style them, as we know it already (the bullet does not inherit heading style):

(the default behavior of CKEditor 4 is shown above, imho it's wrong even for the document editor).

Real life example

Some real life scenario as I write more text recently than code.

It happens to me relatively often when writing longer documents on G Docs, that I start creating long list, add more and more list items and then I'm later restructuring the document into something simpler, requiring at the same time to add some headers in between.

The funny fact is that I never convert a list item into a header, just because the flow is more or less like below:

Version 1 ("before")

First I have a long list:

Things to buy

• ham
• hammer
• bread
• butter
• spikes

Version 2 ("after")

Then I decide to make it more structured:

Things to buy @ Grocery shop

• ham
• bread
• butter

Things to buy @ Castorama

• hammer
• spikes

Of course the way I do this is that (i) first I make two lists out of it manually, pressing two enters or remove indentation button (ii) and in the end I add headers. I think I never tried to convert list item into a header.

One may say that it's just one example out of 7 billion people. But if you deduct people without computers and internet, it becomes more representative :P

Jokes aside, look here:

Stackoverflow (aka the expected behavior by the majority of devs)

I just did a quick googling and it redirected me here:
http://stackoverflow.com/questions/8935262/how-to-semantically-add-heading-to-a-list
I completely agree with concerns mentioned there as well as with the most upvoted result.

So, to keep things short, regardless whether header feature inside lists will be disabled or not, headers should never be allowed inside list items. And imho this would be a very good conclusion, because it would mean that leaving headers enabled and making its default behavior to extract the list item from the list would be a semantically correct result, expected by vast majority on SO.

MS Word - <li><h3>Foo</h3></li> vs <h3>Foo</h3>

Last case. With some reluctance I checked MS Word and it worked just as I expected it to work (!)

A list

A list after selecting 2nd item and choosing Heading 1

See that the list button is not highlighted.

For me it means that both the "Article editor" and "Document editor" can simply follow the same path.

Anti-example

http://materializecss.com/collections.html - this is so wrong that I guess there is no need to comment it.