Loving the new version! Love tables!
A question — is the current way table width is handled expected to stay? I have a table with two columns and entered a load of text, which makes each column wider. The overall width of the table isn’t capped, so you have a “sliding” table view in the app. I know Dropbox Paper had allowed for that, and I think GitHub does the same. That said, Paper added a feature to force a max-width on tables and allow manual manipulation of column widths via various means (all of which were handy):
- Allow users to click-and-drag on any columns right-divider and manually make it narrower and, by doing so, have the width of the table get narrower and into window focus.
- Have a single button that has the table be no wider than the max width of the current window. (No side-scrolling allowed at all.) In this case, table columns narrow automatically. Users via Option 1 can make individual columns wider, as needed, for viewing.
All of these are handy. The current Panda default will have a lot of table viewing require side-scrolling by default, which makes reading longer table data hard.
NOTE: FWIW, Dropbox Paper’s table handling is best-in-class from an editor, IMHO. Didn’t start out that way, but over time they’ve added a feature set that is damned easy to use. Two more recent features they included were table sorting (based on the header row) and, more importantly, the ability to re-order rows, which is wildly useful when table row length gets high. Having to think about the order of row items as you’re just cranking out data is a problem — allowing the re-ordering of data afterwards removes the need to worry about it during original entry (very handy and Bear-like).
In the image below, you can see text in two columns I have, which kicks in the mandatory side-scrolling requirement. In the example below, you wouldn’t know if there are more than two columns without side-scrolling (obfuscation of data isn’t good).
