On 4/13/05, Mark Stanton <[EMAIL PROTECTED]> wrote: > Hi Peter > My gut reaction is that you should not be saving form state when a > user presses a button labelled "back". I was having trouble thinking > of why I felt this way when you first posted your question, but I > think its a bit clearer now. > When a user comes to a form they assume a few things. For example: > - When they move a cursor into the a field and type their text will > appear in the field as they type it > - When they press the tab key they will move the next field > - When they press the reset button all the changes they have made on > the form will be cleared > - When they press submit their entries will be sent to the server > - If they move off the page in any other way their entries will NOT be sent
Partially true, keep in mind if we lived in a perfect world where all web-based applications focused on that rule alone - i'd 100% agree. Sadly, we don't and its a common mistake to be had. > This is pretty basic behaviour that we have all come to expect on the > web. By having a back button that takes them to the previous page AND > saves their data you are breaking away from the expected behaviour. It > may seem that you are enhancing the user experience but my gut feel is > that this enhancement is not worth the fact that you are doing > something that the user does not expect. > > Once users see this behaviour I think they may assume that the form is > somehow magically saving their information as they enter it. This > could lead them to expect their information to be saved regardless of > how they leave the form. How does your average user see the difference > between the browser's back button and your back button? > > I guess I'm worried about you lulling them into a false sense of > security and that this will lead to a negative experience in the long > run. Try not to worry, if your consistent in your approach you are by my rules safe. I mean how the hell did we know the "Start" button in Windows meant a menu? How did we know that double clicking on an icon opens up a program. Consistency is the key element and small amount of training isn't a tragic ask to place on a user. Just don't make it freakin hard to connect the dots. I urge you all to sit down one day in front of say a call centre application or green-screen application. Then come back and preech to me usability laws 101. > Could you possibly have a button that explicitly says "Save and return > to previous screen", but that is a bit of a mouthful. > > Mr Barnes will sledge me for this, but I think about 90% of interface > design is making it work in the way the user expects. The other 10% is > being creative within these limits. If you are Apple you can break > these rules, but if you are developing an application that serves a > business purpose you shouldn't. > > Let me know what you think. I think your an ass hehehehehehe... no, I agree with what you are saying and understand your approach. Yet i think the assumption would be valid if this were a world in which all followed rules of useability and laws that come with them. Yet they don't so the end user expects one thing. "how does this web app translate to my nomiated operating systems approach". Usability and keeping it simple are my pet hates. As its easy to just go down the path of "well its simple enough process, lets not rock the boat and keep it simple". There is that and it has value if your target audience is monkeys who mash keyboards for a living. That being said, you can go that extra mile in terms of Business applications so long as you are consistent in your approach. If you put together a UI that has a radically new way to tuck stuff away, implement it but make sure its useable and doesn't change every screen you place it in. eg: OSX brought out a way to traverse your hard drive via a vertical accordion style approach. In that when you go from parent to child, it steps down a branch but doesn't show you a tree at all? in fact its keeping your primary focus on the container you are looking at. http://www.spidaweb.com/Screens.jpg - Illustrates a panel tucking approach. Experts will say "Tree format tree format!" as thats the Mr Usability "Guru" N. says. Personally i think he is infact an ASS at times with the crap he comes up with. I use it in FLEX and users find it easy to navigate with. Yet another "no no" being proven wrong - i have countless more. People aren't morons and if you feel that the application can benefit by having a keep-state concept, then apply it. Pressing BACK implies "going back one step". That bloody Back button has had so many combinations of the way it works, then if you were to hijack its concept for a multi-step form, then so be it as you can't possibly sit there and argue its main purpose in life is to go back and reset. Its got so many changeable behaviours associated to it simply by other developers around the world using it for different purposes that in many ways a user tends to rely on inline navigation elments then they do via the browser. If its a static website, then yes they tend to use the top tier back/forward approach. If its a business application then it should by rights be removed period. Its a useability flaw in web-based applications and i've seen countless scenarios and approaches in how folks interpet that button. imho. State should be kept in a multi-step form provided it's sequential steps aren't dictated by original actions. In that, step1 a user clicks a certain checkbox, which triggers how step2 will be displayed. To me thats a no no, as you're now changing a users personal memory as to them they only forgot to fill out a username or something trivial, yet they aren't aware that if they change data in a certain way the follow-on steps radically change. If its plain sequential data much like the ye ol Macromedia Accordion Control, save away. If its not, at the very least inform them that if they go back in anyway "they will loose current data". Useability isn't about do's and don'ts, its just communication. Communicate to the user if a negative occurs. Politely inform them if a postive occurs. its simple process. -- Regards, Scott Barnes http://www.mossyblog.com http://www.flexcoder.com (Coming Soon) --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
