Bug Hunting Session
Bug 90374 - SIDEBAR: Having the sidebar with a fixed width across all tabs
Summary: SIDEBAR: Having the sidebar with a fixed width across all tabs
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 83526 91915 92317 (view as bug list)
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2015-03-31 14:51 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-10-22 18:48 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
indicator when drag resizing Deck is about to collapse closed (9.33 KB, image/png)
2015-04-25 15:29 UTC, V Stuart Foote
Details
sidebar tabs cropped (90.06 KB, image/png)
2015-04-25 16:10 UTC, Yousuf Philips (jay) (retired)
Details
Minimum width of navigation/search sidebar and styles floating window in MSOW2013 (17.86 KB, image/png)
2018-01-24 14:01 UTC, Thomas Lendo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-03-31 14:51:09 UTC
I believe having a fixed width for the sidebar will give us a defined area to work within and will reduce bugs appearing with controls being cropped (e.g. bug 79758, bug 87809) and similar type issues.

Having it resizable doesnt have a benefit when all that is happening is that controls are being stretched to fit the new size or space is being added between the controls.
Comment 1 V Stuart Foote 2015-03-31 16:01:14 UTC
@Jay,

IMHO do not agree *at all*. A fixed Sidebar Deck area locks us into a fixed Sidebar layout. Stretching and shrinking the Sidebar is needed to accommodate dynamic use of the Sidebar as any future content panels are implemented, or users roll their own content panels.

This suggestion is 100% opposite of bug 83526#c5 - "Deck not adjusted for content panel size when switching content panels"

Adjustments to the Sidebar should be a simple and convenient as currently available to customize Toolbars, they are not (some annoyances listed below).

The Sidebar deck and user preferences should be stateful and user configured, and work on bug 85905 - "Allow undocking of Sidebar decks" pursued to allow the Sidebar to become fully functional.


=-Sidebar annoyances-=
bug 33223 - Sidebar: as container for toolbars, ability to add functions missing from Sidebar 
bug 65351 - Sidebar: open pane that was active when last used
bug 67230 - Sidebar does not keep state of Content View in Navigator
bug 67770 - Sidebar customization settings not remembered after reopening
Comment 2 Yousuf Philips (jay) (retired) 2015-04-06 22:18:16 UTC
Stuart,

