Hi, this is Henk. I'm a product manager on the Confluence Editor team and we've recently started working on making table columns resizable! See the JIRA ticket here: https://jira.atlassian.com/browse/CONF-3393
We plan to introduce a new table "mode" with "Fixed Width Columns" and it will be possible to switch between the current, "Fluid Width Columns" mode and the new mode.
One question we've been wondering about: Would you prefer new tables to be created as:
We'd greatly appreciate your feedback.
Henk Kleynhans | Senior PM - Confluence
I'd prefer a default of fluid, because it works fine for most of the stuff I write. The ability to do fixed width would be very welcome for the times when fluid doesn't work for me, but that's maybe 20% of my tables at most. I think the main reason for choosing fluid is that I don't want to have to think about column widths most of the time - I'd rather not default to having to adjust my columns for 80% of the tables I write.
If fluid means that the column won't wrap until I tell it too, then that's fine. I find that almost every new table currently creates the problem of wrapping things that I don't want wrapped, due to the page width. I would prefer to choose which columns wrap and at what width. This is especially true with the many small tables that I tend to create or maintain regarding contact information, financial figures, etc.
I would prefer the width to be fluid at time of creation, but stay fixed at time of edit.
Fluid is the entire issue with tables right now - there seems to be no rhyme or reason as to how they auto-resize meaning I have columns in some of my tables that are 3 words wide and 20 rows long which is awful to read and makes the page unduly long. I'm shocked to see everyone saying "fluid" as this has been the issue on the JIRA ticket all along.
If "fluid" is the default, there must be the option to resize by clicking/dragging cell borders.
I understand where you are coming from but my thinking is that it would be best to have it fluid while you are adding info to the table and then be able to specify the widths once the table is populated. Having to specify fixed widths at the start when the table is created will just add an extra step as the widths are bound to need adjusting after you have populated the table.
Fluid as default would be preferable for most users, as usability will continue "as is" and extra format option is introduced for those who actually need it.
Resize feature is needed, but only in some cases. For most of the time current Confluence way to handle it is good enough.
I wonder whether it is necessary to have 2 modes and allows switching mode.
As I see, "Fluid" is what we have in MS Word. and "Fixed" is being in Google Drive (if I remember correctly). However, from developer's point of view, I think it would be better with "Fixed" mode and "wrap" or "pre-wrap" whitespace. "Fluid" mode will give us more table's behaviors to take into account and make the UI a bit unstable and things will get more complicated when we have more features. One question should be "is it worth to do that?".
Since customers like to have more control and so do I. I vote for "Fixed" mode, simple and sufficient.
I also agree with previous posters that we should have a min/fixed/max width options. %'s would be great, but the min/max/fixed options along with never breaking in the middle of non-whitespace would cover all my needs I would think.
I like fluid as default as well. When a table is being quickly produced its just one less thing to think about. And in many cases, speed (for default options) is king.
That being said... we have a large Confluence implementation touched by thousands of users and its when a table is in a space open to all of our employees that the refinement of fixed width columns would be most welcomed. Looking forward to this being implemented.
Also, liked the idea of posting this question out on Answers as we're all not necessarily plugged in to feature requests that we have interest in. This new table feature will be most welcomed!
An additional comment from one of my 'power' Confluence users, is a request to add a table property to suppress the table border display. This is helpful when one of the 'Page Layout' options does not quite fit a preferred layout requiring say 3 columns of differing widths or more than 3 columns. A table with defined widths could fill in, but having borders could get in the way.
I would prefer the fluid mode as default. But this depends on how the fixed mode will be implemented. If the fixed mode will be implemented using absolute values then i definitely vote for the fluid mode. If the fixed mode values are relativ then i say, i don't care as long as it works.
I vote for "fluid" staying the default behavior. We definitely need option to set width (in some cases px, others %) for some of the columns, however, majority of tables don't need these explicit settings, so it would be great to have ability to set target width as an option but not as a rule.
I would vote for fluid as the default. I'd also vote for three options on the column: %, fixed, and none as options.
Story: As a table creator, I would like to be able to fix the width of one or more initial columns that I do not want to wrap, and reserve all remaining space for a final column so that I can create key-value style definition tables where the key(s) never wrap and the values column uses as much space as possible.
I also vote for "fluid" by default since this is what people are used to and it works for the majority of tables.
Regarding "fixed" mode, could you clarify if the resizing options mentioned (dragging column borders) are available in edit mode only or can people viewing the page also resize the columns to work for them? Changes in view mode would not affect what others see, but could be stored for that person or for that browser session.
Another question about "fixed" - do you plan to provide some sort of page sizing options (sort of like page view in Word) or a ruler of some sort? If you are trying to make a table that is formatted nicely for printing, this would be handy.
For me, a percentage mode (not typing in a percentage which is awkward, but dragging as described) would be quite handy in terms of having the table adapt to different screen sizes while still maintaining a nice ratio between column sizes. So the table would work much like fluid mode, but the ratio between columns would be adjustable. Presumably in fixed mode the table maintains a fixed size and side scrolling must be used to see all columns on smaller screens.
I do not like idea of 2 table types. It's too complicated for such simple thing as table. Maybe we can have one table type that behaves as fluid and fixed: - After adding all columns are fluid. - when I drag a border column at left becomes "Fixed" and all other are still fluid. googled and looks like it's supported by css: http://stackoverflow.com/questions/12641104/css-table-columns-width-fixed-dynamic30-dynamic70-fixed
@Volodymyr Krupach Speaking from a non-technical point of view, I was making the assumption when adding my own opinion below that default should be fluid (because it's the fastest option for informal, smaller tables), that changing it to fixed (perhaps better for more information-rich tables accessed by more users where more display refinement would be optimal) would be a relatively simple and seamless process. It must be easy and intuitive to be able to 'change states' between fluid and fixed in my view, perhaps via context-sensitive menu choices
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Hi Community, Jessica here from the Confluence Product Marketing team! July’s community challenge is all about sharing pictures — and as an extension of our first post on what ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs