Hello,
I always wondered, why is “Back” action missing in workflows? Is there any specific reason to not allow user to go back and edit previous screen? Sometimes clients seem to be dissapointed that this regular feature they are used to know is missing.
Another UX issue is that repeating workflow clears all data and starts a new one. Users are expecting to start with same data they entered before. I know “Repeat” action is for repeating, eg. start it fresh again and user can accept this explanation but I feel it is somehow connected with missing “Back” action that they expect this behavior.
Can we discuss more about improving workflow to allow user to go back? I know there are hidden tasks between screens, so it is not as simple as “okay go back, just reset context stores and continue as usual”, but still I think it is worth considering. New users in Origam tend to make mistakes and they are not happy to fill everything again (sometimes the forms are large, eg. Communication).
You are right that it is not easy to say what should happen on Back because the sequential workflow just goes forward.
Actually I think it was not the very best decision to add screens into sequential workflows but it was our way how to implement wizards back at the time.
I think more correct would be to actually create a special model for modelling “screen-flows” that would allow complex interactions just between the screens with possible ways on how to get back. So again, I don’t think it would be correct to try to implement something in a sequential workflow itself.
But there might be a way, although a with a lot more work than what you currently have to do in a sequential workflow:
Create each screen as a sequential workflow with a final screen
Connect these screen using UI Actions with closing the original screen every time.
This way you should actually be able to get a working “machine” where you could model any direction (you could easily go “back” to the previous screens with the correct UI Actions).
If you would create a sample project with such a workflow and post it to a public GIT repo, we could have a look and see if it is something useful and could be integrated better into ORIGAM.