if a user resizes the sidebar it is mainly to gain area regarding its document and work

is it something wanted to force him to resize the sidebar every time he switches decks or panels ?

The sidebar content must not get cropped on resizing. Therefore it has a minimum width that fit its content. Or at least it should. The prototypical implementation can be found in Writer > Properties (except when a vertical scrollbar is shown). But even there the other panels (Styles & Formatting, Gallery, Navigator) do not work as expected. And controls in the header of the separate navigator sidebar are hidden as well.

Alternative solutions are wrapping controls or to show a chevron like at the toolbar. UX should discuss the pro and cons...

(In reply to Heiko Tietze from comment #2)
> The sidebar content must not get cropped on resizing. 

Why? 

>Therefore it has a minimum width that fit its content. Or at least it should...

Not at all, the dialog/pane widget for the Sidebar Deck simply expands open or closed, and widgets for the objects in each Content Panel respond according to their packing. Shrinking hides widgets until reaching a "minimum" width--before the deck collapses--which is the minimum that fully displays a full button object. That "minimum" changes depending on the widgets exposed on each content panel.

> 
> Alternative solutions are wrapping controls or to show a chevron like at the
> toolbar. UX should discuss the pro and cons...

Or, provide a scroll bar for a pane calculated against the full packing of button objects for all Content Panels occupying the full Deck.

Or, provide a scroll bar for each individual Content Panel (but that would add visual clutter)

Or, complete work needed to provide stateful customization of the sidebar--start with reasonable defaults, and then allow user to set their preferred Deck exposure for working in documents with _each_ module.

(In reply to V Stuart Foote from comment #3)
> (In reply to Heiko Tietze from comment #2)
> > The sidebar content must not get cropped on resizing. 
> 
> Why? 

Almost all basic ux-principles. If you neither show a control nor indicate that there is more (scrollbar, chevron etc.) it's the worst UI ever. And cropping the sidebar's header and deck content is about hiding controls.

> > Alternative solutions are wrapping controls or to show a chevron like at the
> > toolbar. UX should discuss the pro and cons...
> 
> Or, provide a scroll bar for a pane calculated against the full packing of
> button objects for all Content Panels occupying the full Deck.
> 
> Or, provide a scroll bar for each individual Content Panel (but that would
> add visual clutter)
> 
> Or, complete work needed to provide stateful customization of the
> sidebar--start with reasonable defaults, and then allow user to set their
> preferred Deck exposure for working in documents with _each_ module.

Nice list of options. But consider as well the controls in the header not only deck's content. Would be a weird interface with multiple scrollbars ;-) (not that I haven't seen such a crime).

(In reply to Laurent Godard from comment #1)
> if a user resizes the sidebar it is mainly to gain area regarding its
> document and work

If a user needs room for their document, then they should use the zoom slider to obtain more space or click on the sidebar tabs to close the sidebar pane, not resize the sidebar so that sidebar content gets cropped. Its not even possible to shrink down the properties tab once its at its minimum size.

> is it something wanted to force him to resize the sidebar every time he
> switches decks or panels ?

If you resize the formula sidebar tab similar to heiko's screenshot and then jump to the properties tab, you'll be able to see two or three buttons from it per row, which means you'll have to resize the tab so you can see all its content, as the tab isnt functional/useful if all its contents arent visible. This is why having a fixed sidebar width that all sidebar tabs can fit comfortably in is what i prefer rather than sidebar tab sizes constantly bouncing around or having their content cropped.

Seems me and Stuart discussed this similar issue in bug 83526.

(In reply to Heiko Tietze from comment #4)
> (In reply to V Stuart Foote from comment #3)
> > (In reply to Heiko Tietze from comment #2)
> > > The sidebar content must not get cropped on resizing. 
> > 
> > Why? 
> 
> Almost all basic ux-principles.

I disagree, the user should be free to resize the sidebar as he want.

In the case of the Styles & Formatting tab, the style preview may lead to very wide sidebar if some style is defined with a long name and a big font size. Idem in the Properties tab with the style dropdown list.

Currently you can set the Properties tab size to the value you want by changing the Style&Formatting tab size first. So it seems there is several processes trying to set the same size. That should be simplified. 

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #7)
> > Almost all basic ux-principles.
> I disagree, the user should be free to resize the sidebar as he want.

I don't talk about the ability to resize the sidebar (there are other tickets about). But there is absolutely no question that controls must not get hidden on resizing (without any clue that there is more, like chevrons or a scrollbar thumb). You would violate at least these principles:

* Interfaces should provide feedback about their current status. Users should never wonder what state the system is in.

* Users should be able to discover functionality and information by visually exploring the interface, they should not be forced to recall information from memory.

> I disagree, the user should be free to resize the sidebar as he want.

No, the user should be free to reduce the sidebar only to a minimum width defined by the UX designer. If they need more space, they are free to close the sidebar.  Having a sidebar minimized so much it’s not functional, provides absolutely no benefit to the user and looks ugly and unprofessional. The current system is broken. All sidebar panels should have a minimum width.

I'm all for choice, but there is no point in giving the user the freedom to break the UI.

(In reply to Luke from comment #9)
> > I disagree, the user should be free to resize the sidebar as he want.
> 
> No, the user should be free to reduce the sidebar only to a minimum width
> defined by the UX designer. If they need more space, they are free to close
> the sidebar.  Having a sidebar minimized so much it’s not functional,
> provides absolutely no benefit to the user and looks ugly and
> unprofessional. The current system is broken. All sidebar panels should have
> a minimum width.
> 
> I'm all for choice, but there is no point in giving the user the freedom to
> break the UI.


I'm user, and I very much agree with this comment.

Currently is a mess width adjustment in the sidebar of the different applications of LibreOffice. Before getting used to, I lost much time adjusting to the correct width for viewing the content offered by the different tabs. Now I turn to use the maximum width which allows the sidebar and hide when necessary, however, is a problem when you need to use tools in the sidebar while viewing comments in Writer (in 4: 3 is more difficult).

For me, the ideal solution is to have a minimum and maximum width for all tabs in the sidebar, in order to ensure see everything offered at a glance. I think the width of the sidebar, should conform to criteria viewing on 16: 9 (maximum width) and 4: 3 screens (minimum width).

Currently the properties tab has the expected behavior, delivers security, and provides a better user experience.


This has been discussed earlier in: Bug 90374 and Bug 91915

Cheers

*** This bug has been marked as a duplicate of bug 90374 ***