https://bugs.documentfoundation.org/show_bug.cgi?id=155054
--- Comment #5 from R. Bingham <[email protected]> --- Thank you for your feedback. First, to correct a mis-impression. My UI issue is NOT "I struggle to pick the right PS for my task." As a long-time LO user, I typically have a good idea of the style functionality I want ("the right PS for my task"). My UI issue is... + identifying the character-string style name that maps to that desired functionality. Alas, I have not memorized a mapping of all 125 (yes, I counted) built-in paragraph style character-string names to a mental model of functionality. Why not? My deep involvement with modifying or defining new styles is episodic, driven by need. And even then, that deep involvement is usually only one or two sub-areas across all style types (paragraph, character, frame, page, list, table). Many months, perhaps more than a year, may have passed since my last deep-dive to a particular area of styles. My daily use of style names is relatively shallow. That deep-dive information fades from memory. Then a need for a new deep-dive episode of styles maintenance creation and maintenance arrives and I am once again reminded of desirable enhancements to the LO UI. This is when style functionality hints + encoded in the character-string style name, or + implicit hints from surrounding style-pick visual context, such as the hierarchy display in Navigator, or, + while using the Paragraph Style tabbed-pane widget combo-box picklists such when selecting a "Next style:" or "Inherit from:" to modify or define New and the picklist presents pattern-encoded string names immediately adjacent in the flat-list sort are of high value in avoiding interruption of picklist work. So then, what are my sources of assistance in 'identifying the character-string style name that maps to that desired functionality' for when I have a Paragraph Style tabbed-pane widget up, the Organizer tab selected? The "Stylist (this complex sidebar UI)" component in Navigator has that helpful hierarchical view. Alas, it cannot assist because that styles-maintenance tabbed-pane widget is MODAL. Oops, workflow interrupted. I have to dismiss the widget to use Navigator then return to it. To avoid that modal widget dismissal and loss of mental context, with the modal tabbed-pane widget still in view, let us go to the very fine LO user-facing documentation brought up in my Web browser via key F1 (assuring the appropriate LO Module section of Help). Surely it will have one of + a graphic of a fully exploded paragraph styles tree of the built-in styles as a hint, or + perhaps a page showing the flat-list of built-in paragraph styles as it appears in widget picklists, with helpful notes on greater context for each flat-list entry item? My challenge to RTFM-inclined "requires to read the documentation" LO developers is this: cite UF documentation pages having either of those. A further challenge to RTFM-inclined LO developers is this: using my The Good, The Bad, The Ugly, The Gross examples of style names as a search term in LO Writer Help, or any built-in style name for that matter, cite UF documentation pages having a sentence or two that explains the intended use of the individual style, or if not an individual style, of a style family, such as the cited example of the special-built-in-functional-juice style family ' "Content <n>" for the Table of Contents'. BTW, it is Contents plural, not Content singular. One might think that the overview page "Styles in Writer", LibreOffice/help/en-US/text/swriter/01/05130000.html?DbPAR=WRITER#bm_id4005249 hosting the topic and table "Style Category" would be a good page to find further links to use-intention details on each style-name family, possibly the individual built-ins. NOPE. Lastly on the topic of help, some unsolicited professional advice from a customer-facing IT-sales systems engineer: naked, unsupported RTFM always leaves a classic blow-off impression with customers and sales prospects. Not good for future sales. I suggest instead cite specific documentation pages, topic or URLs. That way, still RTFM but at least you give the impression of helpfulness, of providing resources for the customer. Yes, this requires some research effort on your part using the same user-facing tools the customer can access. But the upside of that effort is, if in that effort you discover you cannot develop those citations, then maybe, maybe, the customer has a point after all... "The second part of expanding a dropdown into a tree makes no sense to me." Agree, but that was only one of several possibilities I listed and in any case I wanted to spark some thought on why the existing flat picklist design has its own UI usability problems when the list gets long and the entry items are opaque, or, err, unclear, or better, cryptic. My whole 'encoding sufficient information in a style name if that is all you have' concept. The Workaround: While the UI of a document having a MODAL paragraph style widget is frozen, open (or create New) a different ODT and its Navigator is still functional. Surely then I can search by style name or subset thereof in Navigator. Nope, no search on style name (wink, wink, enhancement suggestion!). OK, set the paragraph styles filter to All Styles and scroll through the alpha sort list. Taking the example from 'The Gross' of 'Text', find that entry, right-click Modify and see that 'Text' inherits from 'Caption'. Ahhhhhhh... that is the 'Text' style functionality. Hopefully I will remember that for a while. But then look at what I had to go through. Means I have to keep a spare ODT instance open on my desktop just to access a working Navigator to figure out a style-name context while doing style maintenance in a different ODT. A direct consequence of the MODAL UI design pattern. Thank you for the pointers to 69551, 103427,90646, 93111, 143987, 153581. Need some study. A quick scan shows a recurring theme is the conflict between power-user and general user. You might guess I am a episodic power-user. Hmmm... other apps address this with the concept of a Preferences setting for novice, general and power-user modes for the UI. Hint, hint, maybe time to start thinking about that in small ways to make that recurring theme go away. My excursion in to the subject of deficient documentation was not accidental. Additional documentation would mitigate much of the complaint in this ER, thus avoiding program code changes. I have encountered many instances in the LO UI where there seems to be no documentation of the words/phrases that appear in the GUI. Sigh... time to go visit the Contributor's side of the Doc Team website. Regards. -- You are receiving this mail because: You are the assignee for the bug.
