[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=155054

--- Comment #5 from R. Bingham <rdbingham at verizon.net> ---
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 on the CC list for the bug.