Who uses LookML dashboards?


(Andrew Kraemer) #1


I’m having a discussion with myself that I decided to open up to the community. Four questions have been on my mind:

  • How many of you actively use LookML dashboards?
  • Do your users get confused when they are dealing with LookML dashboards vs User defined dashboards?
  • Is it time consuming to recreate a User defined dashboard as a LookML dashboard?
  • Are LookML Dashboards part of Looker’s roadmap? I’m curious because they seem to still use old lookML.

Where I’m coming from:
Since I started using looker, my team has always used looker defined dashboards. It’s GUI and easy. However, I’ve been caught in a situation a few times where I end up updating a dozen looks in a dashboard, which ends up taking a long time & doesn’t have a lot of transparency.
There are some situations where I’m thinking it would be easier to just have a LookML dashboard, so I can quickly make updates via code rather than manually updating Looks, but I don’t have enough experience with Dashboard LookML to know if that will end up being even more time consuming.

Just looking for thoughts from large-brained people.

(Sam Wilson) #2

I’d really like to be able to use LookML Dashboards because they are under source control and can be versioned with my model, and because when I make changes, anything I’ve broken will be found by the validator.

The big drawback is that the Newspaper layout is only available with user dashboards, and all our dashboards are designed using it.

The layouts available for the LookML dashboards are either limited or completely broken and unusable. The tile layout is probably only good for very basic dashboards and the grid layout doesn’t offer row/column spanning (which would make it a workable replacement for the Newspaper layout).

The static layout makes it sound like you can achieve similar effects as the Newspaper layout, the problem is it’s is both broken and static. Broken in that, unless you specify the top, left, height and width for every element, they will render as a jumbled mess. So you literally have to hard-code the whole thing. Except that the margins/padding are all broken, and there’s no way to say “Make the left most element 300px wide, and the right most element can consume the rest of the width”, so you have to have fixed-width layouts.

Like I said, I’d love to use the LookML Dashboards, but they feel like a completely abandoned and half-implemented feature.

(Sam Wilson) #3

I’d also like to add that another benefit of the LookML dashboards is that you can actually demo the changes you make in your models in development mode. With user-defined dashboards, you basically have to break all your dashboards either until you publish, or after you publish until you’ve updated them all.

(Dirty Looker) #4

Hey @Sam_Wilson,

We are very aware of these issues and have some plans to consolidate the world between LookML dashboards and User Dashboards.

Unfortunately, in today’s world, the cadence between rolling features out between these two dashboard types have been staggered and we definitely want to move towards a universalized world where both share the same features and functionality in terms of layout, organization, and editing. We also know the value of storing the dashboards as files for source control and migrating content between Looker instances.

We’re actively working on this so please stay tuned or if you have any questions reach out to your account manager so we can update you as progress is made on this front. We’re not abandoning LookML dashboards!

(Richard) #5

For what it’s worth we’ve completely abandoned LookML dashboards and have made everything the responsibility of the user. I’ll admit this is at least partly motivated by my own laziness, but we don’t miss them, not really.

(Sam Wilson) #6

Glad to hear you are working on it. This was seen as a key value proposition for me with Looker.

I definitely like having both options. We offer a baseline set of dashboards, and also want to support user-generated content, and appreciate the GUI/ease-of-use with developing the non-LookML Dashboards.

If there’s an issue tracker where I can up-vote something like this and track progress, that would be nice as well.

(sam) #7

Hey @Sam_Wilson - discourse is our public-facing issue tracker. There’s a Feature Requests section that you can use when leaving upvotes and +1s - and we do watch those seriously.

In this case, LookML dashboard work entails a lot of individual issues! If there’s something particular you’d like, upvote or create an article within the Feature Requests section and we’ll make sure it gets seen by the right people.

(Sam Wilson) #8

Thanks! I’ll do that.

(Alex Hancock) #9

The way I see it, user dashboards should be as fully configurable as LookML dashboards and have the option to save down to LookML for Git versioning. Some dashboards become business critical and should have a PR process associated with them.

(sam) #10

We got a feature request for that @Alex_Hancock - would love your feedback here: https://discourse.looker.com/t/get-dashboard-lookml/991

(Jay Stricks) #11

