Bug 99528 - Better handling for multiline tabs
Summary: Better handling for multiline tabs
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Dialog-UX
  Show dependency treegraph
 
Reported: 2016-04-27 11:00 UTC by Samuel Mehrbrodt (CIB)
Modified: 2019-03-04 08:05 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Paragraph style: Current layout (58.93 KB, image/png)
2016-04-27 11:00 UTC, Samuel Mehrbrodt (CIB)
Details
Mockup: Vertical tabs for paragraph style dialog (25.90 KB, image/png)
2016-04-27 11:01 UTC, Samuel Mehrbrodt (CIB)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Mehrbrodt (CIB) 2016-04-27 11:00:46 UTC
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?
Comment 1 Samuel Mehrbrodt (CIB) 2016-04-27 11:01:25 UTC
Created attachment 124670 [details]
Mockup: Vertical tabs for paragraph style dialog
Comment 2 Heiko Tietze 2016-04-27 12:37:54 UTC
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.
Comment 3 Samuel Mehrbrodt (CIB) 2016-04-27 12:53:28 UTC
(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.
Comment 4 Cor Nouws 2016-04-27 13:12:25 UTC
(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.
Comment 5 Samuel Mehrbrodt (CIB) 2016-04-27 13:16:06 UTC
(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.
Comment 6 Heiko Tietze 2016-04-27 15:06:00 UTC
Stacking text/tabs to avoid whitespace and having different UI concepts that would be two epic design failures.
Comment 7 Cor Nouws 2016-04-27 16:53:45 UTC
(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.
Comment 8 Yousuf Philips (jay) (retired) 2016-04-27 18:24:50 UTC
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
Comment 9 Thomas Lendo 2017-05-18 22:59:36 UTC
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.
Comment 10 Yousuf Philips (jay) (retired) 2017-05-19 20:01:52 UTC
(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.
Comment 11 Mike Kaganski 2018-12-10 06:05:14 UTC
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").
Comment 12 Heiko Tietze 2018-12-10 16:14:15 UTC
(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.
Comment 13 Heiko Tietze 2019-03-01 13:43:40 UTC
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.
Comment 14 Samuel Mehrbrodt (CIB) 2019-03-04 07:02:12 UTC
(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.
Comment 15 Heiko Tietze 2019-03-04 07:42:35 UTC
(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.
Comment 16 Tomaz Vajngerl 2019-03-04 08:04:52 UTC
gtk3 is not our only backend
Comment 17 Samuel Mehrbrodt (CIB) 2019-03-04 08:05:39 UTC
And gtk3 also has multiline tabs in current master?!