13 reputation
2
bio website
location
age
visits member for 2 years, 4 months
seen Jul 22 at 19:31

Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
@superduperfly The implementation of a "transaction" doesn't necessarily need to be a true transaction. It could be a record (or set of records) in "pending" status - you still persist data to the database so the user gets the security of not losing anything but it also give them the ability to re-start from scratch (by dropping out all "pending" records). This was the point of my response to Robert Harvey - we assume the users simply can't stand to lose "that much" data, but how many times and in how many ways do we really need to ask someone if they are sure they want to continue?
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
@André This crossed my mind as well, and what I was alluding to in my responses to Mike and Robert Harvey above. Think of an application like Word - you can lose a LOT of work that can all be lost by clicking "No, I don't want to save" when exiting - Word gets around this via autosave/recovery. If the data is THAT important and/or time-consuming to enter that it simply can't be lost via a single action then the application should account for this requirement (in a manner that doesn't get in the users' way).
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
@superduperfly Let's just say where I work some of the project managers like to design in a bubble. In this case, I asked my co-worker what the users thought of the interface and they showed me a sample screen that looks nothing like the current iteration; the users have signed off on what was proposed to them but haven't seen what's actually being implemented. This means that a lot of our developers' designs become a "best shot" at what we think the users will like/want. I've tried changing the mindset to encourage more end-user interaction, but have failed so far :(
Jun
29
awarded  Student
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
Out of the answers provided, this seems to make the most sense - there are times where this approach may be the best, but the interface should always be clear about what's going on. Right now, my concern is that it isn't clear and the users (notably the CEO, President, and Board of our mid-size company) will end up fighting with the interface instead of getting their work done.
Jun
29
awarded  Scholar
Jun
29
accepted UI Design / Flow - what should “Save” and “Cancel” do?
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
I understand your point about accidental data loss, but I wonder if we sometimes hold the users' hands a little too long. I agree that many grid-based entry forms are implemented as you describe...but it seems like a lot of times users will accept what they're given to use unless it is extremely user-unfriendly. I mean, we're not all user experience gods, but the first answer surely shouldn't be "I've got a grid for that". In any case, I think Mike hit the nail on the head - it's not so much a bad overall approach as much as the intent isn't very clear.
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
One example (not this application, though) would be a statewide system for annual financial reporting - basically take a 17-page financial report on which a municipality or county must provide details about their income and expenses and put it on the web. The UI should be designed so that it doesn't make data entry any more laborious than it already is due to the sheer amount of data involved (~1000 points of data). I think clicking back and forth between pages would getting annoying somewhere around the 90th line of data on section four...and only four more sections to go! ;)
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
The (internal LOB) application in question is dealing with tabular data that needs to be looked at and manipulated as a set. I'm also not one for in-line editing in tables, but in my opinion there are definitely times where it is not only permissible but necessary.
Jun
29
comment UI Design / Flow - what should “Save” and “Cancel” do?
What is wrong about wrapping all of the edits in a transaction (not necessarily a DB/distributed transaction, but using some sort of marker for what needs to be committed when the user clicks "Save")? It sounds like this is a case of differing POVs - I see the form as a set of actions that should be handled together, while you and my co-worker see them as individual actions that aren't necessarily related. Maybe this even calls for different button placement/notification much like what Mike suggested. Does that sound like a fair assessment?
Jun
28
asked UI Design / Flow - what should “Save” and “Cancel” do?