Bug 113418 - scrolling vertical tab bar instead of horizontal multi-tab dialogs
Summary: scrolling vertical tab bar instead of horizontal multi-tab dialogs
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Dialog
  Show dependency treegraph
 
Reported: 2017-10-24 22:14 UTC by zyklon87
Modified: 2018-01-19 11:30 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Gnome settings (global view) (129.78 KB, image/png)
2017-12-18 00:41 UTC, zyklon87
Details
Gnome settings (submenu view) (59.64 KB, image/png)
2017-12-18 00:42 UTC, zyklon87
Details
Builder settings layout (114.11 KB, image/png)
2017-12-18 20:54 UTC, zyklon87
Details

Note You need to log in before you can comment on or make changes to this bug.
Description zyklon87 2017-10-24 22:14:30 UTC
Description:
Having several interchangeable rows of tabs at the top is not that good UI design. It always is confusing, has no structure and one always has to think first, which row is where, then which row do I need, and last which tab of that row do I select. Would you consider using a side panel like the Gnome guys now changed to in gnome-control-center [1]? Thats far more convenient and especially useful, if there are a lot of items. That’s also the case why now there’s the Firefox Tab Center Redux add-on!

[1] https://blogs.gnome.org/aday/2016/01/13/a-settings-design-update/

Steps to Reproduce:
.

Actual Results:  
.

Expected Results:
.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 V Stuart Foote 2017-10-25 04:30:52 UTC
I'm neutral on this. 

Imagine it would have to touch a lot of multi-tab dialogs if replaced in bulk, but moving to a scrolling vertical tab bar could be cleaner for holding configuration settings and properties.

Easyhackable?
Comment 2 V Stuart Foote 2017-10-25 04:40:26 UTC
Tools -> Options is already in a vertical format. While File -> Properties is of the objectionable type. 

But there are dialogs like Character, Paragraph, Page, Area that are by design functional with horizontal tabs.

There is something to be said for consistency--but maybe just too much layout rework (and user grief) for too little gain.
Comment 3 Heiko Tietze 2017-10-25 06:53:21 UTC
This idea made it into the preliminary HIG for property dialogs years ago https://wiki.documentfoundation.org/Design/PropertyDialog

The response back then was mixed.
Comment 4 Thomas Lendo 2017-10-26 00:29:52 UTC
Moving from (multiline) horizontal tabs to a vertical tab list would increase the height of some dialogs. A vertical list is handy if only few items are in.

Are there mockups for dialogs like for paragraphs and UX studies to show what's more efficient and easier to use for users?
Comment 5 zyklon87 2017-12-18 00:41:55 UTC
Created attachment 138497 [details]
Gnome settings (global view)
Comment 6 zyklon87 2017-12-18 00:42:16 UTC
@Heiko: The vertial list entries in this mock-up are pretty tall, I’d prefer icons on the left side of the text, like it is done in the LO menus or in the new Gnome settings. I added two screen shots of Gnome settings, where you also see how they implemented layers (first SS shows global settings, second SS was done after clicking “Geräte” – you then see the title “Geräte” inside the header bar, together with a “back” button).
Comment 7 zyklon87 2017-12-18 00:42:50 UTC
Created attachment 138498 [details]
Gnome settings (submenu view)
Comment 8 Heiko Tietze 2017-12-18 08:56:07 UTC
Small or medium sized icons are not suited as headlines, IMHO, it has to be an outstanding eye catcher compared to functions in the right content section. And text right of the icons may end in trouble with localization, or your dialogs grow like Gnome's.

My solution to this was to show a few items with big buttons for the most important properties along with an overview of settings, and a small list or tree (with no icons) in another expert mode, which is also being activated if the user clicks on a link in the mentioned overview. It looks like this http://scrabble.sourceforge.net/wiki/index.php/Configuration:Rules
Comment 9 zyklon87 2017-12-18 20:53:48 UTC
Well, you’re complaining about icons being too small, while in the current implementation, there aren’t any at all…? Additionally, these headings with icons would then look like the current LO menu implementation, which fulfills a pretty similar purpuse (making settings accessible via a menu structure). There, I also don’t see a downside of icons next to the text.

Still, you could of course do that with big icons and sub settings menus, like you proposed. But I really wouldn’t do modes at all, because a lot of users (like me) activate that instantly, just for not missing anything when searching for a setting (and never deactivate it again). Additionally, you’ll have two completely different settings windows, depending on which mode you’re in, what makes it pretty complicated to find/remember a setting, and is confusing at all.

Instead I’d rather do an “Advanced” Settings page with sub-settings, for having no mode conflicts and a user then learns faster, what’s in there and if he/she needs to (ever) look into it. When you have modes, it’s far harder to learn if you need expert mode or not. And I’d call that mode “advanced” instead of “expert”. ;)


I append my proposal for a new Gnome Builder settings UI, I did last week. What do you think about that? On the left pane, you’ll have the main categories (with big icons if you like). And then you have a GtkStackSwitcher at the top of the main view for sifting through sub-settings. This way you don’t need to “get back to the upper menu layer” (with the main menus being hidden), and you also don’t have big structures/trees. With everything being split in a vertical main menu and a horizontal sub menu, you’ll also recall setting’s locations faster than in any kind of tree or mode.
Comment 10 zyklon87 2017-12-18 20:54:17 UTC Comment hidden (off-topic)
Comment 11 Heiko Tietze 2017-12-27 09:03:44 UTC Comment hidden (off-topic)