Disabling Steps

💡 Feature Requests
1

Hello everyone,

I would like to hide a Step according to “visible” attribute (IsEqual…) :
test= Step(‘xxx’,views=[‘xxx’])
test.field= Tab(‘xxxx’)
test.field.test=Text(“xxxx”, visible = IsEqual(Lookup(‘params.xxxx’),‘xxx’)

By testing it the Step is empty but not deleted/hidded.

Do you any ideas to solve this topic ?

Regards,
Louis

1 Like
2

Hi Louis,

Currently, it is not possible to hide an entire Step, Page or Tab. I have added your request to our internal issue tracker.

Regards,

Raoul

3

Hi Louis,

Appreciate your feature request! To better grasp the scenario, could you provide a specific example where you’d like to use this feature? Having a concrete use case will help us fine-tune our approach and offer a more tailored solution.

Thanks,
Ke

4

Requested by @fzhou

5

I have changed the status to “in-discussion” since this has not yet been picked up. The visibility of Pages and Tabs has been added since this feature request was first created

6

We are looking into this and need concrete usecases to validate potential implementations. Could you share your usecase / situation?

I see a lot of upvotes from:

Could (one of) you describe what the desired outcome is for your app? How would you use the proposed feature and how would it improve the current situation?

PS: do you want to hide the complete step or do you just want to hide (one of) the views?

7

@matthijs I think there are different use cases for hiding a step and for hiding a view. Hiding a step could be useful for internal finances. Let’s say you build an app for quickly visualising user input data, comparing it and finding a most critical situation for the project. Next to this, you build the option to automatically generate input files and run calculations with this most critical situation. Now you might have users that are fine with just comparing input data and determining a critical situation and users that want the full usability to also generate and run input files. The workspace to just visualise and compare your input data would then cost less internally and is therefore attractive for small projects whereas the full usability comes in handy for big projects where an expensive app is fine given the total budget of the project. In this case step visibility would need to be able to be toggled per workspace (unless you release two apps which is also possible) for which environment variables on workspace levels would be necessary.

Another use case, which is also the use case for hiding views, is when entities are used in multiple apps. For example an entity in which the total amount of material for the project is calculated, corresponding costs and nitrogen emissions in nature areas. We might have a project where in an early stage different solutions need to be weighed for which the amount of material required is the most important, or a project that is not close to nature areas so nitrogen emissions are not applicable. In this case not all functionality within the entity is necessary in the app but code structure wise it is the easiest to build one impact on surroundings entity that is located in a shared repository. If the different results are calculated in different views you might want to hide certain views to keep the app simple for the user to use. If the different results are calculated in different steps you might want to hide a step. This can also be used for internal financing like the first use case I gave.

I hope this gives some insight in the use case I am thinking of. Maybe other people have examples (better ones maybe) as well.

8

Thanks for the elaborate answer @Rutger!

  • if i get this right your first usecase (limit functionality and hide views) only works if we would have workspace env vars. is that correct?
  • what’s the main downside of the “two apps” approach? that seems like quite a good solution (which is currently possible). a potential problem i see with using step/view visibility for this is that this is only visual. you could always call the endpoints that are hidden (although it would necessitate using the API, which most users wont know how to). separate apps give you are more strict separation.
9

One nice thing about the current implementation of the steps is that the user has an idea at the beginning what steps are coming. If a parameter change would trigger removal/addition of steps (with accompanied numbering change) this could become confusing.

This could be solved by making steps inactive instead of fully hiding. That way you still keep the same number of steps and know where you, but improving the navigation.

As an example

  1. Project parameters
  2. Location parameters
  3. Geometry parameters (optional)
  4. Loads parameters (optional)
  5. Report

Lets say for certain projects, step 3 and 4 are not necessary. We would then grey these out and clicking next on step 2 would navigate the user directly to step 5. (and clicking previous on step5 would lead to step2)

Discussed this already with @wouterhouzr separately and this seems a good fit for openred, curious to hear from others

10

I think greying out steps is a good alternative to hiding them!

I would say the downside to the “two apps approach” is that if you want to keep your functionality contained to one entity you need to somehow make sure that certain parts of the entity are available in certain apps. For turning views on and off you can create a generic Parametrization class and then edit it in your main repository. Alternatively you can comment code out before publishing your app. Administratively this poses a challenge to keep the code clean. With visibility this could be done with one statement visibility = visibility_view_a. This however would also require workspace environments.

Personally, I don’t think the fact that with the API you can still access the invisible views or steps is not that big of a problem. On average the users who know how to use the API are skilled enough to not accidentally access invisible views or steps.

11

We had some use cases for dynamically hiding a view a while back:

  1. We have a Gef entity type, used for both CPT’s and BoreHoles. To visualize the soil layout, we used different approaches. One leverages Viktor’s matplotlib visualiser; the other a custom Plotly figure.
    That meant we had 2 views, and the user had to select the correct one. Not user-friendly and cumbersome. It would have been nice to signal the platform that one view schould be hidden/disabled/…
  2. In another app we have different views (and view types) for showing bearing and tension results. But when the user select to only calculate one of then, that view is useless.

btw: we solved the first by converting both results to their html component and use a single webview. But that’s extra code and not really friendly for new developers.

1 Like
12

we have created a separate feature request for the visibility of views: Set visibility of Views

13

I have renamed the feature request since we are heading in the direction of disabling the steps instead of completely hiding them. Could be that we will later also add real step visibility

14

Moved status to “in-progress”. This feature will likely be available in a few weeks

15

Disabling steps has been released :tada:

The following docs section explains how to implement this in your app: Layout & styling - Steps | VIKTOR Documentation

Interested to hear about your experiences @LM_Vin , @Rutger , @sjoerd.hoekstra.tauw , @Pim.TAUW , @Vincentvd , @rkg , @Wichard , @kassi , @Marieke , @Floris , @marliesbuijs , @ColinGroenHouzr , @wouterhouzr , @laurensk , @MYY , @Enrique

3 Likes