Raise a UserError from the next step in the current step

💡 Feature Requests
1

Description of the limitation and why it is relevant to address

As a user/developer, I am using an application that prompt me to provide inputs in ‘step 2’ and shows a result/report in ‘step 3’.

I want to see the User errors raised in the calculation of ‘step 3’ directly in ‘step 2’ where I provide inputs.

So that I can see the user errors directly in the step in which I provide the inputs and adjust them easily, with minimal back and forth.

I think this is relevant for the VIKTOR platform because this would enhance user experience by reducing unnecessary navigation and facilitating a smoother input-result workflow on the VIKTOR platform.

Submitter proposed design (optional)

There are a few possibilities. For example:

1 - Modifying the ‘on_next’ attribute of Step() to accept a Boolean.

  • If True, only proceed if no UserError has been raised in the next step, displaying the error if it occurs.
  • Default is False.
  • This could also be a completely different attribute.
    calculation_step = parametrization.Step(
        'Calculation',
        previous_label='Configuration',
        next_label='Calculate',
        on_next=True,)

2- See current workaround point 3.

Current workarounds

There are at least 2-3 current workarounds:

1 - Use of ‘on_next’ Attribute: Limited to 3 seconds, which is not suitable for cases exceeding this duration, as being discussed now.

2 - Combine Input and Result in Same Step: Problematic for dynamically generated HTML as the view updates in response to input without user initiation.

3 - In the HACKTOR application, the user is asked to update the result within the same page and warned that it is not up to date. However, I could not find any description in the documentation regarding this, and specifically for the case of a dynamically generated html report.

image
image1921×850 120 KB

2

Hi Kassi,

Thank you for writing up this feature request.

Would increasing or completing removing the limit of 3 seconds on step validation solve your problem?

3

Hi rdejonge, thank you for the prompt answer. Completely removing the limit of 3 seconds on step validation would certainly solve our problem.

4

Could you elaborate a bit more on what kind of validations you implement in your app? What are the things you are checking and why does that take a long time?

The three second limit on step validation was chosen because long validations can negatively affect usability of apps. In our data we see that the bulk of the step validation functions implemented in apps take less than a second to complete.

Curious to understand your use case better!

5

Absolutely!

We had existing web-based applications that we transitionned to viktor.ai. These applications take some user input and return either an html report or a user error.

As we transitionned to viktor.ai, we formatted these applications in some steps. One of the step is for collecting the user input (input step) and another to display the report (result step).

When a user goes from the input step to the result step, we use the validation process for two purposes:

i) Validate the user input. This takes less than 3 seconds.

ii) Validate the calculation can go through without an error being generated. Essentially, we perform the calculation, so that if an error arise we can return it directly in the input step. This can take between 0.5 to 45 seconds depending on our modules.

This need arises because while we can be certain of the correct input format expected, we can’t be certain that correctly formatted input should provide a result or an error as per design standards. Hence, if the second verification is not performed, the error will be displayed on the result step, and the user has to go back and forth.

In addition, having both steps merged into one was problematic due to the constant update/wavering of the report (dynamic html) whenever an input was changed rather than on a user click.

6

Kassi,

In this case it seems you can change the duration_guess of the result view to 4 seconds to reach your goal. → A refresh buton will appear on the view automatically. Also see the docs:

Another trick I sometimes do is setting the results by button (SetParamsButton) and storing it into storage: The result view can be generated from the storage data. In order to create a “trigger” for the view you can create a hidden field where you set (e.g.) a random number ór the current time so the params are refreshed and the views as a consequent. With this solution the result is a. the refresh button is at the input side (rather than in the view) b. you can create a combination of [XXX]andDataView where the Dataview is only displayed on hitting the ‘calculate’ button.

Hope this helps,

Kind Regards,
Wichard

1 Like
7

Hi Wichard, thank you for your response. For having tested it, I believe this meets all the criterias outlined in the request, and more!

1 Like
8

@Wichard thanks for chipping in!

@kassi Good to hear that the proposal of Wichard meets your current needs! If I understand correctly you are now using a single step instead of splitting into 2 separate steps?

9

Hi @rdejonge

If I understand correctly you are now using a single step instead of splitting into 2 separate steps?

From a development perspective, I believe this solution addresses all the concerns and needs we’ve identified, while also being efficient in terms of implementation. From a project perspective, this will be brought forth to the appropriate channels and determined based on users feedback and timeline.