I think "Chapter" is the only way to make in unambiguous. "Outline" is already used for a set of predefined list styles and that has resulted in the confusion. And "section", the other possible term, is used for the special feature available via Insert > Section, and those "sections" are unrelated.

If a literal translation of "Chapter" is not meaningful for a language, then this can be solved in the localization.

I do not see problem S1. If I search in the help for "outline numbering" the link goes to the correct help page "chapter numbering". That help page might need a hint, why the title is not "Outline numbering".

But you are right, other places in the UI and help use "outline" in the sense of structure of a document via headings on several levels.

I do not see problem S2. It is called "chapter numbering", which implicates for me, that there exist already a "chapter".

(In reply to Regina Henschel from comment #1)
> I think "Chapter" is the only way to make in unambiguous.

Chapter is unambiguous - but in the wrong way: It's unambiguously not what the user is looking for, so will unambiguously be skipped.

It is also unambiguously false - as the dialog does not allow for any definition involving Chapters.

> "Outline" is
> already used for a set of predefined list styles and that has resulted in
> the confusion.

I'm not following. What predefined list styles? I don't see list styles named "outline". The predefined list styles are named "Bullet (whatever)" and "Numbering (whatever)".

> If a literal translation of "Chapter" is not meaningful for a language, then
> this can be solved in the localization.

You're flipping the majority case. It is not the common or typical case for "Chapter Numbering" to mean numbering of things which aren't chapters, in a document without chapters. My French, Dutch and German are all too poor to comment on that use in these languages, but it's certainly the exception rather than the rule.

So, what I'm suggesting is that customary use in Dutch, German and French be maintained through the localization, but that the name (in the code, and in the English UI) be returned to "Outline Numbering".

> I do not see problem S1. If I search in the help for "outline numbering" the
> link goes to the correct help page "chapter numbering". That help page might
> need a hint, why the title is not "Outline numbering".

If users need to consult the Help so as to be able to decipher the incorrect naming of the menu item - that's your problem right there.

> I do not see problem S2. It is called "chapter numbering", which implicates
> for me, that there exist already a "chapter".

That _is_ the problem - because there are no chapters, nor can we create chapters.

Naming was changed deliberately and I disagree to move back. But ticket is open for input.

All those saying "-1" - Heiko, Roman, Dave, Dieter - what's the basis for your objection? Is there something factually incorrect in R1 through R3? Do you believe the current state of affairs is not confusing?

If not, then I fail to see the justification for the rename.


Also, to clarify - the question here is not about what should be done in localizations, where each language community calls things whatever works in their language, but rather - the unlocalized text, in English and in the source code, on the basis of which localizations are made.

Current situation might not be a perfect solution, but I don't see a better one. For me Regina pointed out the main arguments against a change. I read a couple of bug reports that came from confusion about outline numbering.

And I don't see, that a user with - let me say - three different headings in a small document with 3 pages says "I don't have real chapters (parts of a book) in my document, so I can't use this feature to number the parts of a document."

(In reply to Dieter from comment #8)
> Current situation might not be a perfect solution, but I don't see a better
> one.

It has already been established that using the name "Chapter" is not an improvement over the previous name, except perhaps in a few locales.

The better solution is reverting the name to "Outline Numbering".

> For me Regina pointed out the main arguments against a change.

I have explained why Regina's comment is - with respect - quite invalid: Using "Chapters" makes things unambiguous in English, but unambiguously wrong, which is worse than the previous state of affairs.

> I read a
> couple of bug reports that came from confusion about outline numbering.

1. With which locales? If they were about French/German/Dutch, then that's a localization issue.
2. Outline numbering has other causes for being somewhat confusing. See issue 141453.

If there are relevant bug reports, can you please put them online somewhere (pastebin?) and link to them?

> And I don't see, that a user with - let me say - three different headings in
> a small document with 3 pages says "I don't have real chapters (parts of a
> book) in my document, so I can't use this feature to number the parts of a
> document."

You are assuming the user's attention is already on this feature. It will not be because of the combination of it being in the Tools menu and it being about Chapter. You are assuming three things about the user:

1. Believes that the numbering features are to be found outside of Format | Paragraph (or even the format menu) and outside the Numbering Styles sidebar.
2. Believes they should look for a relevant feature in the Tools menu.
3. Knows that Chapter numbering will apply to sub-chapter-level elements, or in a chapterless documents.

This is unlikely. If the name is reverted, we will have removed one of the three required realizations/pieces of information a user must possess.

(In reply to Eyal Rozenberg from comment #7)
> All those saying "-1" - Heiko, Roman, Dave, Dieter - what's the basis for
> your objection? Is there something factually incorrect in R1 through R3? Do
> you believe the current state of affairs is not confusing?

This is bug tracking system, NOT a debating society. I find it offensive that our Bugzilla is offten abused by people who keep a "so called" bug open with pedantic arguments, in an attempt to get "their way", by a "war of attrition".

This is a decision the project has already taken, so can we please not waste any more time and effort on the NON-BUG. Close it as NOT A BUG, WON'T FIX and move on to assessing REAL bugs.

(In reply to Dave Barton from comment #10)
> This is bug tracking system, NOT a debating society. 

And yet, you chose to to make a Social-Media-like "Dislike" gesture ("-1 from me").

> I find it offensive
> that our Bugzilla is offten abused by people who keep a "so called" bug open
> with pedantic arguments, in an attempt to get "their way", by a "war of
> attrition".

Attrition is part of how the name change was made despite objections and reservations. ("I give in..." - bug 107573 comment 19).

> 
> This is a decision the project has already taken

It seems as though you're saying that the merit of a measure is unimportant if it has officially been adopted; and a measure can never be taken by mistake.

This bug was opened after carefully reading bug 107573, to understand the motivation for the suggestion to rename; and while you may certainly disagree with the arguments I made, I resent your implication that they are frivolous, or redundant.

Please do not close this bug report while the issues it raises have not been addressed. Also, speak for yourself.

Eyal, I think Design-Team should decide finally in one of the next meetings. Since everybody can join it's meetings, everybody should accept the decision then. Heiko, if you disagree, please add a comment.

(In reply to Roman Kuznetsov from comment #16)
> Eyal, you can see we all disagree with you, so please let's will not start a
> status changing war here

The reason I have insistied on the status is that the closing did not follow from actually addressing the issues raised - and it was a closure as NOTABUG.

I will not have a status-change-war over a WONTFIX - as it is your prerogative rather than question of fact.

And just to be clear - I am appreciative of your time spent on reviewing and commenting on bugs, even when I disagree vigorously.

(In reply to Eyal Rozenberg from comment #9)
> 1. Believes that the numbering features are to be found outside of Format |
> Paragraph (or even the format menu) and outside the Numbering Styles sidebar.
> 2. Believes they should look for a relevant feature in the Tools menu.
> 3. Knows that Chapter numbering will apply to sub-chapter-level elements, or
> in a chapterless documents.

All true but not directly related to the terminology of Outline vs. Chapter. We concluded somewhere else that chapter numbering should be available on the actual numbering tab in the paragraph properties dialog.
Whether Outline or Chapter, none seems to be perfectly clear without reading a documentation or doing the usual trial and error. Once you know the workflow labels are kinda inferior.
Most of us are not native speakers. The implicit translation could result in misinterpretation. I would trust in the recommendation of native speakers, which is Dave here. No offense to anyone, many of you are linguistic geniuses. A good idea, if it comes to localization questions, is to involve the l10n team. Ideally via mailing list.


We all pull together. Controversial opinions are necessary to ponder different views, and somehow we have to make a choice. I'm also not happy with every democratic decision taken in the past. But have to ask myself: is it really worth to fight?

I don't have an opinion in favor of Outline or Chapter, nor I followed in detail, but I was against the change for the sake of continuity. 
Already in the beginning it was clear that this is not clear improvement. Even if some small, nor enough to do it in my opinion. 
Some would be satisfied, some not. Not worth a change and 2 reports.

(In reply to Dieter from comment #15)
> Eyal, I think Design-Team should decide finally in one of the next meetings.
> Since everybody can join it's meetings, everybody should accept the decision
> then. Heiko, if you disagree, please add a comment.

I agree with Dieter.
Eyal, would it be possible for you to join the next UX Team meeting ?

(In reply to Regina Henschel from comment #1)
> I think "Chapter" is the only way to make in unambiguous.

Heh, if only it were true...

I strongly believe this proposal should be done, and tdf#104151 was badly misguided.

We have multiple confusion here.

Outline is the concept that should be used when the structure (including chapters and sections, and applied by the levels in paragraphs) is meant. It also must be used in Navigator instead of the "Headings".

Chapter is only used when first outline level is used (as in ToC's Create Index or Table of Contents For - note how the Chapter used there is *different* in the meaning from what tdf#104151 assigned it to).

Heading should be used very carefully - to refer to paragraphs having outline level applied; and also to refer to Heading N paragraph style - but these two uses must be disambiguated in writing.

We have currently just a mess, with more proposals coming to make it worse - see the use of "heading" term in comments in tdf#148673, caused by complete lack of distinction between these related, but different concepts.

See also tdf#138748, also dealing with a similar problem - the misuse of related but different terms, leading to real user confusion (e.g., tdf#137175).

(In reply to Mike Kaganski from comment #21)
> I strongly believe this proposal should be done, and tdf#104151 was badly
> misguided.

Sorry, tdf#107573 was meant.

(In reply to Mike Kaganski from comment #21)
> I strongly believe this proposal should be done, and tdf#104151 was badly
> misguided.

So, it seems I'm in rare agreement withe Mike on something :-)

> We have multiple confusion here. ... We have currently just a mess.

Yes, and even when a user figures things out, it's not that they create coherent notions in their mind; they're still in a situation of "I have to memorize semi-equivalences on not-intuitively-equivalent concepts, and what-term-applies-where-and-how".

> Outline is the concept that should be used when the structure (including
> chapters and sections, and applied by the levels in paragraphs) is meant. It
> also must be used in Navigator instead of the "Headings".

Well, either instead of, or separately from, but yes.

> Chapter is only used when first outline level is used (as in ToC's Create
> Index or Table of Contents For - note how the Chapter used there is
> *different* in the meaning from what tdf#104151 assigned it to).

and there isn't a good enough indication that Heading 1 is supposed to be equivalent to Chapter; nor, in fact, is that a good idea. Most documents people write don't have Chapters anyway.

> Heading should be used very carefully - to refer to paragraphs having
> outline level applied;

Here we disagree. "Heading" means "paragraph with Heading/Heading N" styles. That's how the lay user understands it. Paragraph with outline level can be called something involving the word outline: "Outlines", "Outlined", "Outlined paragraphs" or whatever.

> and also to refer to Heading N paragraph style - but
> these two uses must be disambiguated in writing.

So, my disagreement above is how I suggest disambiguate.

(In reply to Eyal Rozenberg from comment #23)

Please note that you try to force some *dictionary* meaning of terms into Writer. This is wrong.

Outline, chapter, and heading are OK to (and *must*) have *special* and specific meaning in Writer. When you write "Most documents people write don't have Chapters anyway" (and the like), you are completely away from the problem of correct use of specific Writer term, confusing different entities (and making a potential fix much harder).

So:
* Heading is a paragraph having an outline level other than "Text Body".
* Chapter is a part of text starting from a heading with outline level 1, and up to the next heading with outline level 1.
* Outline is a concept of paragraphs having the associated levels, creating corresponding structure.

Having some styles with word "heading" in them is just fine, and simply must be accompanied with word "style" ("paragraph style") each time, like in "Heading 1 paragraph style".

Trying to make it more complex, by mixing with so insanely complex matter as human language is (aggravated by translations, which multiply the associated meanings) is a mistake.

(In reply to Mike Kaganski from comment #24)
> * Outline is a concept of paragraphs having the associated levels, creating
> corresponding structure.

My poor English made that point rather bad. Rather:

* Outline is a concept of hierarchical document structure, created using respective levels assigned to (some) document paragraphs.

I must stress that my wording itself may be flawed *because of my poor language*. Anyway, the corrected meaning must reflect the Writer's concepts, and only be loosely related to the human language words of the same spelling (just to create some association in user, as in "it is similar to", nothing more).

(In reply to Mike Kaganski from comment #24)
> Please note that you try to force some *dictionary* meaning of terms into
> Writer. This is wrong.

It's not wrong. That is, users read text in an application's UI and interpret it according to the common meaning of the terms (the "dictionary" meaning). This will necessarily happen and cannot be defined as "wrong". while users can be educated about certain terms having a different meaning within an app, it's usually a good idea to minimize the extent to which that happens.


> Outline, chapter, and heading are OK to (and *must*) have *special* and
> specific meaning in Writer.

Technically, they _can_ have a very special and specific meaning in Writer, but why _must_ they have one? Or rather, why _must_ it be very different than the dictionary meaning?

> When you write "Most documents people write
> don't have Chapters anyway" (and the like), you are completely away from the
> problem of correct use of specific Writer term, confusing different entities
> (and making a potential fix much harder).

You are focusing on myself personally, but it is the _users_ who are "completely away" from the use of Writer terms you expect. A user writing a document with sections, whose heading paragraphs use styles Heading 1, Heading 2 etc., would assume a "Chapter Numbering" menu item is irrelevant to their document.

And yes, this fact makes it somewhat harder to fix things: We/you will need to better reconcile the meaning ascribed to terms in regular (English) language use with the desire to use LO-Writer-specific definitions.

> So:
> * Heading is a paragraph having an outline level other than "Text Body".

No it isn't. We can set the outline level of an arbitrary style, with no intention of considering it to head anything in the text (Example: Perhaps I want certain blockquotes of particular importance to appear in the outline view of my document). If instead of "Outline level" you called that property "Heading level", then you could make your argument. But we/you have chosen to say "Outline", so... no, a paragraph having an outline level other than "Text Body" is not necessarily a Heading.

> * Chapter is a part of text starting from a heading with outline level 1,
> and up to the next heading with outline level 1.

Here my objection is somewhat weaker. That is, it's counter-intuitive to define chapters like this, but it's not incoherent and doesn't cause inconsistencies. You're just using the term in a way which would surprise the user - who may not think of what they wrote as containing chapters. If stereotypical user "Benjamin" is writing a short paper for school, Heading 1 paragraphs are the heading paragraphs of the top-level sections of the paper, not the headings of chapters.

It's also worth mentioning that if you choose that definition, then it's not clear where we should even use this term; after all, you too agree Chapter Numbering should revert back to using another name.

> * Outline is a concept of paragraphs having the associated levels, creating
> corresponding structure.

Indeed. But that contradicts - as a typical user would see it - your claimed definition of a Heading paragraph.

> Trying to make it more complex, by mixing with so insanely complex matter as
> human language is (aggravated by translations, which multiply the associated
> meanings) is a mistake.

Unfortunately, LO is used by humans, and the UI is full of text in Human language, so I don't quite see how you expect to "unmix" that.

Anyway, what's wrong with the following definitions (for English of course)?:

* "Outline paragraph" is a paragraph having an outline level other than "Text Body".
* "Heading" is a paragraph with style "Heading", "Heading 1", "Heading 2" etc. Perhaps some additional specific styles (e.g. "Title").
* "Chapter" will be unused/undefined by LO Writer, as we don't seem to have facilities specific to chapters in books as opposed to Heading/Outline paragraphs.
* "Outline" is a concept of paragraphs having the associated levels, creating corresponding structure.

and the menu item can either be "Outline Numbering" (my preference) or "Heading Numbering" (which won't be an exact name but some might argue would better attract users needing it) or "Outline/Heading Numbering".

(In reply to Eyal Rozenberg from comment #26)

OMG. Are you trying to make just anything that *you personally* touch in the bug tracker to become completely unmanageable?

> (In reply to Mike Kaganski from comment #24)
> > Please note that you try to force some *dictionary* meaning of terms into
> > Writer. This is wrong.
> 
> It's not wrong. That is, users read text in an application's UI and
> interpret it according to the common meaning of the terms (the "dictionary"
> meaning). This will necessarily happen and cannot be defined as "wrong".
> while users can be educated about certain terms having a different meaning
> within an app, it's usually a good idea to minimize the extent to which that
> happens.

Any term used in an application needs to meet *several* criteria. Among them:
- Being consistent *inside the application*;
- Being *familiar* to users who intend to use it *in the most common case*;
- Following the common terminology in the industry...

and many more (being short, translatable, you name it). However, the criteria have their *relative* weight.

Users having problems with any term because of inconsistent use inside the program is a real bug. You claiming that users have problems with a term because it doesn't fit the dictionary meaning is just words, until we made the original term *self-consistent*, and *only after that* any *following* user confusion could be treated as the term being poor itself.

So each time you mention a term used inconsistently inside a program, and try to push your vision of dictionary-based approach, you just do it wrong personally. The only proper order is as I described: make its use self-consistent inside the program, then wait for user reports to see if further actions are needed.

> > Outline, chapter, and heading are OK to (and *must*) have *special* and
> > specific meaning in Writer.
> 
> Technically, they _can_ have a very special and specific meaning in Writer,
> but why _must_ they have one? Or rather, why _must_ it be very different
> than the dictionary meaning?

No they are *not* very different. We need to use the words from common language to create *associations* for the *most common* tasks associated with the term. We need *not* pursuit complete match with dictionary article. Users use the functionality *most often* when they crate headings for chapters (the words used *here* in a dictionary meaning), and even when they don't have strictly *chapters* in their documents, but, say, name them "sections", the "chapter" word is likely to occur to them when looking for the functionality. Use of *any* feature outside of the *originally intended* use case is common, but does not require any rename until that use becomes frequent enough, uniform enough, and in that process, the evolution would come through creation of some tutorials/how tos, FAQS, etc., until it formed the clear vision how that new use case fits into the terminology. You just claim some uses that don't yet deserve the said attention. Users who need that use case are likely already familiar with the original, most prominent use, and won't have problems with that terminology *if* it's self-consistent (again: self-consistent in the sense that it is used consistently to mean something specific in this program, not in any broader sense).

> > When you write "Most documents people write
> > don't have Chapters anyway" (and the like), you are completely away from the
> > problem of correct use of specific Writer term, confusing different entities
> > (and making a potential fix much harder).
> 
> You are focusing on myself personally, but it is the _users_ who are
> "completely away" from the use of Writer terms you expect. A user writing a
> document with sections, whose heading paragraphs use styles Heading 1,
> Heading 2 etc., would assume a "Chapter Numbering" menu item is irrelevant
> to their document.

I can imagine that there might be a couple of users who would not recognize Chapter Numbering as related to their task at first (but they could easily find it using help: typing "heading" there immediately gives "headings -- numbering/paragraph styles", which leads to "Chapter Numbering"); however, I fail to see how could you imagine *any* term to not have that property - anyone not familiar to it would be possibly confused; and using the term familiar to most is likely to ring a bell in most. (However, I still think that Chapter Numbering is worse than Outline Numbering, because that was a term having its established meaning in the industry - but this is unrelated to your argument above.)

> And yes, this fact makes it somewhat harder to fix things: We/you will need
> to better reconcile the meaning ascribed to terms in regular (English)
> language use with the desire to use LO-Writer-specific definitions.

No, not that fact, but your personal preference to do it in the wrong order (see above).

> > So:
> > * Heading is a paragraph having an outline level other than "Text Body".
> 
> No it isn't. We can set the outline level of an arbitrary style, with no
> intention of considering it to head anything in the text (Example: Perhaps I
> want certain blockquotes of particular importance to appear in the outline
> view of my document). If instead of "Outline level" you called that property
> "Heading level", then you could make your argument. But we/you have chosen
> to say "Outline", so... no, a paragraph having an outline level other than
> "Text Body" is not necessarily a Heading.

Yes it is. As I said: your personal use of the feature is fine, but until it's much rarer than the other use, it's OK to call that feature in the program after its most prominent use.

> > * Chapter is a part of text starting from a heading with outline level 1,
> > and up to the next heading with outline level 1.
> 
> Here my objection is somewhat weaker. That is, it's counter-intuitive to
> define chapters like this

Each time you mention intuition, you sound very strange, because each time then, you claim something that is mostly counter-intuitive itself to *most* users except most geeky ones. So please note that no, it's very *intuitive* to call chapters that way - just because intuition of *most* users would match it. The intuition is just a matter of prior experience, not something inherent - and hence, you need to weigh how much your own intuition is representative for the most common case.

> > * Outline is a concept of paragraphs having the associated levels, creating
> > corresponding structure.
> 
> Indeed. But that contradicts - as a typical user would see it - your claimed
> definition of a Heading paragraph.

No, it won't.

> > Trying to make it more complex, by mixing with so insanely complex matter as
> > human language is (aggravated by translations, which multiply the associated
> > meanings) is a mistake.
> 
> Unfortunately, LO is used by humans, and the UI is full of text in Human
> language, so I don't quite see how you expect to "unmix" that.

As I mentioned above: in steps, using terms that are associated with the most prominent use case, and making sure that we don't break the intuition of users having their experience in the *industry* (that has some established mappings).

> Anyway, what's wrong with the following definitions (for English of course)?:
> 
> * "Outline paragraph" is a paragraph having an outline level other than
> "Text Body".

No problem in itself - but inexperienced users (i.e., the majority) will least likely recognize that as something matching their goal.

> * "Heading" is a paragraph with style "Heading", "Heading 1", "Heading 2"
> etc. Perhaps some additional specific styles (e.g. "Title").

ABSOLUTELY wrong, and MUST NEVER be used that way. Any paragraph style is not special in any way. You seem to fail to recognize that fundamental concept. The name of the style is intended to hint how it's expected to be used, but it isn't a special style. It is no more special as e.g. "Заголовок по ГОСТ 21.1101:2008" that an organization might decide to use for headings, and mandate in its internal regulations.

> * "Chapter" will be unused/undefined by LO Writer, as we don't seem to have
> facilities specific to chapters in books as opposed to Heading/Outline
> paragraphs.

We have - as I shown in the ToC dialog.

> * "Outline" is a concept of paragraphs having the associated levels,
> creating corresponding structure.

Or you could see it this way:

There is *only one* content structure defined in Writer, and that structure is defined using outline levels (let me ignore a small structure created by lists, which is unrelated to the discussion, and would just confuse the following). Paragraph styles do *not*, *never* define any structure. They can only *help* in such structuring - in the same way that they may *help* in semantical structuring, and in formatting - but no style itself is equal to "bold" formatting, even if you name the style "bold".

There are several solutions:

1. Make all terminology follow the Outline concept (and then, drop *everything* related to the use cases - so drop all "headings", "chapters", "tables of contents", and only keep technically clear terms, like "outline paragraphs", "parts of text governed by an outline paragraph", "index of outline", etc.)

2. Introduce additional - orthogonal - content structure. That, again, must *not* use paragraph styles, but some similar *property* (which, indeed, could be set in a paragraph style, as a convenience method - but doesn't make the style *internally* special). Then - why limit to two structures? Let us define arbitrary number of orthogonal structures. Then user could name each structure as they wish. And shoot into their feet (or, rather, make others' life harder, because even the second orthogonal structure would introduce huge confusion).

3. Just improve the existing structure in steps, using the established and familiar terms, in the ways that make it not too hard for users to grasp it, but not trying to create something absolutely perfect (trying to do which would simply stop any progress).

(In reply to Mike Kaganski from comment #27)
> OMG. Are you trying to make just anything that *you personally* touch in the
> bug tracker to become completely unmanageable?

Thank you for that lovely ad-hominem attack, I'm sure it greatly strengthens your argument.

> Users having problems with any term because of inconsistent use inside the
> program is a real bug. You claiming that users have problems with a term
> because it doesn't fit the dictionary meaning is just words, until we made
> the original term *self-consistent*, and *only after that* any *following*
> user confusion could be treated as the term being poor itself.

That might sound reasonable on first reading, but it's actually the wrong way to go about it. Suppose that in 75% of the places we refer to paragraphs in LO we would call them "puppies". It is _not_ right to aim for consistently referring to paragraphs as "puppies", and to habituate users to that term, only to later consider whether or not change it into "paragraphs".

What we should do is *simultaneously* become consistent with "dictionary meaning" _and_ self-consistent.

> The only proper order is as I described ... 

(sigh...)

> So each time you mention a term used inconsistently inside a program, and
> try to push your vision of dictionary-based approach, you just do it wrong personally.

It is as if you were to say: "each time you try to push your vision of a dictionary-based approach in which paragraphs are not puppies, you're just wrong personally"


> I can imagine that there might be a couple of users who would not recognize
> Chapter Numbering as related to their task at first

You imagine wrong. Chapter Numbering is about Chapters. If you're writing a document without chapters you are quite likely to assume it is irrelevant to you. I would even guess people are more likely than not to fail to recognize it as relevant, although that's more debatable.

> No, not that fact, but your personal preference to do it in the wrong order
> (see above).

You can keep saying "personal" as many times as you like, but dictionary meaning is not a "personal preference", it is the preference of essentially everyone. Diverging from it always needs special justification.

(In reply to Mike Kaganski from comment #21) (marked as "wisdom")
> Outline is the concept that should be used when the structure (including
> chapters and sections, and applied by the levels in paragraphs) is meant. It
> also must be used in Navigator instead of the "Headings".
@Mike: “Headings” is a valid (accurate) label (if Headings = "Paragraph with Outline level"), but why haven't you proposed this change to "Outline"?

Also, if the Navigator label was changed as proposed here, then should "Headings" be changed to "Outline" in the cross-reference dialog (Ctrl+F2) as well?
(seems appropriate to have the same label in both cases).