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.
