[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Heiko Tietze --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 --- Comment #7 from R. Bingham --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 --- Comment #6 from Eyal Rozenberg --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054
--- Comment #5 from R. Bingham ---
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 "
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/0513.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
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 Heiko Tietze changed: What|Removed |Added Blocks|107833 |103427 --- Comment #4 from Heiko Tietze --- Some of the paragraph styles (PS) are used by internal functions such as "Content " 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). Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103427 [Bug 103427] [META] Styles and Formatting sidebar deck and floating window https://bugs.documentfoundation.org/show_bug.cgi?id=107833 [Bug 107833] [META] Writer paragraph style bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 --- Comment #3 from R. Bingham --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054 V Stuart Foote changed: What|Removed |Added Summary|UI: Remediate frustration |UI: Remediate frustration |of opaque style names in|of unclear style names in |style-name picklist |style-name picklist |contexts|contexts CC||vsfo...@libreoffice.org --- Comment #2 from V Stuart Foote --- slight edit to summary s/opaque/unclear -- on first read I'd assumed it was a dark-mode rendering issue ;-) -- You are receiving this mail because: You are on the CC list for the bug.
