Bug 130495 - Introduce a filter in Tools > Options > LibreOffice > Application Colors
Summary: Introduce a filter in Tools > Options > LibreOffice > Application Colors
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Options-Dialog Options-Dialog-Colours
  Show dependency treegraph
 
Reported: 2020-02-06 21:42 UTC by sdc.blanco
Modified: 2021-05-04 08:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
mockup of radio button approach to Application Colors (88.60 KB, application/vnd.oasis.opendocument.graphics)
2020-02-06 21:42 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2020-02-06 21:42:25 UTC
Created attachment 157713 [details]
mockup of radio button approach to Application Colors

Tools - LibreOffice - Application Colors

Problem:  
  Useful and interesting settings, but
    - difficult to get an overview, especially if unfamiliar with possibilities  
    - overwhelming in first encounter
    - long scroll window, 
    - different kinds of controls, relevant to different users/purposes

Proposal:  Introduce radio buttons for each "type" and only show the relevant controls for each type.  (same kind of idea as Area tab in Paragraph Style).

Here are the "types"
 General
 Text Document
 HTML
 Spreadsheet
 Drawing / Presentation
 Basic Syntax Highlighting
 SQL Syntax Highlighting
 Report Builder

Mockup attached  (2 Draw pages), showing the idea with "General" and "Spreadsheet"    No opinions about the "fine details" (e.g., some of the radio buttons might only have 1 or 4 controls, some label names are long, moving some to module specific locations). Others will be wiser about such issues.

No new commands.  No changes in existing functionality.  

Just UI change to make it easier to see/find relevant controls
Comment 1 Roman Kuznetsov 2020-02-07 05:48:53 UTC
UX-team, we need your opinion.
Comment 2 Roman Kuznetsov 2020-02-07 05:53:52 UTC
and +1 from me
Comment 3 V Stuart Foote 2020-02-07 14:35:05 UTC
So is the action of the buttons just going to advance the scroll of the listbox of 'User interface elements' and assigned color swatches?

Or would it filter the elements, result in just showing the element and color of the selected group?

And while the scrollable listbox is efficient for localization--it has always been clunky. Should we go ahead and filter, is there a better GUI to present the interface elements?
Comment 4 Heiko Tietze 2020-02-18 08:22:30 UTC
I understand the idea as buttons show the current position in the list and allow to quickly jump to it.

However, this configuration is not meant for basic users and I would expect experts to deal with long lists. And I wouldn't say the application colors are "useful and interesting setting". 

So my take is -1.
Comment 5 sdc.blanco 2020-02-20 23:04:23 UTC
(In reply to Heiko Tietze from comment #4)
> I understand the idea as buttons show the current position in the list and
> allow to quickly jump to it.
Nope. More like the "Area" tab (in, for example, Paragraph Style dialog), where clicking on a radio button shows all and only the controls that correspond to the button.

Attachment 157713 [details] shows idea (with two Draw slides).
Click on "General" and only "General" controls are shown.  
Click on "Spreadsheet", only Spreadsheet controls are shown.

(eliminates completely the need to "scroll" in a big window)
Comment 6 Heiko Tietze 2020-02-21 08:39:13 UTC
(In reply to sdc.blanco from comment #5)
> Nope. More like the "Area" tab...

Hm, still not convinced that it's needed. But since there are some +1...