|
William, I use a session scoped CFC, an "AdminManager" with a getter and setter to track the return url in a particular app we've built, but in this case, the starting point is clearly defined. It'll only bring them back to the starting point when in their editing process they wander around in the back end. setReturnUrl() getReturnUrl() I find that to be enough, but this seems to much more simple than what you're aiming for. Lemme take a different perspective for a moment. Taking into account your proposed requirement that the app should be able to handle interruptions, what would your solution look like to the user? Would they have a button or a link that says/implies something to the effect "Take me back where i was and restore the application process to the state it was in when i got interrupted"? Would you put that "Take Me Back" button everywhere (because how would you know in advance from which view in the application a user would want to go back to where they left off)? How would the application "know" what an interruption was? Or when it occurred? Or would you want to present the user a series of Undo type history links that would each restore the application to the state it was in up to say 15, 20, or 30 clicks ago, depending on how many undo steps you preserve state for, and let the user decide where they were interrupted? How would you log and then display those steps to the user so they would make any sense to them? How does a program like Excel, for instance, handle an interruption when the user doesn't "take responsibility for it" ? A simplistic example: Let's say i'm in the middle of entering a complex formula and get a phone call asking me to take a look at another worksheet in the same Excel file. Would most users expect the program to be able to return them to the midst of entering that formula? Or would they expect that they would either need to complete their process before going to another worksheet, or choose to abandon it? As a user, i know that if i interrupt a process in the midst of completing something, i can't always expect the computer to be smart enough to cover for me. In fact, i expect the opposite. As an interface designer, i know that any solution i come up with for this edge case of "getting interrupted by a phone call" is likely to be more daunting or error prone then simply letting the user start again. I also know that i shouldn't be designing the app to be highly usable around edge cases. I should concentrate my usability efforts on the stuff users commonly need to do. That's not to say you can't save state at specific points mid-stream of a process ... i'm thinking of a wizard and every time a user clicks on the next button, the state is persisted, at least in memory. But returning the user where they left off is problematic in my opinion, because something needs to decide where that point is. If it's the application itself, it's going to be complex to program and error prone. If it's the user, they'll be confronted with a history list and it will still be complex to program because the app will always need to save state for every point on that history list and be able to restore to that point. In a graphic design program with drawing tools, a history with multiple undo's that allow you to restore to any point can be a very valuable asset, because users are constantly experimenting. But from what you've described, that ability seems much more like an edge case to me. And it's a web application, so users can't quickly click around in the history to find their place. Each click is necessarily a page reload. So a history option is not nearly as usable in a web app as in a desktop app. I'm thinking you should just let the user be responsible for this edge case. Sometimes, that's easier for the user than anything the application could do to try and manage it for them. They'll need to find their own way back to where they were in the process, or start again if they don't take responsibility themselves, complete the process and "Save". And i'm also thinking that if you remove this edge case from your requirements list, a simple solution might be more within reach. Was that helpful? Or am i completely misreading the situation? :) nando William Langshaw wrote: Yes, a Rules Engine is the Enterprise, heavy-weight approach. I am |
- [CFCDev] Workflow management William Langshaw
- Re: [CFCDev] Workflow management Nat Papovich
- Re: [CFCDev] Workflow management William Langshaw
- Re: [CFCDev] Workflow management Tom Chiverton
- Re: [CFCDev] Workflow management Nando