We use Looker as an embedded BI tool, so we use LookML dashboards almost exclusively at the moment for three reasons:

  1. Version control
  2. The ability to use an actual release cycle and github pull requests
  3. the “extend” parameter, which allows us to make base templates and derived dashboards from them, which dramatically simplifies the process of propagating changes across dashboards.

(John Toups) #12

We also use LookML Dashboards extensively, though, only for embedding. I have no issues with the layout per se, though I would be very interested in improvements.

(Andrew Kohlhoff) #13

LookML have the benefits you list, and I would rather author dashboards via LookML. And, I need to use them, because I’m usually prototyping a dashboard that will then be modified programmatically, and then this is pushed out into multiple projects.

However, as well as the confusion for end users that you mention, I think it’s worth considering whether you’ll be let down by the content management and discovery of LookML dashboards. I would argue that content management and discovery of LookML dashboards is so bad in Looker that you would be well advised to stay away from them if you can. After all, getting the content you develop used in your organisation and useful for other people is probably the point of doing it.

Here are my thoughts on why you would not use them.

The main discovery issues:

  • LookML dashboards are listed separately from all the other content in Looker, i.e. undiscoverable through Spaces.
  • LookML dashboards are presented via their own separate page, and on this page the Looker user is presented with an unfiltered list sorted alphabetically regardless of what Model they belong to. In my case this list is 1000 rows long.
  • In the Search Results, LookML dashboards are not listed in the Dashboards section. Instead they are in the 3rd set of search results like some kind of outcasts.

Other discovery issues:

  • LookML dashboards do not appear in the Top Content list.
  • Lookml dashboards cannot be made as Favorites.
  • LookML dashboards do not show up as Recently Viewed content.
  • The dropdown navigation box (top left) on a LookML dashboards links the user to every single other LookML dashboard. In my case I get a dropdown list of 1000 links.
  • LookML Dashboards are named like something that only people with developer mode should be seeing it. Most end users of Looker will never edit (or know of) LookML so why use such an esoteric name as their label? Personally, I would label them Curated Dashboards. (Well actually I’d just rather label them Dashboards and have them with the rest of the Looker content.)

Plus, they’re missing from Usage reporting, so you can’t really tell is they’re used or not. You’ll have to know what Explores are being used within them and work back from that.

Regarding the LookML dashboard roadmap:
I was told in 2014 that better organisation of LookML dashboards was coming, but actually since then the organisation of them has gotten worse - the long LookML Dashboard list used to be filterable.
So while I’m sure better support for LookML dashboards is on a roadmap I’m guessing it’s a fairly low priority and not something one should rely upon.

(Timothy Burke) #14

I think this is really important. @Andrew_Kraemer thanks for starting the conversation and @sam, @mikhailxu please let me know where to vote to prioritize this consolidation!

The BI team in my organization owns the data analysis stack, including our EL and ETL tasks, database maintenance, and Looker modeling, and we are also the biggest users of Looker; answering questions directly and sharing the results via links, curating content in the form of dashboards, and helping other users answer their own questions by pointing them in the right direction.

A previous analysis / reporting tool used in our organization had gotten messy because all users were allowed to save and publish content, and there wasn’t much centralized governance in terms of naming conventions, ownership/maintenance of content, and discovery/organization of content (the result of a lack of planning, also an inferior tool).

Given that experience, we wanted to tread lightly when we introduced Looker, and put a lot of thought into how content would be curated / presented. I just posted on a different thread a little about our model development pattern, and given that underlying Looker project organization and our prior experience, we are leaning towards exclusively developing LookML Dashboards.


  • Dashboards are guaranteed to be consistent across models (because there is only one place where the elements are coded)
  • Dashboards are validated
  • Source control allows us to go back if we break something


  • Content discovery / Favorites / Spaces are unusable (not the end of the world with limited content; we may add our own simple directory of dashboards)
  • Some confusion around what model is being referenced, since the dashboard title is the same across all models (we are investigating using extends to address this)
  • Balancing act between being a bottleneck and doing responsible platform governance.

LookML Dashboards don't work with Spaces
How to add image from my location in the dashboard
RETIRED: Experimental Feature: Setting Up Merged Results
(sam) #15

Looks like you found the right place - LookML Dashboards don't work with Spaces would be the most apt feature request for consolidation of LookML and User-Defined Dashboards.

(Mark Gorman) #16

