Make "missing parameter value" message friendlier

[arikfr]

Solution

1. When a required parameter value is missing and the user tries to run a query, the parameter should be marked as missing value (using red border). We might want to accompany this with some animation on the color transition, to guide the user towards the issue?

2. We shouldn't try to execute the query or show the error message we currently show.

Problem

Currently we piggy back the query execution error mechanism to notify the user that they need to enter a value for a parameter when a value is missing.

On a query screen:

On a dashboard:

The big red message feels very intimidating and I wonder if there is a better way to convey this message?

[kocsmy]

How about changing the design to warning or info so it'll be less intimidating? We can also refine the text to be friendlier: Please set a value for example parameter.

[kocsmy]

We should add the error message next to the input fields.

[arikfr]

We shouldn't treat this as an error message. It's just a state of the UI. One possible solution is to mark the parameters which miss value with some indication.

[kocsmy]

I meant like an input validation error, Bootstrap supports this by default:

[thoechsmann]

Would also be good to allow for empty parameters. Sometimes that is intended and I have to make a workaround like enter a text like 'none' when string parameter should be empty.

[kocsmy]

@arikfr I'm wondering if we should move those parameters inputs to Ant. Their error message is similar but placed below the form (which makes more sense to me). Furthermore, the date and time pickers are already in Ant.

[arikfr]

I think that @kravets-levko's implementation of dashboard parameters already switches everything to React, so using Ant won't be a problem.

But --

1. I'm not sure we should show any message beyond marking the field.
2. I'm looking for a more holistic definition of the behavior here when trying to run a query (or refresh a dashboard) and some parameter is missing value.

[kocsmy]

1. I think we should show error message. Traditionally, the UX of error message should 1. show where the error is, 2. tell what the error is, 3. recommend a solution. For example: Missing parameter, please fill. (or something similar)

2. Can you elaborate on this and what's the problem with the current implementation? The interactions feel quite natural for me and besides moving the error message to its place (next to the field), I can't see serious issues here but I might be missing something.

[arikfr]

Can you elaborate on this and what's the problem with the current implementation?

It looks ugly and intimidating.

I updated the issue description with the proposed solution. See if you have any comments.

[kocsmy]

Yes, this is better this way. Do you think we should just highlight the input without placing any error message below (like in my proposed design). I think it can be enough just to highlight the field but not 100% convinced.

[arikfr]

I think for now the highlight is enough. In most cases the issue is missing value, and this is obvious from the empty highlighted field.

[ranbena]

I think that best approach is to disable the "Execute" button when not all execute conditions are fulfilled, alongside a clear indication of the disable reason.

(Working on demo)

[arikfr]

Looking forward :)

[ranbena]

(ignore the wording and style)
Disallow execution if any param empty.

1. Toggle off execute button
2. Show reason tooltip on button
3. Indicate error on empty parameters. (Error message is optional and might be better without)

[arikfr]

@ranbena makes sense. I also think we can skip the error message, and just use the error indication.

It does mean we will need to duplicate the logic of finding missing values between backend and frontend.

cc: @rauchy

[ranbena]

When a required parameter value is missing

@arikfr are all params required?

[arikfr]

@ranbena yes :-) but it will change eventually.

Some additional input:

1. There might be other issues with a parameter, like wrong value.
2. Based on the above and to avoid duplicate logic between backend/frontend, how about we change the backend response to have a dictionary of "parameter name" => "error message" that we will use here?

[ranbena]

1. There might be other issues with a parameter, like wrong value.
2. Based on the above and to avoid duplicate logic between backend/frontend, how about we change the backend response to have a dictionary of "parameter name" => "error message" that we will use here?

Sounds good.
Yay my first backend task!