Bug 161049 - Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
Summary: Vertical Tab dialogs--Format Cells dialog in recent 24.8 alpha is too small
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Cell-Format-Dialog
  Show dependency treegraph
 
Reported: 2024-05-12 03:04 UTC by ady
Modified: 2024-05-17 15:12 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot macOS (150.61 KB, image/png)
2024-05-13 13:43 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ady 2024-05-12 03:04:11 UTC
I am seeing this on MS Windows with LO Dev 24.8 alpha built on 2024-05-11.

I have not tested other OSes.

STR:
1. Open new Calc.
2. [CTRL]+[1].

The Format Cells dialog opens, but it is too small (and unusable if not modified) compared to what it used to be up until a few days ago with 24.8 alpha (and older versions, including current Stable versions 7.6 and 24.2).

To be clear, it is not just smaller than before; it is too small, so for any practical usage I have to re-size the dialog, every single time.

The dialog should have the same default size as before, and, if a user wants to change its size, I guess the new size should rather be remembered. Both these things are failing on LO Dev 24.8 alpha built on 2024-05-11.

Let's focus this report on reverting the default size to what it used to be.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2b85bceca88ab119fff5cbdc41fe913435a479ca
CPU threads: 4; OS: Windows 10 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded
Comment 1 V Stuart Foote 2024-05-12 10:48:33 UTC
confirmed

20240510 TB77 nightly
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0ffdfb58a07e2a1b89a36bc241c6a2767e82cd2c
CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 2 ady 2024-05-12 12:14:23 UTC
I would guess that this is at least partially related to tdf#99528 comment 32, patch committed on 2024-05-06? IDK if needs to be bisected in order to confirm?

Not only the size of the dialog is too small, the width of the "vertical tabs" box seems to be too small too (so the text to select each "vertical tab" is not completely readable), and cannot be modified. No scroll bars in this "vertical tabs" box either (which is not necessarily the best way to solve it).

As a side note, is the UX team really sure that using "vertical tabs" in this Format Cells dialog is really saving screen usage?
Comment 3 Heiko Tietze 2024-05-13 13:43:01 UTC
Created attachment 194100 [details]
Screenshot macOS
Comment 4 Heiko Tietze 2024-05-13 13:46:03 UTC
Clicking a long text in the "vertical tabs" auto scrolls the list to the end but I cannot scroll manually back to left.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3eb427b31e624af9b2fe2bd68fee859d3d76a661
CPU threads: 8; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded
Comment 5 Heiko Tietze 2024-05-13 14:24:14 UTC
(In reply to Heiko Tietze from comment #4)
> Clicking a long text in the "vertical tabs" auto scrolls the list...
Reported in bug 161020
Comment 6 ady 2024-05-13 18:17:17 UTC
(In reply to Heiko Tietze from comment #4)
> Clicking a long text in the "vertical tabs" auto scrolls the list to the end
> but I cannot scroll manually back to left.

I can press once on the left-arrow. The right-arrow won't work at that point. If I move up or down, it immediately scrolls to the right again, each time.

The width of the box is too narrow and all this moving, even if it was allowed/possible, is completely unnecessary and distracting; also unnecessary requirements of extra actions from the user.

Additionally, when the UX Team will eventually "calculate" what the ideal default width of the "vertical tabs" box should be as default for future versions, I am sure that for some UI locales the width will be not enough whereas for others it will be too much.

ATM, I am not seeing the advantage of this new layout for this dialog. Whichever screen area you assume to be saving (which I seriously doubt for this dialog), it is not worth the extra clicks, distraction and lack of clarity for new users.

All this is important, but please first correct the whole default size of the dialog. Then allow the size to be remembered, and then consider the actual UX consequences of this new "vertical tabs" style for this dialog.

When the names of the "tabs" follow some (similar) pattern, a vertical column might be more efficient in terms of screen area. But when each name is so different as in this dialog (e.g a short word vs multiple words with many characters in each word), then the new "box" of vertical tabs will be occupying blank space that is wasted. Add the fact that a vertical list within a box is less clear for new users in terms of structural/tree steps...

This new "vertical tabs" style should had been experimental and opt-in, asking for beta testers to provide feedback and correct glitches (as this one, reported in this tdf#161049). If really "no one" would agree to opt-in, then that means that no one really wants the new style. If someone really wants it, then they would accept the opt-in. It is just a matter of promoting the opt-in alternative (e.g in the release notes). Instead, this is imposed/forced and with all these problems yet to be solved, with no alternative. I hope it is really, really worth it.