Dynamic Time Granularity - opinions

[Dawid]

I am very curious about people’s opinions on this topic:

Looker Help Center

Dynamic Timeframes for Dimension Groups

You can use parameters to allow users to change timeframes on the fly, like a filter-style toggle where users can choose between rolling up their data at the date, week, or month level. First, assu...

parameter: timeframe_picker {
  label: "Date Granularity"
  type: string
  allowed_value: { value: "Date" }
  allowed_value: { value: "Week" }
  allowed_value: { value: "Month" }
  default_value: "Date"
}

I understand that the main reason for doing it is to switch Dashboard or a Look from one time granularity to another.

To me it was never necessary as I prefer to create multiple dashboards, let’s say weekly, monthly, and yearly and not only include slightly different visualisations but sometimes add things that only apply to certain timeframe.

I’m not saying it’s uselessm therefore no absolute yes/no poll here but I’m trying to find where this type of code becomes over-engineering and when it’s actually adding value.

[er1k]

We use timeframe_picker in almost every dashboard where we can apply it.

It has been helpful to only have one dashboard per topic and it creates much better user experience.

[Elisabet_Pino_M]

I think it is a very useful feature.

What I don’t like is the way it has to be implemented. Too manual… And the dynamic date you end up showing has to be a string to support Date/Week/Month switch. Looks like a workaroud.

But yes, I’m going to keep using this until we have a better option to implement something similar.

[Dawid]

Exactly, the nature of implementation to me feels very hacky, probably why I’m not so for it…

[bens1]

The way I see it, when you give a blank canvas data tool like Looker, there are patterns like shifting between date granularities that give rise to great little blocks of code like this that make Looker queries closer to micro-apps. Based on what you said, this would save you creating two dashboards (out of three in total). I consider that pretty highly efficient, and not over-engineering.

Moving forward, I hope that Marketplace offerings come up that can abstract this away so that as a user, all I’m doing is selecting a Date field (if I have the Timeframe Picker Extension), and clicking “Choose Granularity”, and it would reload the explore with a newly spun-up Extend applied to make this happen.

For the time being, someone on here did something clever that I’ve been doing since. When I implement a pattern, I do it as an Extend with Liquid code to reference the table names they’re being extended onto (or from, I always get that mixed up). I make them dependent on a consistently named variable from whatever it’ll be Extended onto. For _date_comparison, I can Extend it onto any Explore or Joined View, as long as there’s a field field called event_date, for example. That concept would work nicely here too.

[moebe]

That sounds really clever
Do you have an example code block to share?

[bens1]

Let me get you mine shortly, but the closest ‘head start’ would be from Ben Cannon - Date Comparison Block.

It doesn’t tackle the renaming side of things, but gives you a sense of the Extend application side. If your desired pattern needs data restricted as it’s added to a query, then you may have to muck with a sql_always_where code snippet to apply to any Explore you’d like to apply it to as well.

[Sarah_Wilson]

I agree that the dynamic date showing up as a string is a pain. You really have to watch out to make sure that the dates are ordered correctly for graphs. Why can’t the dimension inherit the type the referenced dimension?

[Cyril_MTL_Analy]

You can bypass that by using the parameter order_by_field (https://docs.looker.com/reference/field-params/order_by_field)

[KSrinidhi]

While using date_granularity filter , month is showing as ¨2022-06¨ instead of ¨june-22¨. 

I tried rendered value option but it's still not working. I also used format in chart but no luck.