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: CLOSED FIXED
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: target:24.8.0
Keywords: bibisectRequest, regression
Depends on:
Blocks: Cell-Format-Dialog Vertical-Tab-dialogs
  Show dependency treegraph
 
Reported: 2024-05-12 03:04 UTC by ady
Modified: 2024-08-22 06:46 UTC (History)
9 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.
Comment 7 Commit Notification 2024-05-30 20:35:46 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7629d31f02a9fdbdf71295744c8869dee5cb4c54

tdf#161006 tdf#161049 tdf#161020 tdf#161047 fix VertTabCtrl size calculation

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 ady 2024-06-04 19:39:36 UTC
The cell format dialog UX is yet/still not better with this change.

With the new vertical tabs dialog:

* If no "latest tab" is yet remembered, then users have to select a specific tab instead of having "Numbers" pre-selected already.

* The tab _box list_ is too small (at least some of the tab names are not completely readable in the current width of the box; depending on language too), not size-able (customized size of the tab-box-list should also be remembered).

* The whole dialog does not remember its (customized) size either.

I don't want to open yet another "vertical tabs" report. Please consider this points as part of the next QA / Design / devs discussion about the vertical tabs topic (wherever and whenever it will occur).

Thank you,
Ady.

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 8501cb20627e5bc36d760b53b0990f4105c4ff65
Comment 9 lyly 2024-08-22 02:48:05 UTC Comment hidden (spam)
Comment 10 Buovjaga 2024-08-22 06:46:26 UTC
(In reply to ady from comment #8)
> The cell format dialog UX is yet/still not better with this change.
> 
> With the new vertical tabs dialog:
> 
> * If no "latest tab" is yet remembered, then users have to select a specific
> tab instead of having "Numbers" pre-selected already.

Created bug 162552

> * The tab _box list_ is too small (at least some of the tab names are not
> completely readable in the current width of the box; depending on language
> too), not size-able (customized size of the tab-box-list should also be
> remembered).

Added bug 161492 comment 5.
 
> * The whole dialog does not remember its (customized) size either.

Created bug 162553.