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.
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.
(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.
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.
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.
(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.
Created attachment 179458 [details] Mockup Discussion for this mockup at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/
*** Bug 159887 has been marked as a duplicate of this bug. ***
I stumbled on this bugreport today (GSoC ideas Heiko). I only want to mention that I dislike the arrangement in the current mock-up A) The table width should be below the table name (as currently). The center table setting is "overruled" by table width. There is not much to center if the table width being set to 100%. At least in my perception. B) The absolute/relative gets way to much focus and appears to be detached from which inputfields being affected. So expected more: width. In in the same line: absolute/relative C) Regarding to column width: is only absolute allowed or maybe also relative sizes? Yes, this makes internals more complicated (and no clue about file format support) (especially rounding). However it would be nice to say the distribution for 3 column table to be : 25%, 25%, 50%. If I adapt change the table width, wider/smaller it adapts D) The part Left/Right between round brackets after From Start/From End appears to defying the purpose of using 'Start' and 'End', I think. Locale depend mouse-over tooltip appears to be a better fix, I guess? E) Is Left/Right for spacing correct label for RTL language; so rather neutral?
(In reply to Telesto from comment #8) > A) The table width should be below the table name (as currently). The default alignment option sets the table width at 100% of the parent. Before you configure anything about the width you need to change the alignment. Second argument to move the total width down is to have it together with the column widths. > B) The absolute/relative gets way to much focus... Which again defines what you enter: either a width of 50% of the page size with 25% spacing left and right, if alignment is Center, and column width at 10%. Such a table definition might become handy when changing the page orientation. > C) Regarding to column width: is only absolute allowed or maybe also > relative sizes? The idea would be to set column width in percent in case of a "(o) Relative" position/size, of course. > D) The part Left/Right between round brackets after From Start/From End > appears to defying the purpose of using 'Start' and 'End', I think. > E) Is Left/Right for spacing correct label for RTL language; so rather > neutral? A while ago we considered this "Start (Left)" vs "Start (Right)" annotation for users who might struggle with Start when looking for left alignment. I think this has been rejected meanwhile and we go with just Start/End. As for the spacing I'd keep Left and Right but no strong opinion here.
(In reply to Heiko Tietze from comment #9) > (In reply to Telesto from comment #8) > > A) The table width should be below the table name (as currently). > The default alignment option sets the table width at 100% of the parent. > Before you configure anything about the width you need to change the > alignment. > Second argument to move the total width down is to have it together with the > column widths. That's indeed a valid point. > > B) The absolute/relative gets way to much focus... > Which again defines what you enter: either a width of 50% of the page size > with 25% spacing left and right, if alignment is Center, and column width at > 10%. Such a table definition might become handy when changing the page > orientation. I'm still feels wrong, somehow. Although I can't really pinpoint what bothers me. It's a 'trivial' setting regarding input unit in my perception. It's not actual table property. It's presented as a prominent able setting, IMHO. I'm not having an alternative, though. The only thing I can come up with is how certain input fields behave. Default being absolute. However allowing different input. Although 'converting' it like by fontsize input field. So 10cm being converted to points. But simply allowing % input. But yes, this is quite bad for discoverability. It shouldn't be required to read the help/or manual > > C) Regarding to column width: is only absolute allowed or maybe also > > relative sizes? > The idea would be to set column width in percent in case of a "(o) Relative" > position/size, of course. OK. I personally prefer the ability mix of absolute and relative. So not all absolute or relative. Like table width being defined absolute & column size relative. > > D) The part Left/Right between round brackets after From Start/From End > > appears to defying the purpose of using 'Start' and 'End', I think. > > E) Is Left/Right for spacing correct label for RTL language; so rather > > neutral? > > A while ago we considered this "Start (Left)" vs "Start (Right)" annotation > for users who might struggle with Start when looking for left alignment. I surely grasp the motivation. I'm also not familiar with start/end > I think this has been rejected meanwhile and we go with just Start/End. As for > the spacing I'd keep Left and Right but no strong opinion here. I have no actual knowledge about RTL. I'm happy with it as LTR user..
(In reply to Telesto from comment #10) > > > B) The absolute/relative gets way to much focus... > I'm still feels wrong, somehow. An alternative could be to make it a "hidden gem" like at hierarchical style where you enter a value in percent to change the logic (it's not only the value being 12pt and now 80%, for example, but the fact that with percent the factual value alters if the parent changes). Meaning: you enter on the table width 100% (after changing the alignment) and the column width fields become percent too. I agree that this option has a very prominent place. But it should be much more self-explanatory than this current checkbox.
(In reply to Heiko Tietze from comment #11) > (In reply to Telesto from comment #10) > > > > B) The absolute/relative gets way to much focus... > > I'm still feels wrong, somehow. > An alternative could be to make it a "hidden gem" like at hierarchical style > where you enter a value in percent to change the logic (it's not only the > value being 12pt and now 80%, for example, but the fact that with percent > the factual value alters if the parent changes). Meaning: you enter on the > table width 100% (after changing the alignment) and the column width fields > become percent too. A well, that's the example I was looking for! I'm personally in favour this implementation compared to explicit setting. It's a lot cleaner
Another two points A) Is there a reason to align the preview (with caption) with Alignment and spacing? I tend to position the preview in the right corner (for unknown reason). So 'Preview' label aligned with "Name". Maybe also increasing the preview size little B) The column width is now a bottom down list. Advantage: easy to read (top/down). Efficient dialog usage and nicer optics. Downside: requires it uses more mental mapping energy 'convert' top down list to columns. A horizontal aligned spinboxes functions as visually assistance: represents columns A proposal to mitigate the effect: if you enter a column spinbox: highlight the column in the preview. Assuming the preview being representation of the table. Although not sure what should happen if the page is landscape. It can actually fit way more columns compared what can decently shown in a portrait preview. So or it should adapt the situation; so if page being landscape, preview being landscape.. Or preview should move view with the scrollbar covering the list of columns. Or even something else..
(In reply to Telesto from comment #13) > A) Is there a reason to align the preview (with caption) with Alignment and > spacing? Don't remember. No strong opinion to not align it with the Name. > B) The column width is now a bottom down list. Cannot follow you. The proposal is a scroll window of spin buttons along with locks similar to what we have today but vertically as the to be added row height thingy. > if you enter a column spinbox: highlight the column in the preview. Sounds fancy. Somewhat challenging for the preview but manageable I guess.
(In reply to Heiko Tietze from comment #14) > > B) The column width is now a bottom down list. > Cannot follow you. The proposal is a scroll window of spin buttons along > with locks similar to what we have today but vertically as the to be added > row height thingy. That's what I meant. Column width spinboxes are currently horizontally aligned, after the change it becomes vertical list. The current - horizontal alignment - has the advantage of being spatially arranged the same way as the table columns. So third spinbox field in horizontal list is column C (or in my way: the third column seen from LTR). A)I find it counterintuitive/ less natural to associate a vertical list with table columns. I need to spend mental effort to spatially mapping the third item in a list to horizontal column C. B) My mental image of the table columns mapped horizontally. So I'm constantly transposing. Whereas I want to focus my mental energy on what I want to put into that column & required with to fit the content and not on transposing stuff That's why I'm suggesting highlighting the column as a compromise.