(In reply to V Stuart Foote from comment #1)
> IMHO do not agree *at all*. A fixed Sidebar Deck area locks us into a fixed
> Sidebar layout. Stretching and shrinking the Sidebar is needed to
> accommodate dynamic use of the Sidebar as any future content panels are
> implemented, or users roll their own content panels.

If in the future there are content panels that go beyond a fixed width that was set, a new fixed size could be implemented. Users rolling their own content panels is something that sounds nice but is never going to be implemented. Do you know of any other applications that allow users to change sidebar content panels, as i've never seen any.

> Adjustments to the Sidebar should be a simple and convenient as currently
> available to customize Toolbars, they are not (some annoyances listed below).

If the sidebar was simply a list of buttons that were easily saved into an XML file, then it would be simple and convenient to customize, but it isnt. The panels are designed in glade (i'm assuming) and function with dev code running behind it.
Comment 3 Yousuf Philips (jay) (retired) 2015-04-12 11:52:50 UTC
Setting it to NEW as its ux-advise and await other people's feedback.
Comment 4 mahfiaz 2015-04-12 15:48:41 UTC
I think we should keep minimum width in mind, but not make the width fixed. In some cases making it wider because of styles dialog names, especially when using larger UI font, or because of the font dropdown to fit longer names is extremely useful and would outweight possible slightly odd look.
Comment 5 Adolfo Jayme 2015-04-12 21:53:25 UTC
This is like going back to the previous .src-based dialogs, with their hardcoded sizes and issues with localizations. Just don’t.
Comment 6 Yousuf Philips (jay) (retired) 2015-04-25 14:40:07 UTC
So is a minimum width agreeable.
Comment 7 V Stuart Foote 2015-04-25 15:29:54 UTC
Created attachment 115092 [details]
indicator when drag resizing Deck is about to collapse closed

(In reply to Jay Philips from comment #6)
> So is a minimum width agreeable.

Behavior now is that while we drag the Deck's width narrower at a point the GUI switches to a close action for the Deck--a Right pointing arrow appears--and release of the drag colapses the deck.

This complements action of a click on the current Tabbar button which collapses the deck for the current content panel(s), or if a different Tabbar button will toggle the Deck to that tab's content panels(s).

The full collapse of the Deck with a click on its Tabbar button seems correct UI/UX.

A drag resize to minimum size -> then collapse (looks to transition when last widget of the specific content panel(s) open has been obscured) also seems correct -- reopening of deck to that same content panel opens it to a "minimum width", for that content panel. And changing the Deck to one of the other Content panel(s) with a Tabbar click retains the prior "minimum width".

The Navigator and Manage Changes content panels seem to incorrectly not allow resize of the deck to point of colapse, but they do honor the "minimum width" if set from another content panel active in the Deck.

All that being said, the current configuration of allowing both a "minimum width" (e.g. last fully exposed widget) prior to collapse of the Deck, and a "maximum width" independently for each Content panel continues to make sense. Especially if we are able to improve function of the Sidebar with per-user customization of bug 67770, and the other issues of comment 1.

So NO, would not agree to a single minimum width applied to Decks of "all" content panels--but that said, there is room to improve how each decks minimum width (prior to collapse) is determined.
Comment 8 Yousuf Philips (jay) (retired) 2015-04-25 16:10:21 UTC
Created attachment 115094 [details]
sidebar tabs cropped

(In reply to V Stuart Foote from comment #7)
> Created attachment 115092 [details]
> indicator when drag resizing Deck is about to collapse closed
> 
> Behavior now is that while we drag the Deck's width narrower at a point the
> GUI switches to a close action for the Deck--a Right pointing arrow
> appears--and release of the drag colapses the deck.

That behaviour doesnt happen for the Properties or Manage Changes tabs.

> This complements action of a click on the current Tabbar button which
> collapses the deck for the current content panel(s), or if a different
> Tabbar button will toggle the Deck to that tab's content panels(s).

Dont forget the 'X' button in the title bar. :D

> The full collapse of the Deck with a click on its Tabbar button seems
> correct UI/UX.
> 
> A drag resize to minimum size -> then collapse (looks to transition when
> last widget of the specific content panel(s) open has been obscured) also
> seems correct -- reopening of deck to that same content panel opens it to a
> "minimum width", for that content panel. And changing the Deck to one of the
> other Content panel(s) with a Tabbar click retains the prior "minimum width".

Is there a point to be able to shrinking down the width of a tab so that the controls start to disappear, similar to the attached image.

> The Navigator and Manage Changes content panels seem to incorrectly not
> allow resize of the deck to point of colapse, but they do honor the "minimum
> width" if set from another content panel active in the Deck.

I was able to resize Navigator to the point of collapse. I find the resize of the deck to point of collapse to be quite useless. Other office suites that implement sidebars dont have such functionality (calligra, iworks, wps/kingsoft).

> All that being said, the current configuration of allowing both a "minimum
> width" (e.g. last fully exposed widget) prior to collapse of the Deck, and a
> "maximum width" independently for each Content panel continues to make
> sense. Especially if we are able to improve function of the Sidebar with
> per-user customization of bug 67770, and the other issues of comment 1.
> 
> So NO, would not agree to a single minimum width applied to Decks of "all"
> content panels--but that said, there is room to improve how each decks
> minimum width (prior to collapse) is determined.

So you wouldnt agree to a single minimum width for all but you'd agree to having independent minimum widths per deck, right?
Comment 9 V Stuart Foote 2015-04-25 23:19:39 UTC
(In reply to Jay Philips from comment #8)

> Is there a point to be able to shrinking down the width of a tab so that the
> controls start to disappear, similar to the attached image.
> 
Sure, you can precisely set the exposed content panel to a width that still fits with a document at a particular zoom level--the Content panel is available to work with, rather than hidden.
 
> I was able to resize Navigator to the point of collapse. I find the resize
> of the deck to point of collapse to be quite useless. Other office suites
> that implement sidebars dont have such functionality (calligra, iworks,
> wps/kingsoft).
> 

We *don't* care about other suites! And allowing resize to point of collapse allows the deck and the content panel to be reopened at that width. Again, useful when trying to hold the document at a particular zoom.

> > So NO, would not agree to a single minimum width applied to Decks of "all"
> > content panels--but that said, there is room to improve how each decks
> > minimum width (prior to collapse) is determined.
> 
> So you wouldnt agree to a single minimum width for all but you'd agree to
> having independent minimum widths per deck, right?

Correct, your stated goal was that "having a fixed width for the sidebar will give us a defined area to work within..." I flatly reject the need for that across all Content panels. 

Rather, there is utility to allowing each active content panel to reduce to some minimum. Either as detected by the GUI widgets present on the active Content panel--or to some predefined minimum assigned per content panel. 

So long as the Deck independently responds to the active content panel--the method for the minimum width can be determined either way. Just not set to one minimum width for all content panels.

We did similar for the Start center, where we allow it to shrink to the width of the Welcome message of the selected UI language, or to the minimum width of one thumbnail view if any are present.
Comment 10 Heiko Tietze 2015-04-27 09:15:21 UTC
Resizing sidebars allows to adopt to different content over tools but not within. As a user I have no benefit from resizing (exaggerated spoken). 

On the other hand, Eve [1] might want to have more individualization since sidebars take a lot of vertical space, too much on 4:3 displays. So it make sense to change the content of the sidebar on resizing. For instance by hiding captions or in general replacing text by icons. Another idea would be to have some kind of alignment that leads to rearranged/wrapped controls depending on the width.

[1] Eve is our persona for expert users. It will be added to the wiki soon.
Comment 11 V Stuart Foote 2015-04-27 12:55:23 UTC
The Sidebar deck already provides for contextual adjustments to active Content Panels.  GtkGrid holds widgets pinned right or pinned left. Dropdowns and spinners resize (with or without minimum). Scroll bars are exposed. Even speciifc content, e.g. Gallery thumbnails respond to resize.

There is a lack of consistency in the implementation between content panels, and between modules.
Comment 12 V Stuart Foote 2015-06-10 12:23:12 UTC
Believe arguments are well formed that neither fixed minimum or fixed maximum width is acceptable behavior for current, or future enhanced function of the Sidebar.

Closing Wontfix.
Comment 13 V Stuart Foote 2015-06-11 18:00:52 UTC
*** Bug 91915 has been marked as a duplicate of this bug. ***
Comment 14 Luke 2015-10-14 03:52:25 UTC
vstuart,
I'm reopening this as 
1) There are multiple users requesting this feature. 
2) We already implement this feature in the main properties sidebar
3) Some of your counter bug examples have been resolved, while others do not directly conflict with this request such as Bug 67770 

I feel Yousuf adequately addressed all the other concerns you had with this feature. This is also the best solution to Bug 92317. Every panel needs a minimum width to be functional. We either need a global minimum as discussed here or a per panel minimum discussed there. A global minimum has the advantage of not needing to dynamically resize the panel when switching between panels of different min width.

I use several application with side panel UIs. LibreOffice is the only one where I often find myself resizing it to fix inaccessible controls. No matter how you spin it, that's a bug not a feature.
Comment 15 V Stuart Foote 2015-10-14 04:36:45 UTC
Sure I'm fine with reopening.  But my position remains as in comment 9 -- individually set minimums are reasonable, but  *no* to setting a global fixed minimum width for any content panel active in the Sidebar deck. As the content of each panel is different--its dimensions should be different: fully extended, or shrunk to colapse.

Otherwise, as Adolfo notes a global minimum width would be like a reversion to prior .SRC based dialogs. 

When issues from 67770/69534 "Sidebar customization settings not remembered after reopening" -- see https://bugs.documentfoundation.org/show_bug.cgi?id=67770#c4 -- are being implemented a fixed global minimum width would be counter productive to their resolution. Fixed minimum would not be needed--so don't implement it that way.
Comment 16 Luke 2015-10-14 07:21:17 UTC
V Stuart,
Bug 67770 is about the sidebar -> customization option being remembered. Where do you get the idea it's about remembering sidebar widths? If so, that's a terrible idea. You do not want the sidebar constantly re-sizing as you click on different objects in your document. 

Bug 69534 is about the modules remembering if the sidebar is open or closed. Again unrelated to the min/max width of the sidebar. 

As a sidebar user, the only state I care to manage is open or closed, open to focus on properties or closed to focus on content. I do NOT want to micromanage the size of the sidebar like I do now because controls get hidden. And I do not want it dynamically re-sizing as I move though my document.
Comment 17 V Stuart Foote 2015-10-14 13:39:29 UTC
(In reply to Luke from comment #16)
> As a sidebar user, the only state I care to manage is open or closed, open
> to focus on properties or closed to focus on content. I do NOT want to
> micromanage the size of the sidebar like I do now because controls get
> hidden. And I do not want it dynamically re-sizing as I move though my
> document.

Absolutely! And that is the granularity of Sidebar customization that we need to provide users. We closed this issue as described in its summary because fixed widths (min/max) are not a route to customization and a full implementation of the Sidebar. See bug 33223 and the various issues in the meta bug 65138.

bug 67770 is about customizations being remembered, widths are just one facet of customizations. As you'd like the widths static--great that is your customization. Others will prefer to have their mix of button widgets and positions and widths remembered.  Some of that comes with the new Sidebar API so folks can roll their own content panels.

bug 69534 was resolved by Caolán's work to "cook up a scheme to allow windows to have per-module settings" it gave us ability to record state of the Sidebar per module--on or off in that limited case, but the basis for supporting further customization.

Now, that said--I'd move to close this issue again WONTFIX.
Comment 18 Bastián Díaz 2015-10-14 14:15:39 UTC
(In reply to V Stuart Foote from comment #17)

> Absolutely! And that is the granularity of Sidebar customization that we
> need to provide users. We closed this issue as described in its summary
> because fixed widths (min/max) are not a route to customization and a full
> implementation of the Sidebar. See bug 33223 and the various issues in the
> meta bug 65138.
> 

So what is the solution?

To me, a min/max for the sidebar is not a way of "personalization" is a way to add consistency to the contents of the sidebar -as a whole-.

How strange it would be that each tab on the sidebar, had its own width min/max.
Actually, at some point he proposed the existence of a minimum and maximum width for the sidebar (not all users have a wide screen), but really the best solution is the existence of a single width for side, consistent bar and It would save time showing and hiding the content (not adjust the width to view the content of some tabs!).

If competition is analyzed, that seems to be the rule.



Cheers
Comment 19 V Stuart Foote 2015-10-14 14:58:14 UTC
(In reply to Bastián Díaz from comment #18)
> So what is the solution?
> 
> To me, a min/max for the sidebar is not a way of "personalization" is a way
> to add consistency to the contents of the sidebar -as a whole-.
> 
> How strange it would be that each tab on the sidebar, had its own width
> min/max.
> Actually, at some point he proposed the existence of a minimum and maximum
> width for the sidebar (not all users have a wide screen), but really the
> best solution is the existence of a single width for side, consistent bar
> and It would save time showing and hiding the content (not adjust the width
> to view the content of some tabs!).

Sure, if the Sidebar were a static UI element we could make a case for fixed static structure. However, we quickly migrated it from .src to GTK .UI based widgets making it dynamic by nature.  Building on that we have "enhancements" in queue to do some neat things like splitting out content panels into independent decks--detaching them as .UI based analogs to legacy dialogs--ref bug 85905

The limitation at the moment is that we implement the Sidebar with its Tabbar and just one Deck holding Content Panels, displayed docked or undocked. From a UI design and development perspective that is constraining--and leads to wrong headed ideas that static and fixed is better UI and improve the user experience.

Fortunately once over that development hurdle the Sidebar gains tremendous flexibility. For example ability to undock a custom content panel and drag your favorite UNO widgets into it--closing the rest of the Sidebar, or shifting to "Single" mode of bug 92220 and bug 92218

We support those longer range features now by ensuring the ability of the user to fully customize their content panels and to retain those customizations within a session and within their profile, with an ability to recover or transfer their customizations to a new profile. That all comes from supporting a design that nurtures dynamic layout and customization.
Comment 20 Bastián Díaz 2015-10-14 15:29:56 UTC
(In reply to V Stuart Foote from comment #19)
> Sure, if the Sidebar were a static UI element we could make a case for fixed
> static structure. However, we quickly migrated it from .src to GTK .UI based
> widgets making it dynamic by nature.  Building on that we have
> "enhancements" in queue to do some neat things like splitting out content
> panels into independent decks--detaching them as .UI based analogs to legacy
> dialogs--ref bug 85905
> 

Yes, I've read a little about it, but the design elements must adapt to the tools to create interfaces or vice versa?

For example, inkscape panels maintain their own proportions (width min/max) when anchored as sidebar, and for me the user experience is horrible.

To move the panels out of the sidebar in LO and that these have their own proportions, it seems useful and good (I have seen other people have a workflow that way), but I think while they are attached as tabs on the sidebar should be consistent.

> and leads to wrong headed ideas that static and fixed is
> better UI and improve the user experience.
> 

OK. Maybe not the best UI, but it works best for me and "other potential users."

> Fortunately once over that development hurdle the Sidebar gains tremendous
> flexibility. For example ability to undock a custom content panel and drag
> your favorite UNO widgets into it--closing the rest of the Sidebar, or
> shifting to "Single" mode of bug 92220 and bug 92218
> 
> We support those longer range features now by ensuring the ability of the
> user to fully customize their content panels and to retain those
> customizations within a session and within their profile, with an ability to
> recover or transfer their customizations to a new profile. That all comes
> from supporting a design that nurtures dynamic layout and customization.

Yes, I think that's good then ... you think you could add a configuration option to keep the width of the sidebar static ...
For some users we only matters show/hide the contents of the sidebar, unfortunately to do that, there must be a "consistent width to allow properly display elements of each tab in the sidebar".

I understand the enthusiasm of developers deliver a better user experience, but I think it can be done without dramatically change the workflow of many users.

Cheers
Comment 21 Luke 2015-10-15 21:11:25 UTC
V Stuart,
You talk about all of these great UI features that we give the users like detaching the pane as if they are somehow in conflict with this feature. They are NOT. Once the pane is detached, the sidebar is no longer a sidebar. It's not at all related to this topic. Width limits on them are separate issue all together.

Finally you fail to address the key issues here:

1) What good are the "dynamic GTK .UI based widgets" when they cannot accessed by the user?
2) Why do we want to a system where the user is constantly tweaking the width instead of providing one that just works?

I never find myself resizing the toolbar because a large icon doesn't fit. The toolbar doesn't require constant adjustment to be functional.  When I use the LibreOffice sidebar, sometime the controls that I'm looking for have been resized off the pane. So I have to resize the sidebar to make them fit. This is a bug. It's not a feature. You are not giving the user anything, just making it harder for them to do their work. There is no benefit. It's ugly. I use several applications with side panes and LibreOffice is the only one forces me to make adjustments to make it usable.
Comment 22 V Stuart Foote 2015-10-15 22:05:30 UTC
(In reply to Luke from comment #21)
> ... Once the pane is detached, the sidebar is no longer a sidebar.
> It's not at all related to this topic. Width limits on them are separate
> issue all together.
> 

Hmm, they really are still the same issue--the underlaying code is still a Sidebar Deck and Tabbar--they're just in an undocked state. Of course they could receive min/max width attributes while docked and a set while undocked. And of course as more docking sites are defined that has to be recorded as well.

> 1) What good are the "dynamic GTK .UI based widgets" when they cannot
> accessed by the user?

In fact they currently can be, as extension or macro. What is currently missing is Drag & Drop GUI, or Customization GUI as with Toolbars.

> 2) Why do we want to a system where the user is constantly tweaking the
> width instead of providing one that just works?
 
There is nothing wrong with giving the users that flexibility. It sucks now because nothing is retained. But that will get fixed, and then what? Moving beyond current implementation is better served by keeping things flexible--not by locking it down.
Comment 23 Bastián Díaz 2015-10-15 22:29:57 UTC
(In reply to V Stuart Foote from comment #22)
> There is nothing wrong with giving the users that flexibility. It sucks now
> because nothing is retained. But that will get fixed, and then what? Moving
> beyond current implementation is better served by keeping things
> flexible--not by locking it down.

Then we change some concepts and not talk to retain or limit, but handing consistent user experience when the contents are docked to the sidebar. For me the idea of the sidebar, is a way to manage a set of tools in a coherent and orderly, not a set of different elements working in the same place (or it appears to be ...). This would also help users / developers to be careful when creating new widgets or macros to run docked to the sidebar, and not find widget cut or overlapping.

I think that also provides flexibility, whereas somewhat flexible does not necessarily mean something unlimited.

Cheers
Comment 24 Luke 2015-10-15 22:31:40 UTC
> It sucks now because nothing is retained. But that will get fixed, and then what? Moving beyond current implementation is better served by keeping things flexible--not by locking it down.

So basically you're advocating to keep the broken UI, because you hope it might be useful when things are more customizable. The current default UI without any user customizations is broken. This should be fixed now. 

How you imagine a future UI may or may not work, it not relevant to this issue. Let's discuss that in a separate bug report.
Comment 25 Robinson Tryon (qubit) 2016-08-25 05:39:14 UTC Comment hidden (obsolete)
Comment 26 Thomas Lendo 2018-01-23 23:41:48 UTC
I'm against any fix width of the sidebar. For comparison: Also in MSO Word 2013 the user can freely choose the width of sidebars like Search and Styles. That fulfills the requirements of many users.

From a UX point of view, what's necessary is 1) a good default width per locale to avoid cropped UI elements and strings and 2) the width that is set by the user must be remembered. If that's realized this request isn't necessary.
Comment 27 Luke 2018-01-24 04:45:44 UTC
(In reply to Thomas Lendo from comment #26)
> I'm against any fix width of the sidebar. For comparison: Also in MSO Word
> 2013 the user can freely choose the width of sidebars 

Thomas, 

No one is asking for a fixed width. This report is about a fixed MINIMUM width. What we want is the sidebar to behave like Calligra, iWorks, WPS Office, and yes, like Word too. All of them prevent you from resizing the sidebar/panel to a point where controls get hidden. 


Like MSO Word 2013, the users will still be able to freely choose the width of sidebars after this bug is fixed.
Comment 28 Cor Nouws 2018-01-24 09:03:42 UTC
So the question is:
do we allow users to pull the side bar width below a size where widgets become dis functional, or should we set a minimum (per deck) so that an arrow appears indicating that continuing with decreasing width will result in closing of the side bar.
My first reaction is: don't care.
My second: if there is a different minimum for each deck, don't do it. It might interact when I have the side bar set smallish and click on another deck, that it closes.
Comment 29 Thomas Lendo 2018-01-24 14:01:12 UTC
Created attachment 139329 [details]
Minimum width of navigation/search sidebar and styles floating window in MSOW2013

(In reply to Luke from comment #27)
> This report is about a fixed MINIMUM
> width. What we want is the sidebar to behave like Calligra, iWorks, WPS
> Office, and yes, like Word too. All of them prevent you from resizing the
> sidebar/panel to a point where controls get hidden. 
Ok, but not a single value for all sidebar decks at once.

The Properties, Page, Navigator (in Writer + Calc), Functions, Manage Changes (experimental in Writer) and Design (experimental in Writer) decks of the sidebar already have a minimum width. But Styles (formerly Styles and Formatting), Slide Transition, Animation, Master Slide, Gallery and Navigator (in Impress + Draw) decks and the Elements pane in Math are resizable to a width where most controls, texts and graphics are unusable.

The minimum width seems to be very wide for some decks (also in comparison to what MSO Word 2013 allows, see my attached screenshot) now. That's because the sidebar is very unflexible in general.

Properties deck has a wide min. width, Functions deck has a smaller, nicer min. width (the reason for the difference doesn't matter, I only speak from UX' standpoint).

(In reply to V Stuart Foote from comment #7)
> So NO, would not agree to a single minimum width applied to Decks of "all"
> content panels--but that said, there is room to improve how each decks
> minimum width (prior to collapse) is determined.
I support this.

(In reply to Yousuf Philips (jay) from comment #8)
> (In reply to V Stuart Foote from comment #7)
> > The Navigator and Manage Changes content panels seem to incorrectly not
> > allow resize of the deck to point of colapse, but they do honor the "minimum
> > width" if set from another content panel active in the Deck.
> I was able to resize Navigator to the point of collapse. I find the resize
> of the deck to point of collapse to be quite useless.
I can't resize Navigator and Manage Changes in 6.0.0.2 for example to a point where it collapses. If you reach the minimum width nothing more happens when moving the mouse towards the sidebar's tab bar.

I want avoid that generally and suggest the following: I like fluent design without a strong fixed point -- I mean that when reaching the minimum width point the sidebar width should snap to it. If the user drags it further towards the tab bar then the sidebar should visibly collapse so that the user has a visual feedback. That happens already today for sidebar decks without a minimum width at about 1 cm before tab bar.

Locking:
Maybe also a setting to lock the width given from the user can be introduced to prevent unwanted changes of the width afterwards, similar to the "Lock Toolbar Position" setting for toolbars. (This shouldn't prevent closing the sidebar deck with a click on the tab icon.)

(In reply to Bastián Díaz from comment #18)
> (In reply to V Stuart Foote from comment #17)
> > Absolutely! And that is the granularity of Sidebar customization that we
> > need to provide users. We closed this issue as described in its summary
> > because fixed widths (min/max) are not a route to customization and a full
> > implementation of the Sidebar. See bug 33223 and the various issues in the
> > meta bug 65138.
> How strange it would be that each tab on the sidebar, had its own width
> min/max.
This isn't an issue today because all decks/tabs of the sidebar in a LO component have the same width. Current given sidebar width doesn't differ between the decks of this sidebar. 

(In reply to Cor Nouws from comment #28)
> if there is a different minimum for each deck, don't do it. It
> might interact when I have the side bar set smallish and click on another
> deck, that it closes.
A good default sidebar width per locale (as said in comment 26) would avoid cropped UI elements and strings in any of its decks. If the user only uses the Styles sidebar, why should he/she be urged to use a wide sidebar only because the Properties deck needs that width?

With a minimum sidebar width of all sidebar decks at once I see a plenty of follow-up bug reports coming. Better to enhance the current handling here and there.
Comment 30 Cor Nouws 2018-01-24 14:28:09 UTC
(In reply to Thomas Lendo from comment #29)

> A good default sidebar width per locale (as said in comment 26) would avoid
> cropped UI elements and strings in any of its decks. If the user only uses

Maybe I just want to slide if a bit to the side to look at something.
If I want to use it and slide so much that some of the widgets don't work, it is more than obvious to me why that happens. And I would blame it on me.
Comment 31 Heiko Tietze 2018-02-21 19:39:54 UTC
Looks to me as we have a min and max width today. And although it makes no sense to me we obviously do not come to an agreement to change it. So keeping the current status.
Comment 32 V Stuart Foote 2018-03-02 00:36:35 UTC
*** Bug 115981 has been marked as a duplicate of this bug. ***
Comment 33 V Stuart Foote 2018-03-02 00:36:47 UTC
*** Bug 92317 has been marked as a duplicate of this bug. ***
Comment 34 V Stuart Foote 2018-03-02 00:37:02 UTC
*** Bug 83526 has been marked as a duplicate of this bug. ***