Configuring tables is an every day task for word processors. Most users likely insert a table via menu or toolbar and size the columns per mouse. This usually wont result in a satisfying precision and the table properties dialog would be the next step. But here the problems begin for real since using a certain width for all columns is not possible unless the “Adapt table width” is checked, which requires to change the “Automatic” alignment on a different tab to something else.
This workflow is hard to understand and results in many complaints like “Setting unevenly distributed column width is hard & cumbersome” (tdf#114633), “Revamp the Column tab of Table Properties dialog” (tdf#145739), “Table Alignment options are somewhat confusing” (tdf#145980), “Columns tab of Table Properties dialog doesn’t allow setting width of all columns to same value” (tdf#145738) and enhancement ideas such as “Adapting table width by default” (tdf#113960), “Adjust columns proportionally should/could be supported with visual accolade (lock)” (tdf#142588), or “Add ‘Row’ tab to Table Properties dialog” (tdf#104443).
A user story is an informal, natural language description of features of a software system to describe the requirements. While the examples use concrete values it rather illustrates what use case the UI needs to cover.
Benjamin wants a table with 5 equally sized columns to fills the total page width.
Benjamin wants a table with 5 columns and 5 rows having exactly 1 cm width and height to draw a floor plan.
Benjamin wants a table with 4 columns having an exact width of 1 cm at the middle and otherwise filling the remaining space to show small images next to text.
Benjamin wants a table with 3 columns to have 10%, 30%, and 60% width.
- Benjamin wants to add/delete columns to a table and keep some columns at the same size while other should fill the remaining space.
We started the mockup with the axiom to have attributes on the same page that belong to each other. In other words, the goal is to merge the current two tabs into one.
The dialog starts with basic information such as name, alignment, and spacing. We removed the option “From Left” from the list of alignments and renamed the “Automatic” option to “Justified (Full Size)”. Since languages may run from left to right (LTR) or right to left (RTL) the start can be at the left side or at the right. On the other hand, just calling it “From Start”, without “Left” in case of LTR, might be confusing for people who are unfamiliar with this duality.
The new workflow begins with “Column” (and “Row” next to it, which works the same). As of today, the total width is locked depending on the alignment (which is now clearly shown by a static text). The control look like disabled in the mockup but should be read-only in the implementation. The columns are arranged vertically in a scrollwindow. The checkbox Equal width allows to set all by one, the lock next to each column to make this value fix- changes apply only to other columns.
Some questions needs to be addressed:
- What happens when the total size is fix and the user changes Col A?
The maximum is clearly defined by the total width divided by the number of columns, respectively the sum of the widths. Reducing the value adds the remaining size to the next column in case of full-size tables – or shrinks the table in other alignments (as today). However, if the next column is locked, the second next will be used, etc. In case all columns are locked the value cannot change (minimum = maximum). With “Equal width” being checked, the remaining width is distributed equally to the columns that haven’t been locked.
As alternative solution we pondered over is a ‘slack’ option. Remaining values fill a buffer, shown right of the total width, and the dialog cannot be closed until this buffer is zeroed. The advantage is to have a cleaner UI as the locks add some noise to the design. Since changing a value always increases or decreases the buffer first, the locks are pointless here. On the other hand, having a buffer is also not a very common design and affects the learning curve.
- How about the relative sizes?
It will be used for both, the total size as well as the column width and row height. If the total paragraph width is 17 cm, and the table is centered with 2 cm spacing left and right, the total table width of 13 cm is 76% (as today). The percentage of column widths adds up to 100%.
- What happens when the size cannot be distributed equally with the necessary precision?
We discussed this rounding issue and a potential solution is to use fractions, at least in the UI, like 1/3 for 33%. But the precision would be another issue and we suggest to accept one column to be 34% for now in case of relative values or to have a few millimetres off when distributing absolute values equally.
- What happens to the columns when adding / removing one?
In the current implementation, adding a column squeezes it in rather than expanding the table. And the optimal column width is also a one-shot function. The idea of the reworked design is to have more freedom in the configuration. If columns are locked, it should keep its size as best as possible (adding a column to a table with all columns locked still needs to work), having chosen an equal distribution should affect the table also after modifications.
What do you think about this modification?
PS: Special thanks to Eyal Rozenberg for working on this proposal.