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:
When you click the next button It creates/loads the job # to a tracking table:
Say we get 4 steps in the process and have to break off due to parts availability:
So we click Log out (Trigger argument snip):
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:
add Previous Step In App tree (this should be an option in the go to step and Next Step drop downs as well)
the reason is 2 fold
- it gets rid of the loop
- if steps are added in future iterations it allows for better scalability & flexibility
So if you don’t want anymore Hot Dog Stand themed apps ( or if ya secretly do) please take this suggestion and make my dreams come true!
Stay awesome gardeners!
Best regards to the righteous community!!
Clear Process Solutions
For the Tulip engineers Links to app and table:
Hey @CPS_Chris_Winters !
I already see that you have submitted a feature request!
The product team will evaluate this and we will be in touch!
@CPS_Chris_Winters Thanks for the suggestion and the great example app! We will consider adding this option
Any updates on this topic?
Hey @jboyle -
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.
Thanks for the response @Pete_Hartnett
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).