Parameters Overhaul - UI/UX

Parameters in Redash hold a lot of potential. We plan to completely overhaul the implementation both on the UI/UX front and also the backend implementation to allow more varied usage scenarios.

As we start the UI/UX work, we documented the planned work in the linked issues here:

We welcome you to join the discussion and share your thoughts and ideas (preferably as comments to the relevant GitHub issues or here).

2 Likes

The dropdown list is excellent, but needs a way to distinguish between ‘value’ and label of value… For example:
If I had a drop down list for a sort option… ‘1’ vs ‘-1’ that is used in a mongo query. I should be able to label it as “ASC” vs “DSC”
A very simple input box for dropdown list should use something like label|value or label:value as an example… Possibly even use JSON objects or HTML to configure an ‘input’ select box.

That’s a good idea. Just need to think about the separator.

In the meantime, you can also use the ability to use a dropdown based on a query, and have these values defined in a query (queries support already passing key/value).

1 Like

Not sure I understand the query capability for dropdown, initially I figured the dropdown selectable options would be based on the queries result thus label vs actual wasn’t worth investigating how queries would work.

ie. dropdown query something like (select options from table where x=y) say that brings back (1, -1, 0) its still only giving me the ‘value’ not labels for the value??

ie2. are you saying if I instead used (select label,options from table where x=y) bringing back (ASC,1 ; DSC,-1 ; Block,0) would put the label in the select and use the option in the parameter?

parameters and filters seem closely aligned, in that parameters are passed to queries to filter results, but maybe parameters could just be filters on the client-side?
Something I’m playing around with at the moment is more to do with filters than parameters but I’ll throw it in in case it makes sense on parameter overhaul.
What would be useful is a multi-select filter list coming from a different query, As an example;
a dashboard with three queries on it, it has global multi-select filter of regions, the list of regions comes from a query

(select region_name as label,region_id as value from user_regions where username = {{ current_username}} order by region_name) as "{user_region_list}"

One of queries on the dashboard then could look like;

select region_id as "{user_region_list}::multi-filter",items,sum(cost) as totalcost from items_table where created_date >= '......

because this is needs to evaluate the current_username value (or any other parameter value) at runtime, that needs to be completed on the client-side, and the cache query just needs all data before filtering.

Played around with the new feature and I feel it lacks clarity in user experience.

A few UX issues I experienced:

  1. The 3 param types dashboard/static/widget level are really confusing to me.
  • Setting dashboard param within a widget context is counterintuitive imo.
  • Don’t understand the difference between static and widget level.
  • Feels like widget level should be the default selection.

  1. Parameter form labels in {{ syntax }} looks like a server bug.

2

  1. The spacing between label and fields is too big. Actually, can the fields along with the modal itself be thinner, bringing everything closer together?

3

Here’s my suggestion:

Very concise parameter list, defaulting to param value linked to query.

Clicking “edit”, a modal appears allowing to edit label and value.
Explanation under label field.
Value defaulting to “from query” (link to query) with disabled text field.

32

Click “dashboard” and if already defined, shows disabled text field.

41

Last option, manually setting value with editable input by parameter type (text, number, date, bool, …)

12

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

31

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

02

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.
38

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

Query param option
56

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 .

:+1:

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:

Editable

View only

Irrelevant

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?