Building Great Looker User Experience with Labels

December 24, 2023 • 11:39 AM

In Looker development, enhancing user experience significantly hinges on careful attention to labels. They are the first elements users interact with in a report!

Throughout the development (and clean-up) work that I did at my company, I’ve distilled essential tips for optimal label use, presented here.

Embrace Singular Nouns for View Labels

In report headers, fields appear in this fashion by default: View name in bold, field name in regular font weight: View Name Field Name.

If you use a singular (or uncountable) noun as the view label, things read naturally and they fit English grammar. For example:

Group Logically with Group Labels

Group Labels, as the name suggests, helps you organize related fields in the sidebar.

For example, a user’s address may be made up by multiple fields such as address line, city, region, country, and postal code. If you group them under “Address”, they appear more logically in the sidebar, and when the user searches for “address”, all fields shall show up nicely in the search result.

Clean Up the Sidebar with Group Item Labels

In groupings, use group_item_label: to eliminate redundancy. Use it so that you don’t repeat anything that exists in group_label:. This helps make fields appear succinct and readable on the sidebar.

Note that neither of Group Labels and Group Item Labels appears in report headers; they are solely for the sidebar.

Specifically for grouped fields, you can shorten the field label in the sidebar with group_item_label:. Use it to not repeat anything that exists in group_label: so that fields appear succinct and readable on the sidebar.

Note that group_item_label: has no effect on fields in the report’s headers.

Putting it all together, this is how the fields all appear in the sidebar and in headers (suppose view label is “Order”)—

Field Label Group Label Group Item Label Sidebar Text Report Headers
Address Line 1 Shipping Address Address Line 1 Shipping Address → Address Line 1 [Order] Address Line 1
Address City Shipping Address City Shipping Address → City [Order] Address City
Address Country Shipping Address Country Shipping Address → Country [Order] Address Country

Fine Tune Group Labels and Group Item Labels for Dimension Groups

Dimension Groups are usually used to generate multiple timestamp fields from one source timestamp column. For example, when you use diemnsion_group: purchase you may generate purchase_date, purchase_month, etc.

There’s no rules on whether or how to use this trick. Just experiment with your Looker models, and see how it makes the most sense for your users.

Sort Stuff with Whitespaces

A lesser known trick of Looker is that you can sort how things are sorted on the sidebar: views or fields with a leading whitespace will appear in the 1st position; views or fields with more leading whitespaces appear in front of those with less whitespaces.

Suppose you are in retail, and you have an explore named “Order Details”. There are a few views that should appear in this logical order:

You will want to use leading whitespaces to achieve some sorting (I’ll use underscores to specify added whitespaces for sorting):

In the report headers and in the sidebar, Looker trims leading and trailing whitespaces, and collapses consecutive whitespaces. Your users should not be able to notice any artificial whitespaces that you add for sorting.

Another example is to use whitespaces to sort Address fields: you may want it to be Country → Region → City → Address Line 1 → Address Line 2 on the sidebar so that things follow a logical, not alphabetical, order.

However, be judicious with whitespaces: people still expect things to sort alphabetically most of the time. You should use it sparingly: either to prioritize a critical, central view of an explore; or to subtly influence the order of the views to reflect their hierarchy. You should never find yourself using 6 whitespaces just to meticulously sort your previous stuff.

Avoid Field-Level View Labels

Field-level view labels are what gives you a top-level organization on your fields. While they look helpful on surface, they can lead to maintenance challenges:

All in all, we’ve been doing fine without field-level view labels. In only extenuating cases where we need to move fields around, we do that by moving or merging entire views, never individual fields.

Parting Thoughts

Effective Looker modelling requires a dual focus: an engineer’s eye for clean, maintainable structures, and a user’s perspective for intuitive, engaging experience.

Empathy is key in user-centred design! Open your explore side by side in a separate browser window, try and see for yourself what you can improve. It’s a reflection that needs practicing.