Anyone still frustrated with Table-Next?

  • 27 January 2021
  • 6 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?!

6 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) )