[Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|REOPENED|NEW --- Comment #14 from Heiko Tietze --- Rather than introducing a complex calculation I would make the widget itself resize on small screens / window sizes so it shrinks to only one style width. Anyway, I think we can agree on the fact that a large unfilled are is odd. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580
Jeff Fortin Tam changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Ever confirmed|0 |1
Resolution|WONTFIX |---
--- Comment #13 from Jeff Fortin Tam ---
> We do have a priority for the sections,
> but the styles preview was always attributed to be important.
The "important" section priority attribute doesn't work in practice if the
important-flagged section ends up not being shown visually, no?
>> I don't understand how you can essentially conclude that my proposal is
>> taking anything essential away from anyone...
>
> You proposed to change the overflow procedure and to first hide the styles
> preview.
> Actually, translating into algorithm, to start with the largest section.
_When_ the window width is calculated to be insufficient for that widget.
It still does not take anything away if you do it by measuring available space;
it's not "crippling" the widget if it already isn't showing its contents
anyway…
In principle, my proposed change _adds_ functionality, especially on your WXGA
target,
by filling that visually empty space with either a compact version of the
styles widget,
or other things that can fit, instead of just showing nothing on ⅓ of the
width.
Can't something like the logic below be achieved even with the current toolkit
tech?
On window width set:
1. gtk_widget_get_width (or some equivalent) for each shown widget section
container placed before (left side) of the styles preview widget, sum them up
2. Get the width of the permanent ("Home" and "Find") widgets on the right
3. Substract 1 and 2 from the window width number to get the "available space"
number
4. Get the width of the styles preview widget, to determine if it would fit
within the "available space" number (i.e. fit between the left and right stuff
previously measured)
5. If space is insufficient, either show a compact version, or order* it later
in the toolbar so that other more compact widgets (ex: the "Table" and "Zoom"
sections) can fill that space by being shown before the styles preview widget
(which would still be available in the offscreen expander widget _just like it
currently does in practice anyway_)
*: If "reordering" is somehow technically impossible, I presume there's another
trick:
duplicate that widget's section in the UI file,
and hide()/show() the first or second instance of it based on the context?
If possible, this would make it a better "adaptable" user experience out of the
box.
Even for higher-res screens, it would improve compatibility with split-screen
tiling.
Yes, in theory tech-savy/geeky users like me can turn off that section
entirely,
but the reason why I'm reopening this for consideration is that I care about
the out-of-the-box UX for your less technical users :)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Stéphane Guillou (stragu) changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3525 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #12 from Heiko Tietze --- (In reply to Jeff Fortin Tam from comment #11) > I don't understand how you can essentially conclude that my proposal is > taking anything essential away from anyone... You proposed to change the overflow procedure and to first hide the styles preview. Actually, translating into algorithm, to start with the largest section. (In reply to V Stuart Foote from comment #3) > The NB has a simple priority test based on available LO frame width... We do have a priority for the sections, but the styles preview was always attributed to be important. In the end it boils down to whether the interaction with styles or quickly inserting tables is more important (we provide alternative access for both functions). If your screen is very small, you can customize and disable the styles preview. And of course, if you disagree with the decision, feel free to reopen. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #11 from Jeff Fortin Tam --- Created attachment 190566 --> https://bugs.documentfoundation.org/attachment.cgi?id=190566=edit Screenshot at 1280x768 I don't understand how you can essentially conclude that my proposal is taking anything essential away from anyone by either showing "the other widgets that can fit" or a compacted popup button version of the styles preview widget, _when the style widget couldn't be shown and nothing would be shown at all anyway_. It's additive, not substractive. It improves UX rather than takes anything away from it, as that space was already lost/empty. > OTOH, we have a guideline for the total width (1280x768px/WXGA). Indeed, the new attached screenshot here shows the UI failing that specific guideline, by wasting one third of the screen's width that could be used to show something. And I'm using the English language (which is quite compact) for the UI there, not even French or German, so my example is gentle… -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Heiko Tietze --- (In reply to V Stuart Foote from comment #3) > IMHO => WF (In reply to Heiko Tietze from comment #9) > => WF No further input, resolving WF now. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #9 from Heiko Tietze --- Besides shuffling being odd and the customizability I'd like to point out that the styles preview is an essential control and you should rather hide other items. Home > Table is also available under Insert > Table, Zoom can be adjusted via View, and the Navigator has an button on this tab too. (In reply to Stéphane Guillou (stragu) from comment #6) > - Tab sections should be less than X pixels in width; We must not cripple the styles preview, for example. And I'd say the controls and sections are reasonably designed. OTOH, we have a guideline for the total width (1280x768px/WXGA). > - If a tab section is more than X pixels, it needs to have an alternative > view that can reduce it to below the limit. Quite some effort. If screen space is crucial, the user should pick a different UI layout. => WF -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #8 from V Stuart Foote --- (In reply to Stéphane Guillou (stragu) from comment #7) Not a great example, MS uses a fully scoped Ribbon API, in both UWP and win32 [1] for builds of MS Office for Windows/macOS. Not a good model as we would never implement it as native code as we have to be mindful of cross-platform parity in the UI. The Glade UI framework cobbled together for the MUFFIN NB does really support dynamic reordering or pushing from NB onto collapsed listbox beyond what was done already for the exposure chevrons. =-ref-= [1] https://learn.microsoft.com/en-us/windows/win32/windowsribbon/-uiplat-windowsribbon-entry -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Stéphane Guillou (stragu) changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||4953 --- Comment #7 from Stéphane Guillou (stragu) --- (In reply to Stéphane Guillou (stragu) from comment #6) > MS Office 365 (online) does _both_ of the above suggestions ... and OnlyOffice only reduces the number of columns (until it goes in the "More" overflow dropdown). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Stéphane Guillou (stragu) changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||0140 --- Comment #6 from Stéphane Guillou (stragu) --- (In reply to V Stuart Foote from comment #3) > Shuffling the current widget/group order based on available width seems like > a recipe for chaotic UI experience--better to keep the sequence static-- > tolerate the empty space on the MUFFIN NB. Even though some lower priority > widgets might fit. > Adjusting the intentionally lightweight MUFFIN NB framework to allow users > to set sequence and priority of exposed widgets could be a Customization > feature. Current customization is limited to expose/hide toggle per widget. Good point. Reordering is not ideal and could make things confusing. Customising the order would help, but reordering elements in the Customize dialog currently has no effect (see bug 140140). Regardless, the bad use of space remains an issue and I imagine looks like bad design to many. I strongly agree with Jeff that the default behaviour needs improving. So my current suggestion / summary would be to have a guideline like: - Tab sections should be less than X pixels in width; - If a tab section is more than X pixels, it needs to have an alternative view that can reduce it to below the limit. For the particular case of the Styles preview, we have mentioned two options for the alternative "low width" mode: - Jeff's suggestion: dropdown button to reveal the full preview - My suggestion: reduced number of columns Note that MS Office 365 (online) does _both_ of the above suggestions for its Styles widget: it will first reduce the number of columns, then convert it to a single button to pop down the full widget. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #5 from Jeff Fortin Tam --- Alternatively: When width is constrained, you could automatically show a simple compact styles insertion dropdown/menubutton instead of the styles preview rectangle (which _cannot_ be shown anyway, as you have seen, it's just... an empty space), i.e. show a button with a "▼" where you click it and it reveals a full-sized styles preview picker (which then also wouldn't be limited to this impractically small and scrolling-intensive rectangle space that the UI currently has) as a dropdown from that button. And then, when width becomes wide enough for the styles preview to show embedded in the toolbar, you can show it instead of the dropdown button. In any case, users shouldn't have to go dig by themselves into customization settings (and most users won't even _think_ about it, they will just see a big empty space on their toolbar on some laptop screens or window sizes, and not realize that there is more to be had), from a UX standpoint this should be handled automatically. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||0557 --- Comment #4 from V Stuart Foote --- (In reply to V Stuart Foote from comment #3) for example, Tools -> Customize -> Notebookbar and on the 'Home Tab' target simply toggle the 'Styles Preview' to not display. The following widgets/groups will fill in. Seems like enough for use on displays rendering at less than 1024px width. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 V Stuart Foote changed: What|Removed |Added Version|7.6.0.3 release |5.3.0.3 release Ever confirmed|1 |0 Status|NEW |UNCONFIRMED CC||vsfo...@libreoffice.org --- Comment #3 from V Stuart Foote --- The NB has a simple priority test based on available LO frame width, if a higher priority item fits it displays *in its sequence*, subsequent widgets are not evaluated and they all are available on the overflow exposure >> listbox. Shuffling the current widget/group order based on available width seems like a recipe for chaotic UI experience--better to keep the sequence static-- tolerate the empty space on the MUFFIN NB. Even though some lower priority widgets might fit. IMHO => WF Adjusting the intentionally lightweight MUFFIN NB framework to allow users to set sequence and priority of exposed widgets could be a Customization feature. Current customization is limited to expose/hide toggle per widget. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 --- Comment #2 from Stéphane Guillou (stragu) --- Created attachment 190398 --> https://bugs.documentfoundation.org/attachment.cgi?id=190398=edit screenshot of issue for Writer's Home tab (LO 24.2) Note that the empty space left by the Styles preview could fit the Table and Zoom sections _twice_. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Ever confirmed|0 |1 Whiteboard| QA:needsComment| Status|UNCONFIRMED |NEW --- Comment #1 from Stéphane Guillou (stragu) --- That's a good point, thanks Jeff! It does not make sense to have such a big empty space if those two last sections could fit in it. The logic would be: - width is reduced and is not enough for section - section is removed - check if next in line can fit - if not, repeat until last one But what should happen when the width is increased? Table and Zoom sections disappear to prioritise showing the Style previews? Or they are only pushed to the end once there is enough space to show the Styles preview? One related enhancement would be to reduce the number of columns in the Styles preview (3, then 2, then 1) according to space available. But this is not only about this Styles preview: the same issue can be seen in the Home tab for Draw, where the Area and Line formatting section is quite wide too. Tested with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fd69b546ad36452560cb11ccb28e78632d65f045 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are on the CC list for the bug.
