Explicit “Add Parameter” Button in Query Editor

[arikfr]

Add a button to the interface to add a parameter to the query. This button will open the current parameter definition dialog, but will let you also define the parameter keyword. Once submitted, it will add the {{parameter}} string into the query.

• This will help with the date range issue (Date Range Type Parameter #2643), as it can define the parameter keyword and then in the query you can use {{keyword.start}} and {{keyword.end}} to get the start/end of the date range.
• Will help with discoverability of the feature (today there is no hint about the existence of parameters).
• Should be also triggered by a keyboard shortcut.

[kocsmy]

Here's the proposed design for this:

• "+ Add Parameter" button added below the query editor.
• This opens the parameter dialog, see screenshot. We can change the form items based on the selected type, just like how it works now.
• The dialog closes and inserts the parameter to the query editor and the UI element for the parameter.

[arikfr]

Some notes:

• Maybe use an icon for the button instead of the long text (something like {{ }} maybe?)? While it will require some learning from the user, it will create a more streamlined UI.
• If we already add buttons there, let's mvoe the format button there.
• The Keyword should be the first item in the form, the Title should come after and Type last. Title will be auto filled (with some manipulation to make it human readble) based on Keyword value.
• Enter key in this form should submit it.
• We need a keyboard shortcut to trigger this UI.

[kocsmy]

Maybe use an icon for the button instead of the long text (something like {{ }} maybe?)? While it will require some learning from the user, it will create a more streamlined UI.

• I was thinking about this and we could use the same for this: "How to show if a widget is affected by a parameter? Maybe color code them, and show this color on the widget?" of Dashboard Parameters #2641

I'm a bit concerned that {{ }} might look like something is broken on the interface :)

The Keyword should be the first item in the form, the Title should come after and Type last. Title will be auto filled (with some manipulation to make it human readble) based on Keyword value.

• This is exactly what I did first, but then I was thinking what happens if you add a data-range. Then we'll need to add another keyword and it might be strange that something changes not below the type selector but on top of it.

[arikfr]

I'm a bit concerned that {{ }} might look like something is broken on the interface :)

Good point. Let's see how it looks like. We can also use the filter icon, but this means we need to deprecate the other filters functionality :)

This is exactly what I did first, but then I was thinking what happens if you add a data-range. Then we'll need to add another keyword and it might be strange that something changes not below the type selector but on top of it.

For a Date Range you still define a single keyword, it just that it has two sub-keywords. I.e., you define dateRange, and then use dateRange.start/dateRange.end.

[kocsmy]

Filter icon would be confusion I think.

How about using this icon instead (it's custom made)? We could use this on the dashboard widgets affected by global parameters.

Regarding the order of items: okay, got it, then we can add a little microcopy guiding the user how to use the parameter 👌

[kocsmy]

I'm wondering if there's a nicer way to inform the user. I might improve the design of this modal, it doesn't look great.

[arikfr]

How about using this icon instead (it's custom made)?

Let's continue with {{}} :)

Regarding the order of items: okay, got it, then we can add a little microcopy guiding the user how to use the parameter 👌

👍

[kocsmy]

To be honest I don't think the {{ }} is better than the little icon. Especially if you end up using it on the widgets on dashboards. Let's discuss on a call.

[kocsmy]

As discussed, we'll go with the {{}}: