Created attachment 124669 [details] Paragraph style: Current layout Currently we have some dialogs which have multiple rows of tabs, for example the "paragraph style" dialog. I find it highly confusing to use this kind of tabs. As they are not in one row, it is hard to read all tabs to get a glance what tabs you have. Also when selecting a tab from the top, that row moves to the bottom, which is even more confusing, since the position of all tabs changes. I have two ideas how to improve the situation: 1. Leave the tabs as they are (multiline), but don't switch rows when selecting a tab from the top. 2. Stop using multiline tabs at all and use vertical tabs instead (have them on the left). Any thougts on this?
Created attachment 124670 [details] Mockup: Vertical tabs for paragraph style dialog
The proposal was to introduce icon views instead of tabs. Looks tidy and modern with icons and enough white space. But I remember harsh criticism saying we cannot change all dialogs. http://listarchives.libreoffice.org/global/design/msg07251.html https://wiki.documentfoundation.org/Design/PropertyDialog An alternative is to just disable multiline tabs. In that case, arrows allow to navigate to the undisplayed tabs.
(In reply to Heiko Tietze from comment #2) > The proposal was to introduce icon views instead of tabs. Looks tidy and > modern with icons and enough white space. But I remember harsh criticism > saying we cannot change all dialogs. In this case we have *17* tabs. That would mean a lot of scrolling with your mockup. I'm sure power users would complain very soon. If anything, I would keep the small tab size and add icons left to the text, like: [icon] label [icon] label ... > > http://listarchives.libreoffice.org/global/design/msg07251.html > https://wiki.documentfoundation.org/Design/PropertyDialog > > An alternative is to just disable multiline tabs. In that case, arrows allow > to navigate to the undisplayed tabs. This is ok as long as there is one or two tabs that cannot be shown by default, but I wouldn't do it if half of the tabs need scrolling, this would also seriously slow down power users.
(In reply to Samuel Mehrbrodt (CIB) from comment #3) > (In reply to Heiko Tietze from comment #2) > > The proposal was to introduce icon views instead of tabs. Looks tidy and > > modern with icons and enough white space. But I remember harsh criticism > > saying we cannot change all dialogs. > > In this case we have *17* tabs. That would mean a lot of scrolling with your > mockup. I'm sure power users would complain very soon. If anything, I would > keep the small tab size and add icons left to the text, like: > > [icon] label > [icon] label > ... Looks as a reasonable idea. Wrt power users: one might expect a decent key stroke to move to the next/previous page/tab. Maybe the same as currently. We must realize that also dialogs with as little as two tabs exist. Then the labels in a vertical row is a waste of space.. (In reply to Samuel Mehrbrodt (CIB) from comment #0) > I have two ideas how to improve the situation: > 1. Leave the tabs as they are (multiline), but don't switch rows when > selecting a tab from the top. I would love to see some experimenting with that.
(In reply to Cor Nouws from comment #4) > We must realize that also dialogs with as little as two tabs exist. Then the > labels in a vertical row is a waste of space.. Sure, I am talking about dialogs with more than one row of tabs, I wouldn't change the others. > I would love to see some experimenting with that. Maybe we can do this as a first step and then iterate? Or do we want to ban multiline tabs at all, then I won't waste time on this.
Stacking text/tabs to avoid whitespace and having different UI concepts that would be two epic design failures.
(In reply to Samuel Mehrbrodt (CIB) from comment #5) > Sure, I am talking about dialogs with more than one row of tabs, I wouldn't > change the others. Would look odd to me, to have two types.. > > I would love to see some experimenting with that. > > Maybe we can do this as a first step and then iterate? Or do we want to ban > multiline tabs at all, then I won't waste time on this. I would love to have a look with a not so much used dialogue maybe in a daily. Heiko, what do you think? Honestly I see no solution, bringing more improvements that drawbacks ;) , in the first option.
When there is a limited number of tabs and the dialog contains functionality that is seen by basic users (benjamin), the icon-based vertical tabs which is found in the hyperlink dialog is nice. We are hoping to implement this in a simplified options dialog (bug 90989). When there are many tabs and the dialog is primarily focused on more experienced users (eve), the non-icon vertical tabs found in the options dialog is nice. MS Office does a similar type of vertical tabs dialog with sufficient white spacing between each entry - https://support.content.office.net/en-us/media/5053c209-22b4-4336-a8ec-fd03d4547678.jpg
I find the current layout much more clear and faster readable than any vertical layout. Most people are used to read LTR or RTL, not top to bottom or reverse. Also there is much more horizontal than vertical space. Using a scrollbar would be a usability disaster. A vertical layout should only be an option for very few (~handful) points. Disabling multiline tabs and showing arrows to scroll reduces the usability too because you can't have all options at a look, what's important especially for Benjamin to find the right tab/option.
(In reply to Thomas Lendo from comment #9) > Most people are used to read LTR or RTL, not top to bottom or reverse. The contents of the tabs are ordered top to bottom in columns. > Also there is much more horizontal than vertical space. That all depends on how the controls are organized. Many tabs have extra wide controls for no reason (e.g. Character dialog's hyperlink and highlighting tabs, nearly every tabs in the Paragraph dialog) > Using a scrollbar would be a usability disaster. A vertical layout should only > be an option for very few (~handful) points. Cant say i agree with you, as when you have content that is larger than the available space, scrollbars are common and useful (e.g. browser, file manager). Alternatively you would have to have more vertical tabs, but you wouldnt be for scrolling within the vertical tabs.
Having no tabs at all, and have every area collapsing/expanding (like "Other options" section in Find & Replace dialog) would IMO be much better option. Such layouts are used e.g. in apps like 3ds max, AutoCAD (MS Office has a single non-collapsing long sheet, and that is much worse). Having a dialog with all such sections initially collapsed would create something like ToC right in the middle of the main dialog area; clicking the expand button would automatically bring the area to the center of the dialog; and the scrollbar would only be needed when several of the areas are expanded (and then it would be handy IMO, not a "usability disaster").
(In reply to Mike Kaganski from comment #11) > Having no tabs at all... The pattern is called accordion and would change the native integration (see also bug 120371 c15). Not an easy decision.
Samuel, with the latest changes by Caolan can we close this issue as solved/wfm? Since we aim to be as close to the system as possible, the alternative concepts with accordions or icon views are also a wontfix. In a nutshell, feel free to reopen.
(In reply to Heiko Tietze from comment #13) > Samuel, with the latest changes by Caolan can we close this issue as > solved/wfm? Since we aim to be as close to the system as possible, the > alternative concepts with accordions or icon views are also a wontfix. In a > nutshell, feel free to reopen. The issues I described in comment 0 are still there. I can't see how recent changes have improved anything there.
(In reply to Samuel Mehrbrodt (CIB) from comment #14) > I can't see how recent changes have improved anything there. gtk3 has no multiline tabs anymore, see also bug 121752.
gtk3 is not our only backend
And gtk3 also has multiline tabs in current master?!
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
*** Bug 113418 has been marked as a duplicate of this bug. ***
Vertical Gnome-like tabs were requested on bug 113418. (In reply to Heiko Tietze from bug 113418 comment #12) > We discussed this in the design meeting: > > + dialogs with vertical "tabs" wouldn't be according the OS/DE anymore > but make the application likely more appealing than (stacked) tabs > + sidebar with large image and text might be a good solution for option > dialogs but not in case of properties; good icons are very challenging > and doubt it's helpful (Sascha) > + would appreciate the sidebar with icon solution instead of tabs (Rizal) > + never liked the tabs, go with sidebar (John) > + ideally we have a solution that can be reverted if not accepted (Heiko)