Question

Looker explorer design --> small explorers or large explorers

  • 25 November 2020
  • 2 replies
  • 98 views

Userlevel 1

Hello Looker Team

 

As you know that Looker explorer design is a really important step and it requires a lot of planning upfront. We want to make sure our explorers matches with business expectation, they are easy to understand, easy to navigate, not redundant and avoid too much information. And also once users starts to build the content on top of your explorers, it becomes really hard to change anything in the explorer design later on

 

I have seen articles where it was advised to create small explorers which answers specific questions.  I agree on this approach in terms of database performance, but for user experience its kind of confusing, since users will eventually see 10,20, 30 little explorers and they will be confused and navigation becomes hard

 

Another approach i have seen is to create big explorers related to each business activity like (‘inventory’, ‘sales’, ‘marketing’, ‘risk’) and join 10-15 tables one each explorer.  On the user navigation end, its very simplified, a sales users know where to find sales data,  a marketing user knows where to find marketing data. However this approach is really heavy on performance

 

What do you recommend ? Should we comprise user experience for database performance? or vice versa or is there any better way?

 

Thank you

Raman


2 replies

I’m not certain how our Looker Overlords would answer this (and I, for one, welcome our Department of Customer Love overlords), but this sounds like a classic “it depends” question and answer. I can offer some tidbits of advice, and couple of general responses, and I really hope they’re useful.

  • Remove complexity from your explores by using the fields: [] parameter to limit what’s exposed to the business users
  • It’s not hard to change anything later, so long as you set up your measures correctly initially, so think about those deeply
  • Furthermore if you do change a measure later, the beauty of Looker is that you’ll redefine it once in the model, then send out an explanation and you’re done
  • Performance is not related to the complexity of the explore, because Looker carefully composes the SQL request based on the selected fields
  • E.g. you might have 1000 fields in the explore (pro tip: limit that using fields: []), but if the business user selects one dimension and one measure the SQL is lightweight
  • I.e. check the SQL tab of the Data table to see what is actually sent to the database for retrieval, it can be simple despite the complexity of the explore
  • Navigation is the hardest part, I would concede. We’re still working on this, in terms of making a nice business-user-friendly home page to tell ’em where to Look

There’s no easy answer. Just be prepared to do it one way, and make some changes based on your experience. I have found that redefining a measure once and propagating that everywhere is technically easy, and judicious use of fields: [] helps the biz folk greatly.

Userlevel 5

What if you ask the following question: “Is it difficult to answer specific question with a complex explore?”

It might be if people do not what to look for or how to navigate. I am currently trying to reduce number of explores in our Looker from 40 to hopefully fewer than 10. The ability to answer questions will not be impacted but the learning curve will be different. 

That’s why I think it’s crucial that you don’t just blindly go with Business expectations, or Product. Looker is still a lot of code to manage, along with all the views, explores, extends, refinements, models. You can try to find a middle ground rather than go extreme on one side and then suffer on the other. 

Data Dictionary was a really good introduction by Looker but it still lacks ability to change it into a really informative knowledge base about Looker. Not just what the fields mean but also how fields are connected, the sections, groups, and so on. 

 

Unfortunately, explores still have few things that could be improved, in order to help non-data users explore with more ease. From the top of my head the fact that you can’t put a dimension group in a group is one, probably because it’s already a group.

I believe some changes are coming to the explore field picker and hopefully that’s the first step. Next would be to change the Data Dictionary so that we don’t have to keep Looker knowledge in Google Docs, Notion, Confluence, or our heads.

 

I digressed a little bit. The best advice I can give is to start small and big at the same time :) Big in sense that you include many aspects in one explore as long as they make sense logically, and small that each section has only the obviously important fields. Then you can wait for feedback. Is it easy but there are not enough fields? Awesome, that way you can manage what you add and you receive important piece of information - awareness about what fields/metrics are needed.

Reply