Particularly on laptop screens or in windowed mode, the notebookbar (and groupedbarcompact, I think) toolbar UI has some limitations when it comes to space optimization when hiding/revealing sections. For example, in Writer, the "Styles Preview" section is very wide, and blocks the display of subsequent "Table" and "Zoom" sections, even though there would be plenty of space to display those. This is a demonstration of the problem: https://youtu.be/5SiVEOhYqrQ --- Tested with version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: fr-CA (en_CA.UTF-8); UI: en-US Flatpak ...but it happened in every previous version that shipped notebookbar UIs, too.
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
Created attachment 190398 [details] 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_.
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.
(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.
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.
(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.
(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).
(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
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
(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.
Created attachment 190566 [details] 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…
(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.
> 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 :)
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.