[WIP] Widget parameters UX overhaul

[ranbena]

WIP - REQUESTING QA REVIEW

What's this?

Implementation according to UX discussion.

Before

After:

[arikfr]

One issue I found:

1. Open the "Edit Parameters" dialog.
2. Edit the label.
3. Open the parameter source editor.

Result: after closing the parameter source editor, the label value reverts to original one. Although if you open the popup, it shows the new one.
Expected: that the label will retain the new value.

Edit:
I couldn't reproduce this now 🤔 Maybe it has to do with me closing the Edit label dialog with hitting enter?

[arikfr]

How can I create a new dashboard parameter?

[ranbena]

How can I create a new dashboard parameter?

That's the default option and is transparent to the user.

In the screenshot above, a new "city" dashboard param will be created (or mapped to, if a matching dashboard param already exists).

[ranbena]

I couldn't reproduce this now 🤔 Maybe it has to do with me closing the Edit label dialog with hitting enter?

The only by design scenario is when "static value" is selected, since it has no "title override" feature the title reverts to original. Changing selection to Dashboard/Widget params restores the new title.

Edit:
I can see how this would needlessly confuse. I can change the behavior so title change persists in all scenarios.

[arikfr]

In the screenshot above, a new "city" dashboard param will be created (or mapped to, if a matching dashboard param already exists).

But you miss a scenario where I can point this to "city2" parameter, i.e. a whole new parameter which differs not only in Label but also in Keyword. This is useful if want to add two widgets that use the same parameter in the query, but should use different parameters in the dashboard.

I can see how this would needlessly confuse. I can change the behavior so title change persists in all scenarios.

In my case, I still had the edit button, so it's not this. No change is necessary I think, I will report if this ever happens to me again.

[ranbena]

But you miss a scenario where I can point this to "city2" parameter

Would this scenario not suffice?:

1. Create Widget1, by default creates new dashboard param "city".

2. Create Widget2, by default mapped to existing dashboard param "city".

But this does introduce a correlated limitation, in which a user can't create a new dashboard param if an existing param key already exists in the dashboard. Am I right? 😖

[arikfr]

But this does introduce a correlated limitation, in which a user can't create a new dashboard param if an existing param key already exists in the dashboard. Am I right? 😖

Exactly. The scenario you described is not what I described -- in my case, there are two city pickers.

[ranbena]

@arikfr a few updates:

1. Fixed "title" reverting issue.
2. Decided to split dashboard param options to new/existing.

3. The necessity to display mapped keyword now has significance.

Disclaimer

The UI is a little fidgety and style not consistent - I'll address it once functionality is solid 💎

[arikfr]

I didn't play with all the options, but so far looks like we're in the right direction.

[arikfr]

When adding a new widget:

[arikfr]

Some more issues I found:

• When mapping to existing parameter it should only allow for parameter of the same type.
• When picking a static value and click OK in the parameter mapping dialog box it clsoes the "Add Widget" dialog (see Gif below).

[ranbena]

• When mapping to existing parameter it should only allow for parameter of the same type.

Makes sense though notice it doesn't work like that in master @arikfr

• When picking a static value and click OK in the parameter mapping dialog box it clsoes the "Add

10x, looking into it

[arikfr]

Makes sense though notice it doesn't work like that in master @arikfr

I thought it might be the case :) How hard is it to fix?

[ranbena]

I thought it might be the case :) How hard is it to fix?

Not sure but it's now my top pri.

[ranbena]

I thought it might be the case :) How hard is it to fix?

@arikfr #3330

[ranbena]

Thanks for the feedback, continued in #3332.