arikfr
1
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).
askc
2
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.
arikfr
3
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).
askc
4
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.
ranbena
6
Played around with the new feature and I feel it lacks clarity in user experience.
A few UX issues I experienced:
ranbena
7
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.
Click “dashboard” and if already defined, shows disabled text field.
Last option, manually setting value with editable input by parameter type (text, number, date, bool, …)
ranbena
8
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.
arikfr
9
I like the direction, it definitely makes the list of parameters easier to process.
What I didn’t like:
ranbena
10
@arikfr How about this? (Live version)
TBD: The “Edit” link will allow changing source and renaming label in either:
ranbena
11
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).
arikfr
12
I like the direction this is going!
Some notes:
Label -> Title, Key -> Keyword.Value should be Default Value.ranbena
13
Label->Title,Key->Keyword.
Valueshould beDefault 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:
arikfr
14
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:
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 
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.
ranbena
16
Following this release, @jesse 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:
Now with screenshots of my current work:
Editable
View only
Irrelevant
jesse
17
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:
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”.
ranbena
19
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?? @jesse @arikfr
