Download it now!
Bug 130102 - default sidebar width
Summary: default sidebar width
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 132041 (view as bug list)
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2020-01-21 06:55 UTC by andreas_k
Modified: 2020-04-14 08:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Default visible sidebar in writer (30.12 KB, image/jpeg)
2020-01-21 07:19 UTC, andreas_k
Details
if an sidebar didn't fit the default size (49.80 KB, image/jpeg)
2020-01-21 07:20 UTC, andreas_k
Details
how MSO make the sidebar (28.46 KB, image/jpeg)
2020-01-21 07:21 UTC, andreas_k
Details
Gallery Sidebar (32.06 KB, image/png)
2020-01-24 09:19 UTC, andreas_k
Details
writer sidebar width of the different decks (214.76 KB, application/vnd.oasis.opendocument.text)
2020-01-24 09:51 UTC, andreas_k
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andreas_k 2020-01-21 06:55:30 UTC
there are different sidebars but at least the specific sidebars didn't fit into the width of Style/Font/Paragraph so the user has to have always change the sidebar width depend on the content sidebar. This width change also give visual glitches.

can there be an default sidebar width all sidebars has to (perfect) fit. I'm thinking of the width of the default sidebar elements (Style, Font, Paragraph for writer). At least in english language.
Comment 1 andreas_k 2020-01-21 07:19:41 UTC
Created attachment 157290 [details]
Default visible sidebar in writer

this can be the size of all sidebar's, at least you would get no visual issues
Comment 2 andreas_k 2020-01-21 07:20:23 UTC
Created attachment 157291 [details]
if an sidebar didn't fit the default size
Comment 3 andreas_k 2020-01-21 07:21:49 UTC
Created attachment 157292 [details]
how MSO make the sidebar

you can change the size at MSO but in the default width all elements fit's in addition they use always the same layout and the same widget's.
Comment 4 andreas_k 2020-01-21 08:00:54 UTC
I also would like to make the gallery sidebar 3  collum width, which would be a bit larger than now. Change to that width could help the other sidebar widgets.
Comment 5 V Stuart Foote 2020-01-21 14:22:40 UTC
@Andreas, * 

This has been covered in depth. And only resolved facet is that the Sidebar decks will not revert to the 'fixed' widths of the legacy .src based GUI.

It is directly the opposite of bug 128180

IMHO => WF

(In reply to andreas_k from comment #4)
> I also would like to make the gallery sidebar 3  collum width, which would
> be a bit larger than now. Change to that width could help the other sidebar
> widgets.

No objection to that (a default opening of the content panel with icons sized to fit 3 columns) but as implemented--as the content panel is made wider or narrower the icons will respond and resize--and, at some icon maximum, the column count will shift. Increasing with width to max or 4 or decrease with width to 1, before the deck will collapse.

The tiles holding the icons as the Gallery is resized will shrink, but have an issue open that it does so only in the x-axis, keeping a minimum y-axis height that makes the tiles look weird prior to the deck's collapse. Could not find that BZ id just now.
Comment 6 Heiko Tietze 2020-01-22 10:15:13 UTC
An evergreen... opinions in addition to what Stuart said?
Comment 7 andreas_k 2020-01-22 14:08:58 UTC
The default sidebar should be that size where all sidebars fit. In addition the user can change the size of the sidebar depends on there need but it should be an additional thing.
Comment 8 V Stuart Foote 2020-01-22 14:50:49 UTC
(In reply to andreas_k from comment #7)
> The default sidebar should be that size where all sidebars fit. In addition
> the user can change the size of the sidebar depends on there need but it
> should be an additional thing.

If you mean that all sidebar decks open to the same "master" width with a default user profile, I don't have too much heartburn over that provided all user configurations and last used state for each of the decks then get recorded back into user profile.

But then calculating what that "master" width would be seems challenging. Would have to be done by os/de and os locale setting--because GTK packing changes by os/de, as does width of labeling and droplist content by localization.

for consistent UX I would rather have a consistent set of rules:

1. drag expand to some reasonable maximum by os/de & locale
2. drag collapse to some reasonable minimum, before full collapse of the deck by os/de & locale
3. any width set per deck becomes the value for that deck for that LO module--in the current session
4. on save/close option to make those session last used values, new user defaults per module per deck, recorded to profile for next launch.

(1&2 as done in the Gallery deck now)
Comment 9 andreas_k 2020-01-24 09:17:18 UTC
(In reply to V Stuart Foote from comment #8)
> If you mean that all sidebar decks open to the same "master" width with a
> default user profile, I don't have too much heartburn over that provided all
> user configurations and last used state for each of the decks then get
> recorded back into user profile.

That's the idea of this bug report.

> But then calculating what that "master" width would be seems challenging.
> Would have to be done by os/de and os locale setting--because GTK packing
> changes by os/de, as does width of labeling and droplist content by
> localization.

That's one of the problem
Comment 10 andreas_k 2020-01-24 09:19:07 UTC
Created attachment 157391 [details]
Gallery Sidebar

> (1&2 as done in the Gallery deck now)

the gallery deck show now only one image per row it doesn't look like it's so usefull see attachment
Comment 11 andreas_k 2020-01-24 09:51:05 UTC
Created attachment 157393 [details]
writer sidebar width of the different decks

this may show the big issues. you can "fix" this bug with make the sidebar elements size smaler, but in the end it would be easier if there is an default width where all items fit's.

issues are:
- Backends (GTK3/QT/...)
- OS
- Translation
- Layouts (ui files)

anyway maybe we can define an maximal width depend on the 4 items so that everything fit's well.
Comment 12 andreas_k 2020-01-25 23:19:59 UTC
As now the sidebar width is the MINIMUM of the first visual UI elements.

I don't think that an MINIMUM is the best decision for the default, would it be possible to use MINIMUM + 20% as default.

Optimum = Minimum * 1,20

That would solve a lot of issues if other translation stuff is a bit longer than the default widgets.
Comment 13 Heiko Tietze 2020-02-05 13:54:44 UTC
Sidebar max width was discussed in some meetings, among others in (1) or (2), culminated in a survey which results are presented in (3) and the guideline (4). One point is "Do not crop controls. Define one minimum width depending on the content of all tabs." In bug 128180 a smaller minimum was requested and we decided to resolve as WF, likewise we did in bug 90374 about a fixed width across all tabs.

So the initial request to have one fix width is a WF. As Stuart said in comment 8 we should focus on better positioning of controls, IMHO also a stricter selection of what is shown, labels for accessibility etc. Should it be done on this ticket, or at all? Probably not unless the topic receives more attention.

(1) https://wiki.documentfoundation.org/Design/Meetings/2016-02-05
(2) https://wiki.documentfoundation.org/Design/Meetings/2016-02-19
(3) https://design.blog.documentfoundation.org/2016/04/17/our-happy-hour-how-libreoffice-sidebar-tenders-properties-and-functions/
(4) https://wiki.documentfoundation.org/Design/Guidelines/SideBar

(In reply to andreas_k from comment #3)
> you can change the size at MSO but in the default width all elements fit's
> in addition they use always the same layout and the same widget's.

Using one control per row results in a clean layout, no question. And it also has the advantage of (accessible) labels everywhere. But keep in mind that we provide access to much more functions and attributes from the sidebar.
Comment 14 Heiko Tietze 2020-02-20 10:38:14 UTC
We discussed the topic in the design meeting and there is not much to add to comment 13. => WF
Comment 15 V Stuart Foote 2020-04-12 13:30:08 UTC
*** Bug 132041 has been marked as a duplicate of this bug. ***