Parameters Overhaul - UI/UX


If dashboard param isn’t already defined, “save” button is disabled and alert icon appears.

Hover over icon explains the problem and allows to create it on the fly.



I like the direction, it definitely makes the list of parameters easier to process.

What I didn’t like:

  • The parameters list doesn’t have the most important information: where the value comes from…
  • “From query”/“From dashboard”/“Manual” - if I didn’t have the context I wouldn’t understand the meaning here. Maybe the current descriptions can be worded better, but I think they are still make more sense than these ones. Maybe @susodapop can help.
  • The default should be to use a dashboard level parameter and this flow should be simple. Here you add some friction to it, mostly the need to “Click to create” instead of just implicitly creating one. Also it seems like we lost the ability to actually choose which dashboard parameter to connect it with.


@arikfr How about this? (Live version)

TBD: The “Edit” link will allow changing source and renaming label in either:

  • popover / modal
  • Expandable row


Updated suggestion (live version):

More concise

Click value source, popover opens.
New widgets have “Dashboard parameter” selected by default.

Dropdown with existing dashboard params (mapping feature).
Defaults to new entry with key name.

Query param option

Manual entry

TBD: Editing labels will be done in the same fashion, by clicking over left most “Label” values (disabled for param types that do not allow renaming label).



I like the direction this is going!

Some notes:

  • To be consistent with the New Parameter dialog in the query page, Label -> Title, Key -> Keyword.
  • Value should be Default Value.
  • In “value parameter”, it’s not “Query parameter” but rather “Widget parameter”.
  • I feel like “manually set” is not as accurate as “static value” -> static means not changing, unlike manual.
  • Maybe along the “Dashboard parameter” we should mention which dashboard parameter it is?
  • Is it clear that clicking on the link is the way to change this? Maybe it should have some other visual hint?


Label -> Title , Key -> Keyword .


Value should be Default Value .

I mean for this to be the actual current value. If parameter source is changed or value updates, this will reflect it accordingly. No?

…it’s not “Query parameter” but rather “Widget parameter”.

Then perhaps I’m misunderstanding this option. Doesn’t this mean it’s linked to the parameter value defined in the query editor?

… “static value”…

The way I see it, all value sources are static (set manually, not automatically), the difference is that they’re defined elsewhere. I think the most accurate definition would be “Widget parameter” or “Local parameter” as it implies it is set within this widget’s scope. We can go with “Static value” if you think so.

… mention which dashboard parameter it is?

I had that in the previous version but decided it was unnecessarily adding visual noise, and available upon clicking the source. I can return it if you think it has value at a glance.

Is it clear that clicking on the link is the way to change this?

I explored all kinds of versions and settled on this as it is the cleanest and follows the convention set by the recent Refresh Schedule phrase.
Can instead:

  1. Have a last “actions” column with “Change source | Edit label”. I didn’t like the noise.
  2. Have an “edit” link / button next to the value source and label.
  3. Make the row expandable and allow all edit options there. I couldn’t yet make it work.


No, the current value has no meaning on its own as it is transient (unless you use the static option), hence why “Default Value” is more accurate description. This is the value the dashboard will open with if no other value is passed via the URL.

When adding a visualization which uses parameters to a dashboard there are 3 options for where the parameter value will come from:

  1. From a dashboard level parameter: rendered at the top of the dashboard and applies to all the parameters which use it.
  2. From a widget level parameter: rendered in the widget and applies only to this widget.
  3. Static value: _no UI is rendered_for this parameter and you can’t change it once it’s defined here. Hence “Static”.

I think you misunderstand the different options. I suggest you try the different options in a sample dashboard and then come back to this discussion :slight_smile:

:+1: let’s roll without it.

I think option #2 (edit link/button) is worth testing briefly. I agree that the link option is better than #1 and #3 is too much effort at the moment.



@arikfr and I settled on this for now



Following this release, @susodapop has raised an inquiry about title editing:

What happens to the Parameter Title when a dashboard-level parameter is in use? From what I can tell this isn’t displayed anywhere. The dashboard-level parameter has its own Title that supercedes the widget level name. Is it possible to hide the Title or gray it out from the Parameters list modal when the Value Source is Dashboard?

If I understand correctly, there are 3 states to cover:

  1. Editable - widget param, new/own dashboard param.
  2. View only - linked to other dashboard param which sets the title.
  3. Irrelevant - static value in which the widget doesn’t display the title.

