Bug 145739 - Revamp the Column tab of Table Properties dialog
Summary: Revamp the Column tab of Table Properties dialog
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.0 alpha1+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 159887 (view as bug list)
Depends on:
Blocks: Writer-Table-Properties-Dialog
  Show dependency treegraph
 
Reported: 2021-11-17 14:47 UTC by Eyal Rozenberg
Modified: 2024-10-19 17:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Current version of the Colum Width fialog (25.84 KB, image/png)
2021-11-17 14:47 UTC, Eyal Rozenberg
Details
Mockup (84.85 KB, image/png)
2022-04-11 13:02 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2021-11-17 14:47:31 UTC
Created attachment 176315 [details]
Current version of the Colum Width fialog

The current UI of the Column Width dialog of the Table Properties dialog is problematic:

1. It is not clear what "adapt table width" does from reading its label. One cannot guess apriori that, in itself, it does nothin. and is actually a modifier on the action of other controls. Also "adapt table width" - adapt it to what
maybe, something like "Change table width to track changes to column width settings".

2. The overall table size has no control in this dialog, not even a read-only display of the effects of other changes.

3. It is not clear what "adjust columns proportionally" does. When will columns be adjusted? What will change in proportion to what else? What proportional to what?

4. It is not clear what "remaining space" means. How does space "remain"? And what space is it which "remains?

5. The scrolling-among-individual-columns controls are idiosyncratic. They are also annoying, since you don't have a scroll bar among the lot of them; nor can you look one up by its index.

6. Pressing Tab when in the last currently-visible column -/+ box does not scroll one column further.
Comment 1 Heiko Tietze 2021-11-29 12:24:40 UTC
bug 129639 "Could Not Set Column Width in One Column Table"
bug 139096 and bug 139109 with the same issue pointing to bug 114633 "Setting unevenly distributed columns sizes is hard and cumbersome the achieve using Table properties or set width"
bug 116609 pointing to bug 113960 "Adapting table width by default"
bug 100537 "Width and relative checkboxes disabled in Table dialog by default with automatic alignment" (resolved NAB)

I suggest to have only one dialog for the UI redesign.

"Adjust table width" is not so unclear, admittedly with some ugly dependencies like discussed in bug 145738, and we could also argue to read the help.
Comment 2 Eyal Rozenberg 2021-11-30 22:23:03 UTC
(In reply to Heiko Tietze from comment #1)
> bug 129639 "Could Not Set Column Width in One Column Table"

That one is about the size change not working, it's not a complaint about the UI layout; plus it's about a different dialog (Table context menu | Size | Column Width).

> bug 139096 and bug 139109 with the same issue pointing to bug 114633
> "Setting unevenly distributed columns sizes is hard and cumbersome the
> achieve using Table properties or set width"

That (unclosed) bug it's not about the UI layout per se, but about the cascading effects of setting one column width on the others - which is not something I complained about here, although it is certainly frustrating and related to the UI choices.

> bug 116609 pointing to bug 113960 "Adapting table width by default"

No complaints about the size redistribution policy here. I'd say that's not even a related issue. Redistributing among the two neighbors is valid logic, and so is redistributing among all columns.

> bug 100537 "Width and relative checkboxes disabled in Table dialog by
> default with automatic alignment" (resolved NAB)

I didn't complain about that; my concerns are with the Column Widths dialog _only_.

> I suggest to have only one dialog for the UI redesign.

Do you mean "only one bugzilla bug"? Or do you mean the same dialog reachable from Table Properties and from the context menu?

> "Adjust table width" is not so unclear, admittedly with some ugly
> dependencies like discussed in bug 145738, 

You've misquoted the label text (which I interpret as another indication of the problem with this setting). It's labeled "_adapt_ table width". _adjust_ table width would be just as bad: You only adjust something with a value from a continuous range, or at least a choice among many settings, while this is a checkbox - a binary choice.

> and we could also argue to read the help.

You know that saying, "patriotism is the refuge of the scoundrel" :-P ... so, I'm not saying anything like that, but "read the help" is the refuge of the flawed UI... a decent UI is such that, for the common use-cases at least, almost nobody needs to consult the help, because what you need to do is just obvious.
Comment 3 Heiko Tietze 2021-12-02 14:02:45 UTC
The topic was on the agenda for the design meeting.

And while "Adapt table width" is clear enough given that we have a comprehensive help, there is room for improvements on the UI. So let's keep this one open for a UI redesign.
Comment 4 Regina Henschel 2021-12-11 21:19:20 UTC
ODF has the ability to use relative column widths
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420120_253892949

That is currently faulty in LibreOffice, see bug 109305. But it should be considered when improving the dialog.
Comment 5 Eyal Rozenberg 2021-12-11 22:38:37 UTC
(In reply to Regina Henschel from comment #4)
> ODF has the ability to use relative column widths
> https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/
> OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420120_253892949

Interesting :-)

Actually, it would be nice if one could specify column widths in one or several of:

* Arbitrary relative values
* Percentages

and that is relevant irrespective of what gets saved in the ODF.

Also, note that users may want to have relative widths for purposes of ease-of-editing, but not necessary for purposes of saving these values to the file. Or rather, _maybe_ users want to have this distinction, I'm not sure.
Comment 7 Heiko Tietze 2024-06-21 12:16:12 UTC
*** Bug 159887 has been marked as a duplicate of this bug. ***