This suggestion is coming straight out of a use case that I have not found a scalable workaround for: So in the honor of this old school problem the theme of the app is in Windows 3.1 Hot dog Stand!!!
Layout you have an app that you might break off mid process (think assembly) as with this type of Job we use the Job # to track where we are in the process:
Later on the parts come in and you are able to go back in the process so you go to the start page and enter the job # and click the got to last step button ( (Trigger argument snip):
Now say you want a refresher of the previous step before this on so you click the previous button but instead of going to the previous step in the app tree it takes you back to the first step in the app
So here is the suggested improvement:
Please add in the options for step drop down:
No update on this guy yet. You can always store the last step name to a table, but this has limitations (like this approach wouldn’t work to go back 2 steps). We can make a quick demo of how that could work if you are curious.
One thing that complicates this some is step groups. Would you expect this action to go to the next step up skipping the step group or not?
What about if the step group is minimized in the editor? Effectively, these are no different, but could cause some confusion for a new user.
I think the visualization of steps in a linear order is an artifact of where Tulip evolved from as much as anything else, but its something we should provide the tooling to better leverage. I will bump the feature request and understand if there are technical reasons this is more challenging than I expect.
I believe I was the one working with the OP that led to this post/suggestion. The suggestion you make regarding saving the last step to a table is partly what causes my issue in the first place. The other example I run into is jumping to a “reference step” (such as typical torque charts, acronym definitions, fluid levels, icon definitions) which may be referenced by several steps throughout the app. Jumping to this “reference step” then back into the workflow requires that I now individually program each BACK button in the app to go to a specific step. This also limits the flexibility of rearranging the app if/when necessary.
I guess I am a little confused about your reference to the Step Group. The Go To Step NEXT trigger does not consider if the next step is in a different group or if the group is minimized in the editor. It proceeds to the next step in the step tree. So I would assume an option to Go To Step PREVIOUS should react similarly. The current function of PREVIOUS is not the inverse to the current function of NEXT. I do think both interpretations of PREVIOUS are valid however (last active step & previous step in step tree).
Is there any update on this functionality? Would be very useful to declare a “Previous” button once in the base layout rather than having to statically declare each transition for each page with a previous button.
Hey @dsun, thanks for reviving this thread. I want to tag my colleague @jakerigos into this conversation. We’re looking at work for improving the transition experience later in the year and I think this thread is a good summary of some of the difficulties folks are having with the current model. If you want to share more about your use case or if you have questions he’s a great resource.
