Labeling Views to Make Your Models More Understandable (3.20+)

(lloyd tabb) #1

Looker 3.20 introduces new ways to label fields.

Until now, you’re probably familiar with fields appearing like User Age. You’ll now have much greater freedom about how you want fields to appear to users in the field picker.

Field labels now consist of two parts:

  • The view_label begins the name of the field, and is the view name by default (“User” in the example above)
  • The label ends the name of the field, and is the dimension or measure name by default (“Age” in the example above)

If you’ve enabled the new field picker that was introduced in 3.18 (by going to the Labs section of Looker’s admin settings), fields are grouped by their view.

In 3.20, views can now be re-labeled so that they are logically grouped together in for end users in the field picker. You’ll still reference the fields in the way you’re used to when writing LookML.

Default Behavior

Suppose you had the following model:

- explore: order
  joins:
  - join: user
    foreign_key: user_id
  - join: user_order_facts
    foreign_key: user_id

- view: user
  fields:
   - dimension: age

- view: user_order_facts
  fields:
   - dimension: lifetime_orders

The resulting explore would have three separate views named:

  • Order
  • User
  • User Order Facts

The two dimensions would be displayed as:

  • User Age
  • User Order Facts Lifetime Orders

Both of these fields are really attributes of User. The fact that “Lifetime Orders” exists in a separate view isn’t all that interesting to the person exploring the data. It would be really nice if “User Order Facts Lifetime Orders” displayed as “User Lifetime Orders” instead.

In 3.20 there are a couple of mechanisms to do this:

Change the view_label for All Fields in a View

In the following example, all the fields in the User Order Facts view would appear as User instead:

- explore: order
  joins:
  - join: user
    foreign_key: user_id
  - join: user_order_facts
    view_label: User        # Change the view_label
    foreign_key: user_id

Change the view_label for Individual Fields

There are times (e.g. in a wide events table) that you might want to label attributes. In these cases you might want to declare the view_label and label for individual fields:

- view: event
  fields:
  - dimension: user_name
    view_label: User
    label: Name
    sql: ${TABLE}.user_name

  - dimension: user_id
    view_label: User
    label: ID
    sql: ${TABLE}.user_id

  - measure: user_count
    view_label: User
    label: Count
    type: count_distinct
    sql: ${user_id}

In LookML these fields are called:

  • event.user_name
  • event.user_id
  • event.user_count

However, they would appear in the field picker as:

  • User Name
  • User ID
  • User Count
12 Likes

Breaking a Wide Table into Multiple Views for End Users
(Alison) #6

Lloyd,

I love this solution. It solves for so many use cases and divorces the UI from the SQL JOINs.

Thank you to you and the rest of the team!

Alison

5 Likes

(Vlad Dubovskiy) #7

My first Discourse post. This is wonderful news! We’ll be doing away with some awkward naming conventions, like the “_” on view and dimension names to mimic the “right” UI name.

Thanks team

3 Likes

(Eric Nelson) #8

Really glad to see this feature in development, thanks to everyone @ Looker for being receptive to the feedback + picking this one up!

3 Likes

(Justin Palmer) #9

This is so good. As I read this, I almost literally see user confusion, renaming gymnastics, maintenance cost, and other pain disappear. Can’t wait to use this!

3 Likes

(lloyd tabb) #10

We’ve spun up learnbeta.looker.com. Its a clone of Learn that is running the latest release (so if you have a learn login, you should have one on learnbeta too). If you would like to try out the feature, it would be great to get feedback so we can make sure it’s right when it gets into your hands.

1 Like

(Justin Palmer) #11

This is sweet! I spent a few minutes with it. The view-level rename worked perfectly (diff attached).

For whatever reason the field-level Dog rename didn’t. I hardly ever want to rename on a field-by-field basis though. To my thinking, views represent distinct nouns, so mixing nouns within a view begs for a separate view anyway.

Really nice feature. Thank you so much.

view-rename.diff.lookml (2.1 KB)

1 Like

(lloyd tabb) #12

I think you wan’t

view_label: Dog

not

view_name: Dog

If it didn’t warn you, that’s a problem. I’ll take a look.

0 Likes

(Justin Palmer) #13

How embarrassing. Thanks Lloyd.

0 Likes

(Thomas Vo) #14

LOVE this update

1 Like

#15

It seems that view_label can be used as a parameter of explore also. Specifically, in version 3.48.7, the following code causes the field picker to display only “Bar” as the view:

explore: foo
view_label: Bar
# It also works without the following lines.
joins:
  - join: baz
    view_label: Bar

Is this intended, and not subject to change/removal in future versions?

(If so, it should be documented somewhere. I don’t see it in the explore documentation, where it belongs; nor is it mentioned in the documentation for view_label for join afaict.)

0 Likes

(Carter Moar) #16

@Michael, a view_label declared at the explore level should apply to that explore’s “base view”, but should not carry through to all joined-in views. With something like the following, do see two view-level headers in the field picker (‘Bar’ and ‘Baz’)?

- explore: foo
  view_label: Bar
  joins:
    - join: baz

I just recently modeled something out like that on an internal instance and got the expected two-label behavior. If that’s not what you’re seeing, I’d reach out to us at help.looker.com or on chat and we can dig into this.

Also, for the sake of completeness, here’s a more in-depth sample of what I’m doing:

- explore: foo
  label: 'Prettier Foo'
  view_label: 'Bar'
  joins:
    - join: foo_facts
      view_label: 'Foo Plus'
      [more joins and parameters, etc., etc., etc.]
0 Likes

#17

Yes, certainly. But the very existence of a view_label parameter for explore is what I was asking about. The documentation, and the original post on this page, only mention a view_label parameter for join, afaict. Is view_label for explore here to stay, despite its being essentially an Easter egg?

0 Likes

(Carter Moar) #18

Ah, yes, in that case it is a “real parameter” and can basically be thought of as a view-level view_label that applies to the base view of that explore. There isn’t currently any documentation on using it on the base view, but I’ve talked to our documentation folks and it is slated to be written. They’re also working on some slick new design stuff!

0 Likes

#19

Thanks for the info, @cutler.

0 Likes

(Alyssa Kwan) #20

Is there an equivalent to a “label prefix”?

Here’s the use case:

There’s a User table. I create a view named user.
In the model there’s another view named order.
Orders have an “opening user” and a “closing user”.
So I join twice to the User table using the from functionality.
For organization, I don’t want User objects for each from to get their own folder. I want to use the Order folder. I just want to prefix the label - Opening User Name, Closing User Name, assuming that the user view has a name dimension.

Does this make sense? How do I accomplish this?

0 Likes

(sam) #21

Hi @alyssackwan-clara!
Since you don’t want both User tables to get their own folder, view_label isn’t going to be the perfect solution. I can pass on your use case to our product team, though! Would something like a field_label_prefix fit your use case? I imagine LookML like:

explore: order {
  join: user_opening {
    from: user
    field_label_prefix: "Opening User "
  }
  join: user_closing {
    from: user
    field_label_prefix: "Closing User "
  }
}
1 Like

(Alyssa Kwan) #22

This is perfect!

0 Likes