Migration of Parameters component to React

Following the React Migration, the Parameters component will now get some attention on UX/UI and this topic will be for discussion on it and also on implementation details.

Currently the component has two contexts: Edit and view mode.

Core points I have in mind:

• Parameter Setting button on edit mode
• Make the sort-ability feature more noticeable*
• Improve mobile experience (may be a good opportunity to that as the component is on the Dashboard an on the Query page)

* This has been a sort of “hidden feature” so far:

drag-sort-parameter747×130 67.3 KB

It will also be necessary to find a replacement to ui-sortable for this feature. A few options from a quick search:

• react-sortable-hoc
• react-dnd

The first one seems easier. If anyone has other suggestions, lmk. I’ll update if I find other options

I had no idea the widgets could be reordered! Do you know if any of the react drag-and drop libraries support touch interface dragging (on a smartphone or tablet e.g.)?

Well reminded, @jesse .

react-dnd don’t work on touch interfaces by default (requires react-dnd-touch-backend)

And react-sortable-hoc works for touch interfaces (also offers a pressDelay setting, but doesn’t auto-apply that to touch devices [ref]).

A quick design of a suggested layout:

params2226×706 53.7 KB

I’m not in love with it but it speaks the current style and exposes the drag feature.

1. Drag handle on the left.
2. Drag placeholder.
3. Settings button top right.

But here’s the style I actually envision for Redash, UI that’s clean, minimalistic and futuristic:

(Not as a standalone design, but part of a broader scope)

421237×303 5.84 KB

On hover displays edit buttons or indications (TBD).

What happens with longer variable names? Do they wrap? Does the widget grow wider? Does the font-shrink?

Currently they grow wider.

For me the optimum is to have a max-width with ellipsis, and full name in tooltip on hover.

I agree. This is something we can implement right away, right?

Why show the data type to the user?

I agree. This is something we can implement right away, right?

Right after the React migration, yes.
Also, the tooltip would have to show up even for titles that don’t get ellipsised cause there’s no simple way to determine ellipsis occurring (it’s an entirely css feature) so let’s add a 1-2 sec mouseEnterDelay till it shows up.

Why show the data type to the user?

Showing the datatype allows me to omit a “settings” button (cause I can’t find it a proper unobtrusive location / design) and instead introduce editing via hover and click. (only a concept right now)

com-video-to-gif784×334 1020 KB

https://u0h05.codesandbox.io

That popup animation for the data type is lovely.

It’s also valuable because our documentation specifically calls out features of different data types for parameters. Displaying this information to the user suggests that the data type is a useful piece of information (they otherwise might ignore it).

I notice in the most recent animation that on hover the POPULATION parameter name doesn’t expand out. Is that a bug?

I’d like to see a draft of how this looks with Query Based Dropdown List Parameters.

1. How do you display the type name without cutting it off
2. Do you have an easy way to display the linked query name?

It would be nice if from the parameter widget there was an easy way to jump to the linked query.

I didn’t realize it shows only on hover.

Another option is to use the parameters sidebar, as discussed here:

In the sidebar, we can have a place for a “parameters catalog” (parameters you can use) and currently used parameters, where you can also open their settings. I assume that there it will be easier to find a spot for the settings dialog trigger.

@jesse @arikfr these are good points and great questions.
But I feel we’re hijacking this thread with a semi-relevant discussion.

Are you guys cool with the minimal-change version I suggested?

Yes.

You started