Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Jumbo This UI enhancement request originated with frustration in using thethe LO Writer Paragraph Style definition Organizer style picklist functions (Next style: & Inherit from:) when modifying an existing paragraph style in LO Writer, but the request applies to ANY feature of ANY LO app that offers a style name picklist, be it a style of paragraph, character, frame, list, page, table, ... First, the LO Navigator offers a nice hierarchial display of styles (for a given style category of character or paragraph or page or...) such that not only can the user readily discern the functional inheritance hierarchy but also implicitly the full 'pathname' context of the terminal name phrase of the style name. Opaque terminal phrase or single word style names have context for understanding from the visual display. In style picklists (such as used in style modification or creation tabbed forms, or TOC/index/list definition contexts), that hierarchial display context is not present. All the user gets is the terminal phrase or single word style name. Thus, unless the terminal phrase encodes sufficient context, the user is lost as to what a style choice is or where it might be found in Navigator. Example style-name terminal phrases: The Good: Footer Left <-- 'Footer' is the encoded clue this style is related to Headers/Footers, the next higher level of context for the otherwise very opaque 'Left.' Header Right <-- 'Header' is the encoded clue this style is related to Headers/Footers, the next higher level of context for the otherwise very opaque 'Right' Figure Index 1, Index 1, User Index 1, Object Index 1, Index Separator <-- I can tell these are related to index contexts! The Bad: Contents 1 <-- 'Contents' of what? In what context is this sytle designed to be used? In Navigator I hunt around and find this inherits from Index. Bibliography 1 <-- Something to do with bibliography, but in what context? Footnote? Endnote? Table of Biblio? In Navigator I hunt around and find this inherits from Index. The Ugly: Drawing Figure Illustration Table Are the above related to indexes for these objects? Something to do with how they anchor or interact with surrounding text? I hunt around in Navigator and find... they inherit from Caption. Who knew? The Gross: Text <-- WTF? (Well, I eventually found it under Caption, but how more OPAQUE can a style name get?) The point of this is that unless a user has visually MEMORIZED the style name tree and retains that memorization since months ago when the user last fiddled with styles, then The Bad, Ugly and Gross just frustrate the heck out of a user whenever confronted with a style name picklist. Enhancement possibilities: A) Selection from a visual heirarchy: A1) Heirarchy tree visual display expands out instead of a flat picklist. Hey, why its called a G.U.I. A2) Alternatively, since it already exists, be able to select from the Navigator tree display to populate an otherwise picklist choice slot in an style selection form context. The user should already know how to apply a style via cursor placement in the document then a mouse 2-click in the Navigator styles gallery, right? Why not use the same trained user action be to populate a style name entry in ANY LO GUI context where a textual style name is valid input? The point of a picklist is to not only present the choices but also to RESTRICT the choices. Navigator does the exact same thing but with greater visual and textual understanding context available to the user. B) Keep the picklist approach but encode additional context in the text of each picklist choice. Possibilities here are: B1) Re-name built-in style names to encode a next higher level of context. Examples: Contents 1 --> 'Index Contents 1' or perhaps 'Idx Contents 1' Bibliography 1 --> 'Index Bibliography 1' or perhaps 'Idx Bibliography 1' Alas, that might hork support of legacy doc files having the legacy style name built-ins. So, consider an alias mechanism where multiple style names map to the same style definition object, then provide context-encoded alias for the legacy built-ins. B2) In generating the text of a picklist entry, prepend a context clue from the next higher level(s) of the Navigator heirarchial tree, i.e., in a '|' (bar) separated format "higher_context_clue | terminal_phrase_name" Regards.
R. Bingham, thank you for the enhancement request. Topic A is related to the combobox, while topic B is more genral about a more significant name of paragraph styles. So perhaps it would be better to have two different bug reports, but first let's add design-team for further input and perhaps decision. cc: Design-Team
slight edit to summary s/opaque/unclear -- on first read I'd assumed it was a dark-mode rendering issue ;-)
FYI, this attachment/comment may show multiple times. I submitted it but it is now not showing in Bugzilla when I re-query this bug 155054. Thanks. I volunteer edit a wide range of documents, accumulating my own library of OTTs AND a library of 100s of styles (for all style types shown in Navigator) across multiple OTTs. I have become very sensitive to the clunky parts of the LO UI regards 'enterprise' style creation and curation for consistency across OTTs. I dream of an enterprise database of LO styles I can manage via a spreadsheet-like presentation for consistency and parameter-value patterns across all my OTTs. Sigh... In the meantime I must make do with the OTT by OTT, style-by-style tabbed-pane GUI. Navigator is my friend. Inheritance is my friend for managing commonality of parameter value sub-sets in tree children. The attached screenshot... well, no, Bugzilla Attachment submission not working at the moment, so laboriously re-create in text here Heading Appendix Hd VolSer 100 LOO LeftAlign Sans parent_only Hd VolSer 110 LOG LftA KeepNext Sans parent_only Hd VolSer 260 VS Vol L03 F/13_Mattr H FM_Title Hd VolSer 264 VS Vol LD4 F/13_Mattr L2 Hd VolSer 268 VS Vol LOS F/B_Mattr L3 Hd VolSer 320 VS Vol Wart L04 UB_I'vlattr LI Hd VolSer 330 VS Vol Wart L05 UB_Mattr L2 Hd VolSer 510 VS Vol Wart 1-StorySet L04 StorySetTitle Hd VolSer 520 VS Vol Wart 1-StorySet L05 F/B_Mattr L1 Hd VolSer 530 VS Vol Wart 1-StorySet LO6 F/B_Mattr L2 Hd VolSer 610 VS Vol Wart 1-StorySet Story LOS StoryTitle L1 Hd VolSer 620 VS Vol Vpart 1-StorySet Story LOS StoryTitle L2 Hd VolSer 710 Vol Wart 1-StorySet Story Chap LD6 ChapTitle L1 Hd VolSer 715 VS Vol Wart 1-StorySet Story Chap LO6 ChapTitle L1 AutoNbr Hd VolSer 720 VS Vol Vpart 1-StorySet Story Chap L06 ChapTitle L2 SubTitle Hd VolSer 730 VS Vol Vpart 1-StorySet Story Chap Anno L07 LO parent_only Hd VolSer 734 VS Vol Vpart 1-StorySet Story Chap Anna 1_07 L1 SubChapTitle Hd VolSer 740 VS Vol VPart 1-StorySet Story Chap Anno L08 L2 Topic Hd VolSer 740 Vol Wart 1-StorySet Story Chap Anno LOB L2 SH_Crono Hd VolSer 780 VS Vol Vpart 1-StorySet Story Chap Anna L10 L4 Char Hd VolSer 150 VS LO1 VolSerTitle Hd VolSer 210 VS Vol L02 VolTitle L1 Hd VolSer 220 VS Vol 1_02 VolTitle L2 SubTitle Hd VolSer 310 VS Vol Wart L03 VpartTitle Hd VolSer L09 LftA Hdr def placeholder Heading 1 ... shows a small part of one of my paragraph styles trees still evolving. Note how I use 'parent only' styles not intended for actual doc use to both encode key parameter value choices in the style name and as a holder of those values for the children. Note how I have had to develop a hints encoding scheme for the style terminal name for when it appears in a tabbed-pane flat picklist. The encoding scheme not only hints at parameter values but also leverages the style-name string sort that usefully happens in both picklist and Navigator presentations. Building up this sort/grouping gives each style-name item a surrounding context as an implicit additional hint of meaning. The encoding burden on the terminal sytle-name could be much less in the Navigator hierarchial view since the inheritance parents are there to also carry some of the encoding in their names as well. I note that Navigator does not offer inheritance for Pages, Lists, and Tables styles. Sadness, and my next UI enhancement requests. Regards.
Some of the paragraph styles (PS) are used by internal functions such as "Content <n>" for the Table of Contents (check the Styles tab), and some depend on the context, for example Caption > Text- you may want a different PS for frame captions vs. tables captions. The Stylist (this complex sidebar UI) has various filters to accommodate many different needs. The full list is not recommendable for novices; and while you like the tree it's not a simple UI. Some effort has been done to bring the best into the Automatic style (for example bug 69551). Please review bug 103427 for duplicates, there are many. I think your request is not actionable (we cannot submit a patch that resolves an issue) nor entirely justified. We can discuss some names, fiddle around with the organization but in the end it remains the same workflow. And the actual use case of "I struggle to pick the right PS for my task" requires to read the documentation. The second part of expanding a dropdown into a tree makes no sense to me. Trees are not recommended usability-wise (although expert user may love it), neither the styles dropdown nor the Notebookbar styles area list all PS but offer access to the Stylist. Lot of room for improvements here, see bug 90646, bug 93111, bug 143987, and bug 153581. Just to pick a few. My take here: WONTFIX (ticket has been tagged as needsUXEval so we seek for input from different people ideally and either agree and forward to developers or resolve WF/NAB; you can always reopen a ticket, I wont close it again).
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.
Lots of text in this request - enough to make it a bit inaccessible to readers to be honest. Anyway, IMHO, it would be beneficial to see the hierarchy when selecting a style for "Next Style" or "Inherit from"; but if this were made into too big of a spectacle, then the benefit would be outweighed by the detriment. So, I would only support a visually subtle solution if one were available.
(In reply to Eyal Rozenberg from comment #6) > Lots of text in this request - enough to make it a bit inaccessible to > readers to be honest. > > Anyway, IMHO, it would be beneficial to see the hierarchy when selecting a > style for "Next Style" or "Inherit from"; but if this were made into too big > of a spectacle, then the benefit would be outweighed by the detriment. So, I > would only support a visually subtle solution if one were available. Agreed, thus my suggestion B2 above: B2) In generating the text of a picklist entry, prepend a context clue from the next higher level(s) of the Navigator hierarchical tree, i.e., in a '|' (bar) separated format "higher_context_clue | terminal_phrase_name" Note that the bar-separator hierarchy presentation is already used in Tools->Customize->Target drop box to show the first two levels of menu hierarchy for context. This I am not proposing a new UI visual pattern, just re-use of an existing pattern in yet another drop box context. Regards.
We discussed the topic in the design meeting. It's recommended to use PS sparingly - and both the Stylist with filter Applied Styles as well the dropdown in the standard toolbar should show most if not all of the used styles. We also provide alternatives such as an Automatic filter that tries to smartly filter PS. As a more general note, trees are complex UI elements and discouraged for use (better combine a dropdown with a list). If we make the simple style picker in the toolbar an overly complex tree with all hierarchy it is rather detrimental to usability. For insights we added the Styles Inspector and recently the Spotlight feature. That might not reduce your frustration but is hopefully a tool for the average user to efficiently deal with PS. => WF, feel free to reopen