We have a number of developers for LookML who have made many explores that focus on their individual needs for visualizations. These are explores that don’t need to be available to all of our end users, so, in general, it makes sense to have them hidden; however, it’s a pain having to show or hide them all the time and many don’t use the ‘hidden’ feature.
A possible solution would be to expand the
hidden tag to have a value of ‘development’ – or to have a flag on an entire model, even.
Ultimately, the request is to be able to manage what’s in the ‘Explore’ tab a bit more granularly. There’re a lot of not-pretty solutions to this, but it would make scaling so much easier and it would allow non-technical users to get a very tailored experience in their product. This would absolutely increase the usability and decrease confusion for them - it’s certain to increase adoption among those team members.
One other thing to note is that we’re working on revamping Looks in such a way that may make the experience better. In our proposed new world a user would open a Look, and the Look itself would be its own page, separate from the explore page. That Look page will have the option to explore from that Look, but it will not be forced upon users.
We tried that option and, unless we executed it poorly (quite new to Looker), we found that excluding a model for a role meant that they could not see dashboards built upon those models.
We want end users to be able to see the Looks built on the explores, we just don’t want the explores cluttering the experience that new business users have when they log in. (Those explores would not be tailored for business users, mostly for the purposes of advanced users creating advanced visualizations.)
Why not create a new model for these explores for Developers or other advanced users? You can then use Roles and Model sets to make it so only the desired Users have access to the Explores
@stipoj, thanks for the explanation and use case for this request. I’ll pass this idea to our product team.
For the time being, the best approach would be to ensure that the
hidden: trueis set on any explore that should not be shown in the UI (but I can understand how having more control on this parameter would be beneficial).