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:
- Order ID
- Order Subtotal
- User Email
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.
label:controls how individual fields appear in sidebar and in headersgroup_label:controls how the group reads on the sidebargroup_item_label:overrides the individual field’s appearance on the sidebar
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:
- Order Line: each row is a line that makes up an order, containing a Product ID, subtotal, etc.
- Order: containing information about shipping address, timestamp, payment, etc.
- Product: the product on the line, for example Apple AirPods Pro 3rd gen
- Product Group: the sub-level product category, for example Audio
- Product Department: the top-level product category, for example Consumer Electronics
You will want to use leading whitespaces to achieve some sorting (I’ll use underscores to specify added whitespaces for sorting):
_Order Lineappears first, as it’s the starting point of the exploreOrderas it isProductas it isProduct__Group, using 2 whitespaces in the middle so that “Group” appears before “Department”Product Departmentas it is
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:
-
Repetition: Constantly repeating the
view_label:value for each field is inefficient. It goes against the DRY (Don’t-Repeat-Yourself) principle. -
Inflexibility: These labels cannot be overridden with
explore:join:view_label:, limiting reusability. -
Confusion: Customizing view labels on a few fields can be confusing. Your user may not be able to tell where the fields come from—is it part of the fact table transaction, or is it from the dimension table that represents an account’s current state?
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.