I would echo Jay Stricks above… we use LookML Dashboards for embedding, and we rely on the ability to version control dashboards as part of our deployment process. The fact that the validator runs against LookML Dashboards is a huge benefit when I’m changing a model.

(Matt McGlothlin) #17

The UI differences between user-generated dashboards and LookML dashboards is an issue for my organization. We are making UI changes in the user-generated dashboards and then finding that the newspaper layout does not translate to LookML. Is there any movement on synchronizing the two, so we can create the layout using the GUI and copy source to the LookML Dashboard?

(Abby West) #18

Hey folks!

Just wanted to provide some insight into our thinking and current work on dashboards:

The End Goal

There are some great features of LookML Dashboards, and we’re working hard to preserve them. In particular, we love:

  • Version Control
  • Mass editing (which comes from being text based)
  • Portability (which comes from being version-able in git)

We also want to join that together with the core benefits of User Defined Dashboards:

  • Adjustable layouts
  • Ease of creation
  • Ease of editing

So, we are working towards full integration of our Dashboards. In the end state, you’ll be able to create point-and-click dashboards and have the option of also representing that dashboard as text. You’ll also be able to create dashboards in text, and they will enjoy all the benefits of our content management system. To the end user who is not editing the dashboard, they will be indistinguishable.

The Process, in summary

We’ll get to this end state in a few phases:

  • [In Progress] The ability to export an entire User Defined Dashboard as LookML, providing manual version control.
  • [In Progress] The ability to expose LookML Dashboards in Favorites & Top Content
  • The ability to put LookML Dashboards into Spaces, meaning the end user cannot tell which dashboards are backed by LookML and which aren’t
  • The ability to edit LookML-backed Dashboards via the UI and have those changes written out to the LookML

The Process, with details

Phase 1 (In Progress)

  • (a) The ability to export an entire User Defined Dashboard as LookML, providing manual version control
    This change comes from a tremendous amount of work under the hood to make it possible. It provides a manual way to convert User Defined Dashboards to LookML, and specifically creates the ability to translate newspaper layout from User Defined Dashboards to LookML.
    You’ll be able to move User Defined Dashboards across instances by creating new LookML dashboards for each User Defined Dashboard and using the existing workflow to move those LookML files across instances. Then you can import them into Spaces on the target instance.
    There will not be a formal link between the UDD and the LookML dashboard; dashboards will create a new ID on each import to a Space.

  • (b) The ability to expose LookML Dashboards in Favorites & Top Content
    We’re making some changes to how we define content within Looker, which will expose LookML Dashboards as able to be Favorites and will include them in Top Content Lists based on their popularity relative to other content pieces.

Phase 2

  • The ability to put LookML Dashboards into Spaces, meaning the end user cannot tell which dashboards are backed by LookML and which aren’t
    You’ll no longer have to use the Import to Space functionality (which breaks the association with its LookML) to expose LookML dashboards in Spaces; instead, they will be able to appear in Space lists, Search lists, and so forth, like any other piece of content. You will be able to control the ability to view those dashboards via the content access controls system that governs content in Spaces, however you will still only be able to edit the dashboard in LookML.
    This change means that nothing is lost on movement into the Space; the dashboard is still connected to its LookML back end and has a persistent identifier.

Phase 3

  • The ability to edit LookML-backed Dashboards via point-and-click and have those changes written out to the LookML

After these pieces are complete, we’ll look towards providing some of these options for Looks, as well as more formal portability mechanisms.

(Alex McGrath) #19

Hi @abbywest,

A few questions -

You’ll no longer have to use the Import to Space functionality (which breaks the association with its LookML) to expose LookML dashboards in Spaces

Will this association with a Space be done in the LookML definition of a dashboard? Or will there be some other UI action to be performed? We roll out our LookML dashboards to 30+ instances and it would be great if this was all source controlled too.

The ability to expose LookML Dashboards in Favorites & Top Content

Will this also allow usage monitoring of these dashboards via i__looker? I’ve raised this feature request:
as it’s a very big issue for us.

(Abby West) #20

Hi @amcgrath83 - great questions.

Regarding Spaces in the model: To start, the placement of content in Spaces is going to remain something that gets done in the UI. The flow for doing so should be a lot easier than the current UDD>LookML>UDD one, but it will still require you to place items manually. In the future, we may look towards putting more items into the modeling layer.

Regarding usage statistics, that should indeed get addressed as part of this work.