https://bugs.documentfoundation.org/show_bug.cgi?id=155054
Bug ID: 155054 Summary: UI: Remediate frustration of opaque style names in style-name picklist contexts Product: LibreOffice Version: 7.5.2.2 release Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: rdbing...@verizon.net 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. -- You are receiving this mail because: You are the assignee for the bug.