Given the following Explore:
explore: foobar {
join: foo {
...
}
join: bar {
...
}
}
When users navigate to the FooBar Explore, the Views will be in alpha order from top to bottom:
Is it possible to manually order these with out relabeling them? Perhaps to:
I have yet to find anything in the docs. Thank you!
Solved! Go to Solution.
For that I use view_label
with spaces to be able to order views as I want
something like:
explore: eeee_view {
view_label: " EEE View"
join: aaaa_view {
view_label: " AAAA View"
}
join: zzzz_view {
view_label: " ZZZZ View"
}
join: yyyy_view {
view_label: " YYYY View"
}
}
(and same for ordering Dimensions & Measures with group_label
)
Unfortunately there is nothing that would work on ordering fields or views. Sometimes people start adding numbers in front of names like 1. foobar
, 2. foo
, 3. bar
but I think it can get very dangerous and less readable with more groups
Yes, @Dawid’s correct. One thing that we see people do to bump just one or two important view_labels up to the top is to prefix the label with an underscore like “_foobar” which will bump it up to the top.
I’ve also had some success experimenting with invisible unicode separators and whatnot to create a less confusing experience:
Would you imagine this being a new parameter in the join: object that lets you choose explore_order
or something like that?
@PaulM1 I would like to know why you think it’s crucial to change the order? After all our eyes and brains work alphabetically much better if presented with a list of labels. Imagine many views/groups like in the History
Explore of System Activity
Model. If I’m thinking about a query based on Dashboard
I roughly know where to find it.
I think that custom order approach only works if everybody who uses Looker has already an understanding of the hierarchy and if there aren’t too many views - but if there aren’t too many, why not let it naturally order?
I think a little flexibility in this area is not an odd request. I do understand that an alpha order is natural. But data is very rarely organized alphabetically. For example:
If I have an Explore that has 2 tables with measurable data, and 6 tables with descriptive data (i.e. Kimball’s Facts and Dimensions), some cases could benefit from grouping the Views as such.
Likewise, if I have an Explore that contains 4 tables, all joined in a hierarchical manner, I think I would prefer the natural hierarchical order:
"Location - Country"
"Location - Sales District"
"Location - State/Province"
"Location - City"
…over an alpha order:
"Location - City"
"Location - Country"
"Location - Sales District"
"Location - State/Province"
I feel in some cases (not all), our brains work quite a bit closer to the first ordering.
And yes, I know that’s not great data modeling. It’s just an example. 🙂
Yes. I could see many use-cases for a feature like this.
For that I use view_label
with spaces to be able to order views as I want
something like:
explore: eeee_view {
view_label: " EEE View"
join: aaaa_view {
view_label: " AAAA View"
}
join: zzzz_view {
view_label: " ZZZZ View"
}
join: yyyy_view {
view_label: " YYYY View"
}
}
(and same for ordering Dimensions & Measures with group_label
)
Wow, I actually didn’t know this Cyril. More spaces == higher in the ordering? I can finally stop using the Mongolian Vowel Separator unicode character!
Just to note, the spaces still work but the number of spaces has no impact
Yes, @Dawid’s correct. One thing that we see people do to bump just one or two important view_labels up to the top is to prefix the label with an underscore like “_foobar” which will bump it up to the top.
I’ve also had some success experimenting with invisible unicode separators and whatnot to create a less confusing experience:
Here you can see that it goes 1. User 2. Climb Type 3. Ascent and proceeds alphabetically from there-- User has a line separator prefixed to it and Climb Type has a six-per-em space prefixed to it.
Would you imagine this being a new parameter in the join: object that lets you choose explore_order
or something like that?
@izzymiller could you explain how you have used invisible characters?
thanks!
My only issue with adding invisible spaces to bump it up in the order is that the spaces show up in the column name when you export it to csv...