Anyone still frustrated with Table-Next?

  • 27 January 2021
  • 8 replies


I’m curious if we’re the only ones that find Table-Next to be endlessly frustrating and constantly revert back to Table Legacy? My whole team feels the same way and most dashboards still use legacy tables as a result.


I think the biggest gripe has to do with column sizing and column names. It always does something wacky and never works the way you’d expect. If you spend the time resizing columns it usually reverts or changes shortly after. Table Legacy does a really nice job of fitting everything within the allotted width without awkwardly sized headers or rows. Even after a lot of config options it ends up weirdly displayed. 


I like a lot of the options in Table-Next like the ability to resize columns, move columns, add embedded bar charting, but the user experience feels a lot worse for our end-users and we never know how it will render on different monitors/browsers.


Am I missing something?!

8 replies

Userlevel 6

@sc0tt I am with you on this.


I can’t quite comprehend the logic used to manage column width in table-next visualisations I think the logic/engine is different, which is bizarre since the old style worked perfectly well..

Userlevel 1

I share this concern:

  1. Agree regarding table-next sizing/formatting, which is very rigid and unintuitive.
  2. While I like the Filter UX, the filters on dashboard next take forever to load/format.
  3. While I realize that Looker’s in-memory approach limits pivot/slicer functionality, it is far behind peer BI tools in this regard, and this is an important use case for exploration.
  4. Rate of change for formatting/bug fixes has been slow, the past ~10 releases.

Tables/pivots/dashboards in shared dashboards are the “backbone” of our enterprise BI instance, &  all available options (Legacy, Next, 3P Marketplace) have limited functionality and/or UI/UX gaps.

I like some of the new features conceptually (cross-filters, 3P marketplace), but would rather see Looker invest in refining the core features, since they are so imperative to user’s daily experience.


Userlevel 6

Now, all of the sudden I just get empty space at the end of the table ..  but surprisingly I changed it to Table Legacy and it’s the same so it must be something with the “next” dashboards

Thank you all for your comments and feedback! I’m the product manager for our dashboard experience and some of our visualizations (like Tables). This sprint we are actively engaging with our design team to improve some of these underlying issues with our tables and hope that in the near future they will be great to work with. 

We are not investing more time in our legacy tables as we hope that these fixes will remove the need for the legacy tables. Would love to hear if (other than the column resizing issues) if there are other use cases where you and your team switch back to legacy tables.

Userlevel 6

For me the default is Table-Legacy unless I need a feature from the Table-Next that doesn’t exist in the Legacy. Those would be

  1. Transposition - used few times mostly to replicate the look of financial spreadsheets, even though Transpose function does not honour the order of columns (in the vis layer when a table calculation is moved for example)
  2. Formatting - if I need better text formatting bold/colours/italic

Because of the formatting issues: field names, column width, cell visualisation enabled by default (the mini bar charts), I don’t mind using Legacy. I hope that will change after the release that contains the work your Team is doing this sprint @Katie_Gillespie 


@Katie_Gillespie  Some requests:

  • Option to disable comment on column hover
  • Option to set minimum width for a column or other functionality to enable more usable tables on mobile, and responsive tables that work on both mobile and desktop with horizontal scroll and non-scrunched up column widths when width would not support desired min-widths, yet keeping the table truncated (without truncating or line splitting any text).
  • Option to remove sub-total row count from the parent dimension (e.g., Date (3) )

While I am always overly optimistic about the improvements that the Looker team product, overall formatting is a huge issue for everyone from senior leadership to analysts since moving over to the dashboard-next as default. I have had to revert several dashboards immediately after formatting for the tables rendered gaining any value impossible. 


The columns widths do not appropriately wrap the content like the legacy tables do and no mater the amount of effort spent to auto size or fit columns it does not work. Additionally, what might look “good” on one computer certainly does not mean it will on another. On mobile it is also completely useless to get any data results. 


The “legacy” tables do not render at all in the new dashboards, they essentially are converted to the table-next design with more limitations. If a table has say 2-3 columns than this works, but for others that might need to render 5 columns that work perfectly in the legacy table, they fail to be of any use in the new design. 


This feedback was communicated several times during the beta phase of the dashboard-next but I have yet to see any major improvement in this area. At present this is legit reason why other employees are looking at other business intelligence tools to use instead of Looker because they think the table design is horrible. I am a huge supporter of Looker but this really is a major weakness of the current product and I urge there to be serious evaluation of its competitive advantage over the legacy view. 

Here's an example of what we’re up against (not even the worst I’ve seen):

I realize it’s a bunch of columns, but this should just horizontally scroll if it’s going to look this bad.