Cloud Editor table deficiencies

[David Smith]

With the impending forced migration to the new cloud editor, I'd like to comment on what I perceive as some missing features/undesirable behaviour compared to the legacy editor.

1. There doesn't seem to be a mechanism to define multiple header rows on a table.  Pages converted from the legacy editor that originally had multiple header rows seem to keep them, although I'm not convinced that  cell merging is preserved properly:

2. In the legacy editor, column widths were automatically sized based on the contents of the cells, so that the tables were no wider than necessary.  In the cloud editor, tables are automatically full-width even if there's very little in the cells, which makes the tables harder to read.  They can be resized manually, but this is quite a clunky process (especially since the editor seems to want to keep the table full width even if the columns are not equally spaced), and this manual resizing needs to be re-done if the cell contents change.

[John Morales]

I absolutely agree, we recently migrate from Confluence DC to Confluence Cloud and the user experience has been awful !!! The transition has not been a good user experience with major gaps within the Cloud Editor, lots of deprecated Confluence Macros with no automated path forward. We have many Confluence users now transitioning their contents to Microsoft SharePoint. We may even consider exploring options and solution to convert our Confluence Pages to Microsoft SharePoint.

[Robert Eiser]

Thank you for opening this post, it is a very important subject.

I would also like to see column width auto resizing restored - ideally the column width would fit the contents of the cells up to the max width of the page, then start wrapping the text.

[emanuel_m_fernandes]

The column widths is something that everyone has been complaining. Why would we want a table with very few text inside to use the entire length of text!? I would like to understand why this makes sense in the head of the Atlassian design/product team — my core belief is that they want everything to align perfectly as they have designed with perfect content. But the reality is that many times, we want tables to have different widths according to relevance or amount of information.

Someone should open an issue about this... 

Let's hope that someone with common sense from Atlassian can read this and actually do something to fix it.

[David Smith]

The thing is, it used to work just fine.

"Just do what the Legacy editor did", even if it's just a selectable option like "fixed column widths", would be fine.

[S_ Francoeur]

So true!

We can no longer designate multiple rows/columns as headers, let alone arbitrary ones (very useful to define sub-sections). As a result, rows/columns designated as headers in the legacy editors are no longer when converted to the new editor and, if the table originally had numbered rows/columns, these previously unnumbered headers are now numbered...

[Anna Mitina _Stiltsoft_]

I totally understand your frustration with the new editor. And I believe Confluence users should speak up about these issues.

The column width can be fixed if you have the Table Filter, Charts & Spreadsheets for Confluence app. Not trying to sell anything to you now, but rather wanted to mention it in case you already have the app.

Namely, you could either change the table column width to the one you desire with a simple SQL query or, if you like working with Excel, you can insert whole spreadsheets on your Confluence pages and adjust them to your liking.

Anyway, hopefully raising these questions will lead to certain changes within the Cloud editor, so thank you.

[Frank Kulla]

That was something i immediately realized after we migrated to Confluence Cloud, and i don't like the Cloud behaviour.

Though you still can manually shrink the columns after you created the table - still it's some more (unnecessary) clicks you have to do with every table you create...

[emanuel_m_fernandes]

That's exactly the point — you get by default a behaviour that will make you click more times, which is the opposite of what you want to get from a professional tool. I understand bringing a tool to modern times with a redesign, but the core interaction and defaults must be well thought so that it can actually bring some value to customers. 

Very likely this is the result of thinking only of the last marginal user and ignoring the current base of customers. They want to acquire Notion, Slab and other tool's customers, and as such, they build the tool around those type of users and ignore the existing ones, to justify growth in the user base. But if the existing users leave more than newcomers arrive, the net subs will decrease, which is the opposite of this entire endeavour of Atlassian.