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]On Behalf Of Mike Kear
Sent: Wednesday, October 26, 2005 10:21 AM
To: [email protected]
Subject: [CFCDev] Making changes before a commit buttonI'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]
