Download it now!
Bug 115981 - SIDEBAR: Panel's minimum width can be circumvented hiding controls on the panel
Summary: SIDEBAR: Panel's minimum width can be circumvented hiding controls on the panel
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2018-02-23 22:11 UTC by Luke
Modified: 2020-10-01 10:06 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2018-02-23 22:11:38 UTC
This is a followup to Bug 90374 which was a mess of different ideas. This is dealing with a specific problem in our UI. 

Steps to Reproduce:
1. Resize the 'Properties' panel 
2. Note how how it has a minimum allowable width
3. Switch to 'Style' or "Galley"
4. Reduce width by +50%
5. Switch back to 'Properties' panel in the sidebar

Note the properties panel is now in an invalid state. Controls are hidden and inaccessible. There is no way to scroll to reach the hidden elements. 

Other suites like Calligra, iWorks, WPS Office, and MS Office do not let you reduce panel size to a point where the UI elements are broken. 

When you switch to a panel that had a defined min value, the panel should be resized to meet those constraints.
Comment 1 V Stuart Foote 2018-02-24 00:26:24 UTC
And it is a trivial and consistent action to swipe the Deck size inward (to left) to open it past minimal width and swipe outward (to right) to drop it back to the decks minimum.

I do prefer to be able to shrink all the decks past their minimum (I use Style or Gallery deck which allow shrink to collapse). Allowing me to give up exposure of some of the controls to be able to hold the document canvas at a set scale with fixed width. And I want my "customization" to profile to included these settings.

As was noted on the the other WF issue, having the Sidbar deck expand and contract to a set minimum would be annoying as it would impact the canvas (obscure it or resize it depending on mode).

The width controls for the decks are fine as the are, beleive Heiko had an idea of providing a "double hash" to indicate Content Panel controls hidden--and on click to expose (by drop list, or wrapped toolbar) the additional controls--or even fully expand to minimum width the deck.
Comment 2 V Stuart Foote 2018-02-24 00:44:31 UTC
IMHO => NAB, Sidebar Decks can be expanded from any collapsed state.

But worth some additional dev work to implement a reasonable "minimum" for each deck (based on width of the widgets present on any deck) to snap open to--via a button action. But also should restore ability to shrink to collapse for _all_ decks. The UI already remembers the deck width--content panel to content panel--so this is likely better dev choice anyhow.

And, there is the other facet of working polyglot. Changing local will expand contract the "minimum" widths depending on the string lengths for many of the list widgets and control labels.
Comment 3 Heiko Tietze 2018-02-24 08:50:21 UTC
(In reply to V Stuart Foote from comment #2)
> But worth some additional dev work to implement a reasonable "minimum" for
> each deck (based on width of the widgets present on any deck) to snap open
> to--via a button action.

That was what we agreed on, more or less. Otherwise we would have to show a horizontal scrollbar to indicate that controls are hidden.
Comment 4 Thomas Lendo 2018-03-01 23:14:05 UTC
Isn't this a duplicate of Bug 92317 or Bug 83526?
Comment 5 V Stuart Foote 2018-03-02 00:36:35 UTC

*** This bug has been marked as a duplicate of bug 90374 ***
Comment 6 V Stuart Foote 2018-03-02 00:37:58 UTC
Actually they all are dupes of bug 90374--Luke and Jay continue to be out voted, so => WF
Comment 7 Luke 2018-03-02 06:11:27 UTC
No, this is not a dupes of bug 90374. That is an enhancement about having "a fixed width across ALL tabs". This is about tabs that already have a defined MINIMUM width. The minimum width can be circumvented by following the steps above. This is a bug.
Comment 8 Telesto 2018-03-02 09:04:39 UTC
This is in essence a dupe of bug 90374; it describes the same issue. If the issue is present as problem (bug 90374) or solution (enhancement, comment 7) doesn't matter.

I personally agree with Luke, it's a bug. A minor one though. Different minimum sizes is unexpected and counter-intuitive for the basic - regular? - user (surprise effect).

--

Some basic question in advance (which someone should answer first)
* Why are there minimum deck size?
-> 
* Why a the minimum/maximum sizes of the decks a shared setting?
-> Visual consistency? 

--

Personal opinion:
-> It's illogical: if we acknowledge the need for minimum sizes, then we should respect them in any case. No circumventions.. 
-> It's Inconsequent (no unity): All decks look the same, some should behave the same
-> It's unfunctional: I would expect a deck to be functional when switching decks
-> It's visually annoying if every deck had a own size setting. 

A small size will render some decks unusable, a larger size doesn't hurt. Based on consistency I would like a global default minimum size, where all the decks are fully functional.

I understand that there are some user cases, for shrinking the deck below the "global" minimum. Which sounds a bit like special user needs (my opinion; no workflow expert). A possible solution would be to 'set a default minimum size' which can be bypassed. Something like CTRL+DRAG for people who really want that to happen...
Comment 9 V Stuart Foote 2018-03-02 14:32:55 UTC
Yes, as I've been saying. I have little trouble that a deck or content panels can shrink/open at less that its minimum width (i.e. a sum of widths of widgets and labels) and have widgets hidden. That is a helpful feature of the Sidebar, which by the way is exactly the behavior of Toolbars.

What still needs to be implemented for Sidebar is a button control on the Title bar of each Deck to snap that deck to its calculated minimum, while allowing the _all_ decks to expand/contract (and holding that width while switching Deck to Deck) to a users preferred width while working on a document, and make the GUI consistent.

As implemented Gallery, Styles, Transitions, Animations, Decks/Content Panels are correct! They each resize fully until collapse.

A number other decks modified with enforced minimums--e.g. Properties, Page, Navigator (in Writer)--have all been _broken_ during implementation as they can not be reduced in width to collapse. They are inconsistent and break the UI/UX.

To move this forward, suggest we:

1) set a dynamic minimum (widgets + labeling width--localized) for each deck 
2) provide a button control on the Deck Title bar to snap to that width 
3) restore the drag width to collapse for all decks to make the UI consistent
Comment 10 sdc.blanco 2019-10-18 09:21:17 UTC
(In reply to V Stuart Foote from comment #9)

> What still needs to be implemented for Sidebar ... 
> allowing the _all_ decks to expand/contract (and holding that width while
> switching Deck to Deck) to a users preferred width while working on a
> document.

This is the kind of enhancement requested in bug #128180.

(As a practical illustration -- to justify this capability -- I sometimes keep the Navigator Deck wide (to use bookmarks), but do not want Properties and Styles to be so wide (when switching to them -- it takes up too much screen space)
Comment 11 Heiko Tietze 2020-10-01 10:06:20 UTC
Shouldn't be an issue anymore, see also bug 104632 and bug 79758.