Now with screenshots of my current work:


View only




I like the tooltips. I would propose a slightly different approach to presentation:

Editable: Keep this as-is. It looks great
View Only: Replace the circle glyph with an “i” in the middle with either a lock or chain glyph like this one:

glyph example

To indicate that the title is tied to something else. You can show the tooltip when the user hovers over the glyph.
Irrelevant: Instead of a strikethrough, just turn the text dark gray with a tooltip explaining what’s happening. The strikethrough looks bad to my eye. And grayed out text is a common design pattern that tells the user “you can’t change this”.



All suggestions sound good to me.



Unfortunately, there is a setback - the current code doesn’t allow to easily or reliably determine which dashboard parameter has dibs on a title. It’s possible but requires some code thru-hoop-jumping.

Which makes me think once again that renaming param titles shouldn’t even be offered in the dialog but rather in context. Since the titles are purely presentational, they should be allowed to be renamed where the value resides - on widget / dashboard param top sections. M I Right?? @susodapop @arikfr

1 Like


Itmt updated design. @susodapop wdyt?



Just one suggestion: flip the chain glyph on the vertical axis so that it runs from southwest to northeast. That way it follows the same “trajectory” as the pencil and the slash through the eye glyph.



Yeah I thought that to do that as well :sweat_smile:



A couple small issues with the latest beta version.

Parameter Titles

The parameter Title for static params always retains it’s previous value when switching to a static parameter. So if I switch it from using a Dashboard Level parameter to a static one, the Title is grayed out but still reflects the name of the Dashboard Level parameter. Seems like this should switch back to the parameter keyword in the underlying query instead. WDYT?

Default Values

The Default Value field suggests that I can influence the initial parameter value on a dashboard. But this isn’t the case. For example, if I use a dashboard parameter called “Param1” and it is currently set to Foo then the Default Value column shows Foo. But if I set “Param1” equal to Bar and reopen the parameter mapping panel, the the Default Value now shows Bar. Refreshing the browser page will reset “Param1” to Foo. So the field is really reflecting the current value of the dashboard parameter.

Incidentally, it would be extremely valuable to remember the most recent parameter value selection for dashboards. If I run a dashboard with “Param1” set to Bar then I expect it will remain set to Bar if I navigate away and later return. Right now it doesn’t do that. It pulls the most recent parameter value that was executed from the Query Editor.

If you have two parameters that are linked to the same Dashboard Parameter, that parameter defaults to the most recently executed parameter value of the widget that was added to the dashboard first (sometimes). At other times it seems to pull the parameter value out of recent browser memory. It’s unpredictable.

Can’t add two widgets with the same parameter keyword

This is a bit strange. If I have two queries that use the same parameter keyword, it will not let me add the second widget to the dashboard. I think that it sees the first query has a dashboard parameter that already uses that keyword name. So when the second widget is presented with the same keyword name, it wants to create a new dashboard-level parameter with that name. But such a parameter already exists. This exception has not been handled, so the widget panics.

Typo in documentation link tooltip

There is a typo on the tooltip for the documentation link under the Value Source panel:


paramaters => parameters



Title for static params always retains it’s previous value

This was intentional with the following in mind:

  1. The updated title could have been so for months, then when changing to static, suddenly returning to original title - might be unnecessarily confusing.
  2. Once a static value, the title persists, even if the previously mapped to dashboard param changes title subsequently.

the field is really reflecting the current value of the dashboard parameter

Hmm. Naming it “default value” was @arikfr’s request as it was first named “value”. So either the column name is wrong, or the displayed value has a bug. @arikfr is this working as you expected?

It pulls the most recent parameter value that was executed from the Query Editor.

I’ll defer to @arikfr or @levko here.

Can’t add two widgets with the same parameter keyword

I tested that scenario and it seems to work fine. Can you help me reproduce this on netlify preview?

Typo in documentation link tooltip

I’m sorry :confounded:



Yes I will put together an example and share with you.



I am no longer able to reproduce this issue :grinning:

1 Like


Would it be possible to add an indicator beside a parameter widget to indicate that the dashboard must be refreshed? It’s not obvious at first that the parameter value can be incongruent with the data displayed in the graphs. Perhaps a red dot beside the parameter widget? Or maybe the execute button?