https://bugs.documentfoundation.org/show_bug.cgi?id=155269
--- Comment #3 from R. Bingham <[email protected]> --- (In reply to Mike Kaganski from comment #2) Ah, ah! This is good. Reviewing bugs 129270, 129668, 129669 and 140846 I see continuing *conceptual* confusion even among the LO Dev Team. If this is "simple user confusion" then tell me why does it persist for this feature? Noting the MK comment https://bugs.documentfoundation.org/show_bug.cgi?id=140846#c4 (LOL, LOL) about good intentions, I suggest a part of the confusion persistence is that through incremental behavior and UI changes over the years in response to point bugs or enhancement requests regards levels, etc., those Dev Team responses, perhaps at best only lightly analyzed for conceptual and user experience consistency, have created a divergence between observed functional behavior (implementation) and observed *presentation* (the UI). Users are responding to that disagreement with confusion and will continue that confusion until that divergence is reconciled away. Let us see how this plays out in the present issue. This will be long because I am setting up user POV experience and mental-model concepts. Mental-model of Styles >From a statement somewhere in the user-facing documentation (UFD), LO Writer is a **style** oriented document creation app. Most if not all visible document objects have an associated style-object that governs the textual and graphical presentation of the object. That association is a link to a style-object global to the document. We wave away nuances and complications from visible-object-local, anonymous style-object clones created by per-visible-object manual interventions. In theory, a change to a global style-object affects all linked document-visible objects (practice a different matter). Global style-objects have an existence observedly independent of being applied to any visible document object. A user can access the global style-objects for understanding, for config maintenance or to create new via Navigator. Here we focus on style-object sub-types (as presented in user POV Navigator UI they are peer sub-types) Paragraph and List. From observation, functionally List seems an enhancement on, or perhaps a wrapper of, Paragraph. [Paragraph Style] (PS) feature >From observation, the PS tabbed-widget UI presents as the fullest-featured way to initially define/configure/update the properties of a PS-object. One of the PS style-object properties prominently managed via the UI is a sub-object identified as tab[Outline&List]->Outline->[Outline level:]. The value-assignment picklist for this sub-object offers 11 values: an ordered list of integer values 1 -- 10 and a mysterious non-integer "Text Body." >From observation, [Outline level:] seems important to the update behavior of the Document field variable Chapter->name, and perhaps other Writer features. Indeed, fiddling the value of [Outline level:] in global PS Foo changes how Chapter->name updates when scan-encountering paragraphs of PS Foo. Note the "sequential scan" mental model of how the document text is processed. [List Style] (LS) feature >From observation, the LS tabbed-widget UI presents as the fullest-featured way to initially define/configure/update the properties of a List style-object. Two tabs of that UI (tabs [Position] and [Customize]) present something visually on the left labeled a "Level." This Level thingy appears to be an integer-valued (1 -- 10) index for identifying a *set* of properties that instruct the construction of a sub-string of the final List-feature text output string prepended to visible, List style-object-linked paragraphs in the document. So 10 possible property sets in all. From observation, this integer index orders a rank relationship for resetting an implied numerical counter associated with each property set, and ordering the sub-string output from property sets in ascending integer value for (presumably language dependent) left-to-right concatenation in to the final List-feature output text string. >From observation, the LS->Level integer-values domain and the PS->[Outline level:] integer-values domain are mutually independent. That is, fiddling the PS->[Outline level:] value of a para assigned a list-style in PS->tab[Outline&List]->[Apply List Style]->[List style:] or manually set to a LS context does not seem to change what the LS feature does in presentation of the para text. LS->[Level] does not seem to be an explicitly exposed or picklist settable property of a given List style-object in the model of PS->[Outline level:]. Rather, the LS UI display index seems to only serve as an internal, organizing index for the List style-object feature. OTOH, fiddling PS->tab[Outline&List]->[Apply List Style]->[List style:] picklist value *does* change the List-feature textual presentation. So now we have the PS->[Outline&List] strongly presented as a config manager one of two features that involve some concept of mutually independent sets of **levels**. We have at least one Writer feature (field variable Chapter->name) which cares ONLY about [Outline level:], meaning most importantly for this narrative, it does NOT care about the *name* of the Paragraph style applied to a give para. Now examine the [Tools->Chapter Numbering] (TCN) tabbed-widget UI. [Chapter Numbering feature] Right away the Numbering and Position tabs are strikingly similar to the LS->Customize and Position tabs, especially the former. Those two tabs present something visually on the left labeled a "Level." The TCN "Level" thingy appears to be an integer-valued (1 -- 10) index for identifying a *set* of properties that instruct the construction of a sub-string of the final TCN-feature text output string prepended to each instance of a scan-encountered paragraph having a PS with the same name as in the property picklist slot of [Numbering]->[Paragraph style:]. So 10 possible property sets in all. From observation, this TCN integer index orders a rank relationship for resetting an implied numerical counter associated with each property set, and ordering the sub-string output from property sets in ascending integer value for (presumably language dependent) left-to-right concatenation in to the final List-feature output text string. You might note how much of the above description is a copy/paste from LS feature. My challenge to the Dev Team: Explain how a user not yet stung could possibly mental model the TCN is anything *other* than an advanced version of the LS feature? Looks (UI) like a List duck, walks (generates sub-strings for a concatenated final text string output) List duck, quacks (prepends its final text string output) like a List duck. INCLUDING that bit about mutually independent sets of **levels** among the multiple List duck families and the Paragraph duck family. RTFM? Hmmm... cite the pages. Further, explain why you will not be bombarded with bug reports when stung users encounter that this TCN feature will silently slam the previously-understood-to-be-mutually-independent [Outline level:] value of any para style name brought new in to the feature as a [Paragraph style:], encounter that if an incumbent para style name is re-located between TCN "levels" that the [Outline level:] value of that para style will be silently slammed yet again, or encounter that if an incumbent para style name is evicted from the TCN feature config, that para style's [Outline level:] will be silently slammed to "Text Body." Nothing tells the user that in addition to PS->[Outline level:], TCN is *also* a manager of [Outline level:] value settings for paragraph styles. NO. THING. Having ranted that, I propose the following thought experiment: (1) Ignore how TCN is currently implemented backstage, ignore the current entanglement with [PS]->[Outline level:]. (2) Focus on how a user observes the feature to work today, the key functionality of (mental model) during an internal scan-processing of the document text of how the TCN feature decides when to trigger a sub-string integer-counter increment, trigger a higher numeric index counter reset, and then quack (prepend to a para) the feature's output text string and quack an update to one of those 10 string-value variables of that same output text string. That trigger function is based on para style NAME recognition of the style applied to a scanned para. For the user, "levels" are meaningless for para style name recognition--you have a bag of para style names collected from the 10 [Paragraph style:] property slots and one of them triggers. As with List, TCN integer "levels" serve to internally organize property sets. The only para style property that is input to this processing is the recognition trigger on [Paragraph style:] NAME. (3) Magic wand, I poof [Outline level:] to disappear from the GUI. Ignoring the deleterious effect on [Chapter->name] and perhaps other features, my challenge to the Dev Team is explain how TCN as described in (2) would not still work as the user expects. (4) If you cannot so describe, you have a path forward from the painted-in corner in which you are now trapped. I would then propose: TCN is to be re-positioned as an advanced version of List, and as with List, has its own independent integer (could be alphabetic!) index scheme of organizing property sets with an ordered index value for constructing its output text strings. No conceptual connection to that [Outline level:] property of para styles, thus freeing that property from TCN inteference. Part of the user-base re-training migration for this re-position is to leave the men Tools->[Chapter Number] path in place while also adding TCN to List Styles in Navigator as yet another List style-object AND re-work menu path Format->Bullets and Numbering to be: Format->Bullets and Numbering-> ->[List styles general: Bullets and Numbering] ->[List styles advanced: Chapter Numbering] See also my suggestion of starting thought on novice, general and advance modes of the UI in 155054 Comment 5 to mitigate the conflicts between the needs of general users and power-users. The feature of Chapter->name available in a variable or an array variable needs a mechanism. Could usefully be an option property in TCN to capture the text of the triggering para for update to the Chapter name array variable. However, I am reluctant to restrict Chapter name capture to just TCN as TCN by definition should not trigger on para styles of unnumbered chapters. Consider a book form with Indexes of contents, illustrations, tables, a Dedication, a Forward, an Introduction, a Prologue, numbered chapters, and an Epilogue, an Appendix or two or three, a Glossary, a Concordance, and Indexes of footnotes. Many, many unnumbered chapters. The [Outline level:] mechanism does usefully work for Chapter name as long as it is independent of TCN interference. However, Chapter name capture by para style name trigger as TCN does is an alternate or additional design to consider. For a reallllllllllllllllly advanced concept for configuring TCN and possibly Chapter name, look at the Assign Styles UI of the Index configurator. For TCN, that UI concept would enable multiple PS names to trigger a given sub-string index property set rather than the very limiting one para style name property slot in the current design. Instead of [Paragraph style:], the UI would have (as the Index confgurator does) a button opening a variation on the Index Assign Styles UI. Regards. -- You are receiving this mail because: You are the assignee for the bug.
