I recently had to write a web-app for a client that involved providing an audit interface. the audit is a long, time consuming, multi-page process. The requirement was that if the user's machine dies while in the middle of the process they should be able to log back on and they can pick up right where they left off.
The only full solution to that was to use an "ajax" solution that saves everything as they go. Obviously, not the most accessible solution as far as users with javascript disabled - but JS is a requirement for the app due to their JIT saving requirement. I don't know if this will help your situation at all but it is another approach. Bill On 10/26/05, Nando <[EMAIL PROTECTED]> wrote: > > Do you have 2 different "Save" buttons for the user? > > Effectively > > "Save Temporarly So You Can Continue to Tinker" and > > "Really Save"? > > Or do you have a multistep form? > > I know it can be a little difficult in the case of certain multistep forms > to decide whether to commit the changes mid-stream. What if the user gets > interrupted by a phone call, for instance? What would they want when they > come back to the app after an hour and 30 minutes? That their changes have > been committed for them or that the app blinks at them and says "Sorry > buster, but your session timed out while you were ambling down the hall to > lunch after that phone call of yours. Whatever you entered is gone." Or what > if they just want to look through the process to see what's there and Cancel > out of it. > > What we've done is to put ourselves in the user's shoes and think carefully > about their intention and goals in using the app, in the situation they'd > likely be using it in (like a busy, distracting office). Sometimes, we've > committed multistep processes on each screen change. The big SAVE button > underneath is just to give the user a sense of security - a Save button to > click when they want to. Sometimes we've not committed the changes between > certain steps when it seemed like it would be more important to allow a user > to cancel a mistake and get out of the process. But it's depended highly on > the context. > > I find it rather easy to decide if i really put myself in the user's shoes > and let their goals be the deciding factor. Sometimes that runs contrary to > what i would think would be most logical as the programmer - but i've run > into enough programs in my life as a user where i wanted to throw the > monitor out the window in frustration to know better. > > I kind of like Barney's idea of an uncommited flag, but where does that > leave me as a user if i miss or misunderstand the commit button? I think i'd > like that it just works, and that i don't have to make any logical choices > imposed by the program. The uncommitted flag could be a part of a solution, > but not all of it. > > Sure, you could explain the logical choice to me and its implications in the > interface, but i don't want to have to read that and think about the > difference between Commit and Save each time with my finger hovering over > the left mouse button. I'm supposed to be using the application, not acting > as a part of it. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Mike Kear > Sent: Wednesday, October 26, 2005 10:21 AM > To: [email protected] > Subject: [CFCDev] Making changes before a commit button > > > I'm feeling pretty proud of my self today - for the first time, I wrote, > unaided, with no safety net, a small app, which uses a CFC Bean to handle > the variables in the object, then a CRUD.cfc to insert the details to a > SQLServer table. This app doesnt do much worth anything, except prove to > me that I have learned enough that I can write using this OOP method, > without copying off other people's stuff. This is a MAJOR milestone for > me! > > Anyway, the way this app works is that a user is presented a form, can make > all the changes and tweaks he wants to the details before finally committing > the details to the database. The bean cfc contains all the data while the > user tinkers around with it, then passes it to the CRUD.cfc when the time > comes to commit the data to the database. > > So here's a potential problem I haven't put a lot of thought into before, > but must have been dealt with by others, and now i realise it's really vital > to solve: > > [Q] How do you ensure that the user clicks the "commit" button before > leaving the application? There would be a risk I'd have thought, that the > user can complete the forms, tinker around with the data getting it right, > thinking it's been added to the database, but it really hasnt. It's still > in the bean cfc waiting for the user to commit it. (If it was a simple > form, i would make the submit button commit the data to the database right > then and there, but the kind of app I'm thinking of using this process is > where there is quite complex interrelated data to deal with - such as a page > definition in a CMS or multi-stage wizard form where the data required in > one part depends on what was supplied to another. ) > > > I know I've seen these kinds of apps before, but never thought much about > what was going on in the background before. > > > > Cheers > Mike Kear > Windsor, NSW, Australia > Certified Advanced ColdFusion Developer > AFP Webworks > http://afpwebworks.com > ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
