Fog Creek Software
Discussion Board




More forms = simpiler User Interface?

In a recent discussion here I mentioned that I had a 160 forms in a relativity small application. (ie: only 26,000 lines of code, but 160 forms).

One poster observed that 160 forms seemed like a  LOT of forms for a application that is not that large. In fact the resulting application (in ms-access) can be zipped on to a single floppy disk).

A question was raised to the effect of how can usability be kept high in such an application with that many forms?

Hum, good question!

I believe more forms makes applications easier to use. The reasoning for this is that by breaking up a task for the user, the software leads and guides the user to complete a particular task. I have always maintained that good software is task orientated. If you present the user with clear and a concise form that asks for a particular task/info, and then move on to the next task, then the software becomes VERY easy to use.

If that series of steps is carefully designed, then you actually don’t increase the number of mouse clicks, or key strokes by any significant amount. The end result is that the user is only presented with relevant options to the task at hand. The result is intuitive and easy to use software.

The only real downside here is that the cost of the software increases since then you have to build more forms. While this breaking out task does sound a bit like a wizard, I can’t really say that they are one and the same. The main difference here is that a wizard forces you to the next step. With mentiplate form, you are not always forced to the next step. We simply reduced the amount of options that are presented to the user at a given time.

The reason for reducing options is not to dumb things down, but to present options that MAKE SENSE and are connected to the given task.

The big challenge a new user has is to build a mental picture or model of how things are to be accomplished. The “relation” between options on a screen tends to be the big problem. If you present a bunch of UI controls on a screen, and they are NOT related to the task at hand, then you confuse the user.

A most simple example of this approach in action is my security screen. For some reason many people find the concept of users, and user security groups very difficult to deal with. In my case, we are talking about ms-access security here. However, this security model is the same as users and groups security for any modern system (be it sql server, or users on a network). So, you add users, and then you add users to those security groups. Why is this concept so confusing?

Users find the ms-access security manager is VERY confusing. Heck, even I do! The reason why it is confusing is that the user is presented with both security options and the ability to add users at THE SAME TIME. The simple solution here is to simply to break out the assigning of security groups to another form. This simple breaking out of this task into two forms and seperate tasks makes this whole process dead simple. The reason for this is now you have a screen to view users, add users, delete users. Now, the user builds up a mental picture that this form and location in the software package is where you deal with users.

When you want to set user security settings, you go to the users screen (and that will make sense to the user). Then, ah ha...there...a security setting  button for the user. Poof, we now give the user a new screen with options to set security for that one person. Not only is this much simpler, but it also gives the user a sense of closure . You view  a user, then set security for that user, you are done. Now work on next user.

With the existing ms-access security manager, you can view, switch and toggle security options all on the same screen. In fact, it becomes VERY difficult to know if you have changed security settings for one user, as you can then switch to another user (there is no closure). Futher, the user has to make the mential connection between what user is displayed in the combo box, and the two listboxes on the bottom. Some things on the screen may, or may not change when you changes users.

Here is a picture of the access scrity screen I am talking about:

http://www.attcanada.net/~kallal.msn/RidesSec/secacc.gif

Here is the the two screens I broke the above into:

http://www.attcanada.net/~kallal.msn/RidesSec/index.html

Microsoft even has an article on this:

Microsoft Inductive User Interface Guidelines:
http://msdn.microsoft.com/library/en-us/dnwui/html/iuiguidelines.asp

Upon coming across this article, it did hit a note with me, since I have been doing that with my software for many years.

Does anyone else use more forms to reduce complexity for your users?

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Tuesday, June 17, 2003

An earlier thread about the Inductive UI - mostly me diatribing.

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=6949

I eventually distilled these posts into an article I put on my website.

I like your 2 forms better than the 1 form.

www.MarkTAW.com
Tuesday, June 17, 2003


Have you read Alan Cooper's "About Face" (there's a v2.0 out now). One of his points that I've found most valuable is that designing for new users may not be the best idea.

The point Cooper tries to make is that no one wants to be a new user. People will either stop using the application or move on to become intermediate or advanced users. When that happens many of the things you may have implemented to help new users may then actually start to get in the way.

I totally agree with your goal of working towards a simpler user interface and with many of the things you've said, I just wanted to point out that simpler does not necessarily mean tuned for new users.

DingBat
Tuesday, June 17, 2003

In that particular example, I think you've imrpoved the form (but you need Update & Cancel buttons on your security settings form)

However, I'm finding that in general people do NOT want smaller forms - they want everything on the same page. For example, with your form, if you could figure out a way to put each role as a column on the first form (and keep it readable), your users would prefer that (I know I would).

Philo

Philo
Tuesday, June 17, 2003

This is one of the reasons I wrote the Five Worlds article.

Albert is working on vertical, industry specific software, it's a lot closer to internal corporate software than shrinkwrapped general purpose software. That means it has a lot of database stuff, and everything in the database needs a way to access it from the UI.

Typical GUI shrinkwrapped general purpose software like a word processor or web browser or game does not represent a view on a database, and needs far fewer dialogs. In Firebird the only common dialog boxes I can see are the superstandard open/save/print/find provided by windows. It looks like the only custom dialog box is Tools|Options which has a few subdialogs.

Joel Spolsky
Tuesday, June 17, 2003

If the reply was to me, I was addressing Albert's statement that he was "breaking apart forms" - doesn't matter what industry, I'm finding that people tend to prefer working on a single form for a single function.

Now if the forms started as an amalgam of functionality, then yes they may need to be cleaned up. But breaking them up for the sake of making them simpler? I'm not so sure *anyone* wants that.

Of course, I could be wrong. :-)

Philo

Philo
Tuesday, June 17, 2003

We have supported call centers for a number of years and you are describing what every call center goes through when selecting application software. 

A large, scripted interface allows the widest variety of people to use the system.  If the approach is always the same, regardless of the task, then this approach is great.  This is also great for the unskilled user.  By this we mean one where turnover is high to very high.

Where the issue arises is when you have a set of tasks that could be accomplished much faster, by a power user, if all more related data elements were available at once.  These systems are complex, but offer a high completed transaction rate once mastered.

In some cases we end up with a hybrid with a "short path" for power users and a "scripted path" for new users. 

In the end, if you have built to your user base, you cannot be wrong.

Mike Gamerland
Tuesday, June 17, 2003

Some years ago, I worked on application where users had to enter the data in a really big form (data entry) over up to 5 pages.

They complained

We rewrote the application to make it a scrolling-form (which was really VERY VERY hard for reasons I won't go into). 

Others users then complained they didn't like scrolling

S. Tanna
Tuesday, June 17, 2003

[One of his points that I've found most valuable is that designing for new users may not be the best idea.]

That's really the crux of the matter.  Are you shooting for your typical iTunes user (ie, no manual, jump right in) or VIm (ie, hardcore user that will take the time to learn the nearly esoteric commands that makes VIm powerful)?

If you've got an application that needs 160 forms, you're not shooting for a newbie.  A learning curve is allowed, I'd have to assume.  Either remove features -- and forms -- or allow yourself a break and make what's most efficient.

Note that putting forms together doesn't "by definition" make a more efficient GUI!!!  Use the software, pretend you've had a few hours to get used to the form you're working on, and try entering/editing as much information as quickly as you can.  Use it a few days, like your user would (you'll probably do this testing it anyhow), and add those shortcuts.

It's no surprise Microsoft has such an article.  Compare the features in Word to, say, OS X's TextEdit or compare even Windows Media Player to iTunes.  Both in both are great products, but appeal to very different audiences [and tasks].

The guy at myfreakinname.blogspot.com
Tuesday, June 17, 2003

26,000 lines of code is small? :)

That's a pretty significant chunk of code for one person, IMO. 

Anyway, sometimes breaking interface components out into extra frames or forms is the answer.  But I think layout of the interface is more important.  Does the interface "feel" natural?  If the flow doesn't feel right, then not even breaking something out into many forms will help.  The user may now get ticked that it now takes 8,000 screens to do what they used to be able to do in 4.

Crimson
Tuesday, June 17, 2003

> try entering/editing as much information as quickly as you can <

That's the crux of the matter. I started uploading images to one of those CafePress stores, and once I started adding products I got quickly frustrated by the process. Too many screens.

1. List of my items, click "add an item"
2. then I get a list of items, click on the item I want to add (a t-shirt)
3. Add front image, click "select image"
4. I get my list of images, click the checkbox on the image I want and click "select'
5. the t-shirt. Select central or pocket image. click next. Here's where it really gets frustrating
6. the back of the t-shirt (repeat steps 3-5)
7. choose price & color. Click "save and finish."

Clearly this wizard-style interface was designed to make the process as easy as possible, but as an advanced user, I'd like to be able to do this with fewer clicks and on fewer pages.

The same goes for my e-mail account, Mailshell. You get an infinite number of disposable e-mail addresses, and their management screen used to have a table with the e-mail addresses on the left and a drop down on the right. You could change the rules for all of your e-mail addresses on one page, it was beautiful.

Then one day they changed it, and now I have to click on each e-mail address to get to the page with rules for that address. Changing each e-mail address' rules went from selecting a dropdown to clicking a page, waiting for the next one to load, changing the rules, clicking save, going back to the main page, and so on. Frustrating.

Once I've been through the process, I should be able to turn off the "wizard' interface that walks me through the simple stuff and get to the more powerful interface. Once I've had an overview, I should be able to do anything I want simply and not have to re-walk through the wizard.

www.MarkTAW.com
Tuesday, June 17, 2003

The two examples you give are bad because they are web interfaces and loading can be slow.

On a desktop loading should be near instantaneous. I would say that three or four things to fill in on each screen would not overtax anybody.

Stephen Jones
Tuesday, June 17, 2003

Why would you do such an app in access and not VB?

VB would scale a lot better.

Smurf975
Tuesday, June 17, 2003

First, 26,000 lines is small. I'm 1 developer and I wrote and maintain 1,500,000+ lines of code. :)

As for the forms issue, as with most things it depends.

I would say that 160 forms is a bit much. While it does make each form easier to comprehend, it adds to the overall complexity of the application. To put it another way, the user will have difficulty finding a specific feature because he/she cannot remember where in the 160 windows that feature lived.

I'm with Philo on this one. It is better to have a single window that contains a single feature set. So the breakup is then much more logical. This logical separation will help the end-user quickly find a needed function while still keeping the end-user focused on the task at hand.

As for being "task" based, I very much agree. Your user is looking to accomplish a task and it is your job to automated that task.

This is one of the reasons I think Word is an extremely great work processor but a horrible business tool. It has so many options that you can literally spend a day setting up a document and never write an actual word. It is almost too flexible. It only becomes useful when a developer steps in and automates it to handle a specific task.

Marc LaFleur
Tuesday, June 17, 2003

Stephen - very true.

I'm browsing around my computer trying to find an example of a UI where you're expected to update information across several screens and I'm having a hard time finding one... Maybe it's the software I gravitate towards, or maybe it's the state of software design. The closest I can find is a couple of tabbed interfaces, but nothing that forces that level of linearity on you.

Take for example Trillian. The connection manager has a dropdown to choose your IM service (AIM, ICQ, Yahoo! MSN, etc.) and on the same screen your ID for each and password. Nothing asking me "add an ID" "edit ID." Everything is on one screen.

The Add/Delete Buddy Wizard (they do call it a wizard) is as close as it gets. Select the folder & IM service on one sceen, and add your buddies on the next screen. The reason for this is that each service requires very different information.

www.MarkTAW.com
Tuesday, June 17, 2003

Marc LaFleur wrote :
>I'm 1 developer and I wrote and
>maintain 1,500,000+ lines of code. :)

Interesting use of the :) emoticon - as an operator that means, 'The preceding is the raving of full blown monomania.'

Thanks for pointing out that you are not more than one developer.  Very forthcoming.  (Full disclosure: I am also only one developer.)

Should I laugh or worship?
Tuesday, June 17, 2003

Dear Smurf,
                  Why do you say that doing the app in VB would scale much better? Remember that Access is being used as a programming interface. You can use Access to write for Oracle, and after Oracle Developer it is the second most common tool used for this. As for why use Access, the answer was given by Albert. It's probably three times qucker to write the equivalent functionality for database apps with Access as it is with straight VB.

Stephen Jones
Tuesday, June 17, 2003

1,500,000+ lines of code huh?  Thanks for rounding. 

If you are only one developer, how many other developers are there in your land of lala?  Will you tell us next about the Unicorns and the rolling green meadows that are pictured in the default Windows XP background? 

Christopher Hester (One Developer)
Tuesday, June 17, 2003

Since this discussion is drifting off-topic anyway, I'll keep it moving steadily away from GUIs to the "Lines of Code" question:  Does everybody generally agree on what LOC means?  I do algorithmic development for engineering work that, then, is processed graphically.  I can spend a morning sweating over just 4 or 5 lines of a particularly nasty algorithm.  On the other hand, can this be compared to 50 lines of:

// Print MyString
cout << MyString << endl;

and so forth??  And if I copy some UI code from one spot to another and make minor modifications, do I get "credit" for all of those new lines?  And what about if I factor out a lot of lines with a new function call and SHRINK my LOC total, do I have to give money BACK to my employer for producing fewer LOC??
  Somebody straighten me out on this 26,000 : 1,500,000 LOC debate.

Barry Sperling
Tuesday, June 17, 2003

...and Barry nails why "lines of code" are worse than worthless for measuring productivity. [grin]

Philo

Philo
Tuesday, June 17, 2003

As Philo and Barry point out, LOC is a worthless value. This is why I slid a ":)" at the end of that sentence (although in hindsight is should have been a wink).

1.5m LOC is of course rounded. I used a little program that simply counts the lines of code and it gave me 1,432,190 lines.

But WTF does that mean anyway? A large portion of that is comments and parameter spacing (I often break long parameter lists into multiple lines). Another chunk is code that my IDE generates automatically. So LOC is really worthless.

If I had to make a guess, the actual LOC should be about 500-800k. Definitely large, but a third of the total LOC count.

The problem is LOC is the most common way we "size up" an application. For some reason, we seem to think that it gives us an idea of the size even though we all know it means nothing.

Maybe we should go by amount of time it took divided by the number of developers? What about size of the installed application?

Or maybe we just shouldn't care because it doesn't really matter.  It isn't the size of your code after all, it is how you use it. ;-)

Marc LaFleur
Wednesday, June 18, 2003

I should add that the language is also a major factor here.

The LOC of a 3GL is a lot higher than a 4GL is most cases.

Marc LaFleur
Wednesday, June 18, 2003

>In that particular example, I think you've improved the form (but you need Update & Cancel buttons on your security settings form)

Hum, we might have to start a new topic on this! I want to stress that the following is not just directed to the above comment, but to my view that less prompts is better!

I don't believe in save, or update buttons. There is not one save button in all of those 160 forms. Save is implied in all forms. In fact, the only exception I can think is that password screen where in fact I do have a “click here to update”. However, that is to change a password, and I actually considered removing the “Click here to update password”. You just enter a new password and you are done! If they mess up, the admin can just go enter another one. In fact, since I don’t show the old password, then that is why I felt the update button was needed here.

I do have in the menu bar with the standard Edit->undo. (MIDI interface here...so all forms are like the rest of ms-office...no menu bars attached to each form...they are at the top of the main app window). For most data entry screens you will find the delete via Edit->Delete,  and of course Edit->Undo etc.  in the menu bar.

By the way, of course in addition to the 160 forms, there is the VB dialog box, and input box count that I did NOT include in the count.

Note in that security screen shot all user entries are editable. That means you can change the user name. The software behind that UserLogon box actually has to delete the old security user name and create a new one!. Of course, the user does not care, or have to know about deleting a old user. They just want to change the user name, and my software simply lets them! Again, this user model thing that the developer has vs the user is often wrong. Users don’t care about how computers work. Users don’t care that the security manager needs you to delete the old name, and create a new one. In fact, I don’t care either! However, the security manger in ms-access does require you to delete the old name, and create a new one! So, I hide this fact from the user.

9 out of 10 developers would actually put in a prompt:

Do you really want to change the user name?

Why do this? This is the programmer thinking about all those things that has to happen to change a user name. Who cares about the programmer? Again, this contributes a large amount as to why my security screen takes little, or no training to use.  If you want to change a user name, then go and change the user name in the box! (that is all this concept means to the end user). The huge dance of code that happens behind the form is NOT a concern of the user. No one will ever ask how do I change a user name with my design.

Further, I am mentioning this fact since one could argue why not break out the changing of the user name into several more forms to make this easy in place of my simple “just change the name” approach.

Answner:
    Because that would be a royal pain, and would only make more forms, and not simplify the task at hand! Just adding more forms to a task does not necessary make things easier. It is dealing with one task correctly that is the trick! It is presenting the user with one context and not a bunch that is the key here.

I am not saying that more forms necessary makes an application better. In fact, if you can  ELIMINATE several prompts and questions to the user, then you should!  I can’t think of a better example then how that security form automatically deletes and re-creates the user behind the scene WITH NO prompts to the user!

Even in the 2nd screen, you can just click on 3 security options, and then hit the exit button and you are done (again, no save button here, no dumb dialogs, no are you really sure you want to do this etc.). A mistake here as to what security options the user has is selected not too critical anyway. For the “remove user” button, that is different story. I do give one of those nasty do you really want to do this message!  I believe in confirmation for deleting things (especially when no undo can occur).

I wanted to spend a bit time explaining the above to everyone here. I really did take to heart Joel’s book on interface design. I DO NOT annoy the user with a bunch of extra little dialogs and small forms for no reason at all. I had a 100% get out of the users way “glide on the ice” attitude throughout the whole application.

When I could eliminate a prompt and nag message, I did.

In fact, after reading Joel’s book, I actually deleted some real nasty msgbox’s. I went on a witch hunt for useless dialog boxes.

I remember that day after reading Joel’s book, and I did the following:

For example, if you have 4 people in a hotel room, and you remove one person, a ton things happen (way too much to list here!). However, if that person you are to remove has NOT made any payments, then we can simply remove that person from the room. (by the way, often one person pays for all 4 people in the room, but often each make their own payments and get their own invoice...the system handles both cases well). Assuming you just removed that user with no payments, then if you search the tours file, that user WILL NOT appear in the tours list. However, the user name will STILL be in the main client file (all users are re-cycled, and only appear in ONCE in the main client system. I mean, this is a relational database....and if you gone on a past trip, then your address info etc is NOT copied, but is used via a relationship).

If the user has payment info, then we can’t simply delete the user from that booking. We actually have to generate a new invoice and move that user OUT of the booking (that MIGHT be bit of work for the users, and could be a nice series of prompts!). In fact, my users used to call this No man’s land! (great name!). The user is not booked to any tour or hotel, but is still searchable and viewable in the tours sections (has some payment info). The monthly sales reports etc will still register this payment stuff.

Right now, you can remove a user from a room with two mouse clicks. (all the cool stuff happens behind the scenes again). Two clicks handles all of the above problems.

So, the nice msgbox dialog that the users USED to get when removing a user with no payments was:

    This person did not have any payment information
    User was returned to main client file
    User is not in the tours file
      [click ok]

The idea of the above dialog box appearing after the ONE person is removed from the room was to avoid some confusing by my users (when, and when not will they go into no mans land). Ok, so now it is nice and clear that the user has no payments, and you will now NOT find that user in the tours section of the system anymore.

Anyway, after reading Joels book, I simply deleted the whole above dialog message (and also thus eliminated the need for the user to “OK” click the msgbox...again one less click!). I thought about this, and the above message really only serves to confuse the users. I mean, if the user has no payments, and you remove that user from the room, then why inform the operator that the user is no longer in the tours file? This again was my “computer” model VS the user model at work here. I asked what are the consequences of NOT informing the user of this behavior? I could not think of any!  I mean, if they search for that user in the tours section, they will NOT find that user. So what!...the user has no payments...so, who cares if you can’t find him anymore! He is gone!...this is no problem at all!

For sure over time, users will build a mental model that if the user has payments, then that user will be moved out to another invoice and will still be searchable in the tours section.

(you can’t delete users with payments).

However, we still must make removing them from that room a snap. Of course you are free to now move that person into another existing room (and his payment info will follow with that user, and becomes part of the total payments collected for that new room).

Further, you also have the case where no one is booked into that one spot, but payments exist for that spot! I would love to explain the cool business rules I have for that case, but this post is getting too long as it is!. Suffice to say that you cannot remove a booking spot from a room with no person in it if there are payments! You can however swap in a new user, and even keep the payments from someone else!

Suffice to say that I deleted a absolute ton of dialogs in reference to moving people around. The result is a amazing increase in ease of use, and less nagging of the users.

So, I do and did fight like dog to remove anything that is not needed. Every task has the ABSOLUTE min steps.

So, my point here is that more forms does not make an application easier.

What makes the application easier is that you group common tasks together for the given task. In other words, splitting one big form into many forms does not help UNLESS you group that split via common tasks. If there is 4 difficult tasks on the big form (and each has 4 things to do), then split it out into 4 forms. So, yea, you do get more forms, but each task can actually mean that user will not have to need training now, or figure out what options belong to what part, or idea.

If you look at the original security form above you have a “add” and remove button that shuffles things between two listboxes. Is that add button to add a new user, or is that add button to add something from one listbox to another? The user is required to make the conceptual guess that the combo box at the top is to select the user, and the stuff below applies to that user. There is two tasks on that form, and the relations between the two tasks is not clear.

Breaking out of tasks from a form does NOT always increase the number of steps to complete a given task. If there are 4 things to do for the task, then breaking those 4 things out of a messy form with 20 tasks on it does not make more work for the user. It does not make more steps. In fact, it means that the user is not presented with 80 options (say, 20 tasks of 4 steps each).

While writing this application I had hung a picture of mount Everest on the wall (a real great picture taken from base camp by a good friend of mine)

I also hung that often quoted saying on the wall also:

<quote>
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away"

Antoine de Saint-Exupery
Aviator and aircraft designer, and author of children's books
</quote>

In fact, the dedication of this product is to the above quote. This is my 3rd version of this product, and this time around one of my goals was to reduce maintenance costs! (I did reduce support costs by 10 hours per year! This was accomplished by change in my design. How I did this is again is a another long and interesting story).


By the way...you guys do hang different things on the wall for different projects...right?

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Wednesday, June 18, 2003

"I don't believe in save, or update buttons"

Good lord - and your users haven't said anything? I'd say one of my top feedback requests early on was "give me visible feedback so I know the record was saved" (I've now learned to do this automatically)

I can't say for sure, but I suspect you're in violation of Windows GUI guidelines, as well (which guidelines have been reinforced by the proliferation of web applications, where "close window" == "abort edit")

Finally, regarding "I don't believe" - I'm not sure I could ever put my faith in a developer that had this attitude. What you believe or don't believe in is very nice, but #1 on the list had better be "I believe in giving the user what enables them to do their work". Maybe you don't LIKE commit or edit buttons, but if the users want them, you'd best be putting them on the forms.

I don't like applications where it's obvious that the developer had a "vision" about "how things should work" - that email client, Bloomba, obviously suffered from this, and it didn't last four days.

Philo

Philo
Thursday, June 19, 2003

Dear Philo,
                  If your users are aksing for save and commit buttons because they want feedback, then it's because they have been exposed to some truly cruddy software. It's easy to know when something in a database is saved; if you put it in it's saved. Just like when you write something with a pen you don't get a message coming from the inkpot saying, "if you want the ink to stay on the page tap left, if you want it to flow back into the inkpot tap right."

                  Now possibly your user is asking to be able to view a draft version of something and do, or not do a batch save. That is not the normal thing for a data entry app so you give him a special form for this with the "standard sci-fi you are in a dream" color scheme, and when he presses the save button then you change the form back to standard. But it is equally possible that what the guy is asking for is a roll-back system, or simply something not so goddam confusing as the junk he is working with.

                You listen to your users but remember that your users are giving you information about how they want to do ther job. This will often be disguised as a request for a particular feature or a "helpful2 explanation of how to do something, but it is your job to design the app, not theirs. To simply take their suggestion at face value is to abidicate  responsibility.

                  Your comment on going against the Windows GUI guidelines is insulting and unhelpful. Insulting because you are accusing somebody who has obviously though long and hard about usability and the GUI, and unhelpful because you can't even be bothered to look them up to say how, or even try and explain in your own words.

                      As far as I can tell Albert is following both the spirit and the letter of the guidelines. The guidelines for confirmation boxes is that it should take two clicks/decisions to do something that may have minor repercussions, and three for something that may have major repercussions.

                      Take the delete confirmation box. You have that coming up, not because, as some think, the computer wants you to take time to reconsider your decision, but because it is quite likely that you clicked on delete by accident (I've lost count of the number of times I've clicked delete instead of rename on the context menu) or hit the wrong key by accident (or your cat landed on the keyboard). Now, as deleting is really serious you have a third option which is the recycle bin. With email you've got the deleted items folder, (though with Outlook at least the defaults cause problems in an Exchange server setup because users don't realize their mailbox is still full - web based emails that do regular cleanouts are much better thought out) .

                    The confirmation box comes up as part of the three stage process. Now take changing the user name. This should be a two stage process because all the info from the old user name is transferred to the new and not lost, and the two stages are choosing the form in the first place, and then entering the info. A confirmation box would be a needless third step, but wihen you delete a user you are doing something serious so you have the confirmation box pop up because you need the third stage. Now if you didn't have to actively choose a form to change the user name you might then need a confirmation box or at least an enter "old user name" stage to maintain the two click rule.

                There is also a real danger with too many confirmation boxes; you get used to clicking OK blindly and when one comes up saying "do you want to delete all your system files?" you find yourself in for a long reinstall (particularly if you have the upgrade version of Windows 95 on floppies)

Stephen Jones
Thursday, June 19, 2003

I am very open to the debate on the issue of a save, but I don’t believe in them right now.

I not sure who, but one of the original folks who designed the ideas for VB has a whole chapter in a book on how save is really dumb.

On the palm pilot, save is implied.

While in excel, you do have to save the whole document, but moving around in the sheet does NOT prompt the user to save (why then not prompt the user to save a cell then?, or if we really are fair...we would prompt for each new ROW in excel, since each row is a reocrd in a database?).

In fact, just open any windows folder and move things around...when you close that window, should the user be prompted to save? Heck, what about moving a folder on your desktop, the computer is saving the x and y location of the folder some where! This is the programmer model getting mixed up with the user model.

In ms-word, you can edit a document, and then close word. It then asks if you want to save/yes no? Talk about annoying your users. I mean if I edit the same doc 10 times today, it will ask me if I want to save 10 times? That is like putting a key in your car and turning it. The car will then ask do you want to start the engine?  I am really glad that cars came out before computers were invented!

How about when you open a real file cabinet and put in a document. The file cabinet will then ask you do you want to file your document? Again, I am glad file cabinets were invented before computers. Save prompts all over the place are just a huge source of annoyance IMHO. To be fair, you could however, you could replace 90% of my Exit buttons with a “save and close” button. In effect the exit button could be considered a save button. (however, I don't call it a save buttion, and that is a very important thing here).

In fact, if you alt f4 the whole appcltion while looking at a booking,it will exit WITH NO prompts. (of couse, so does ms-access, and a lot of other appctions also). And, a save will occur when you do this!

However, we as developers are fixated on save buttons due to how computers work, but that is not how users work. Just like how I delete the old security user and create a new one behind the scenes, the save also is abstracted out of the software here.

However, my shooting of the save button is simply a view of mine. I am just giving my 2 cents here, and for sure there is lots of room for this save button debate.

Further, I would be silly to ignore users mental models.

The follwing is some STRONG points in FAVOR of a save buttion. They are:

Office documents ask for a save (they should not, but hey..I can’t change the world!). Thus, there is a part of me that says I should go with the flow. However, you can open word, or excel and work for a considerable amount of time. Each new worksheet, or row added does NOT require a update prompt. Each new picture, or paragraph in word does not requite the users to “save” the paragraph. So, I can argue that I actually don’t break the users mental model that much. Further, that process only occurs when you as the user FOR A DOCUMENT name.  Futher, each new row in Excel is the same concept of a record in ms-access. And, lots of the time, I do present some data in a grid format, and again to move about and prompt the user to save is not going to fly when navagating a grid.

Ms-access is now 10 years old and got this right from day. It  NEVER DID ASK users to save records (amazing, 10 years old, and now the industry is just starting to adopt this idea). I just don’t see the need for save dialogs. Now today, products like Outlook, palm etc are moving in this direction. You are seeing more and more impled save applictions.

I mean, when you write a email, should you be prompted to save the email in the out box so it can be sent? OE does not prompt you to do this, but it is implied.

Why bug users all day?

The palm pilot came along and revolutionized the pda market with the same concept. (you can flip right into another application while in the middle of one, and the save is implied). I should mention that my users DO NOT know, and are not told this is a ms-access product anyway. All of the access interface is hidden, and I can distribute this via the runtime deployment package anyway. My package is not sold as ms-access application, and I don’t rely on any part of a possible user mental model in regards to ms-access.

For sure a save button gives the user a sense of closure. This concept I am real big on. Users are like little happy mice, and when they accomplish a certain task, or go a certain distance they like feed back. A little bit of cheese here and there is a good thing. In fact, breaking things into several forms often servers this purpose. One big huge complex form does not often give the user a sense that they are progressing. Ok, I just selected what bus to put the tour group on, now lets do the next step (or in my case..next screen!)

And, when things like a corporate group is actually booked, the software actually plays a round of “applause” wave file! True, this is a bit corny......but when you are in a sales office, users will crank up the volume a bit just before they hit the “book” button!. Yup, no doubt someone in the office just did a corporate sale!

For walk ins, and individual bookings, I don’t play that round of applause, and that would become annoying!

So often, sound is used as  negative feedback. I always use sound as a positive thing in my applications.

Since people are exposed to the web. I actually had to remove a few “clear search” buttons. Web stuff is now starting to make users want, or look for a “submit” buttons. Again, the sense of closure these submit buttons is nice. Also, we can not ignore that a lot of users experience is from the web. Thus, their mental model of how software works is being influenced by the powerful force we know as the world wide web. So, once again, there are some forces at work that do make a case for a save button.

However, products like the palm, even ms-access from day one implied a save. In my application, closing a the form is a save. If you need to undo changes, then you go edit->undo.

I just don’t know why word bugs me all day long to save a document when I close word...what else would I want?

I find users begin to navigate in a fashion much like using a palm pilot. They really boogie, and start to move REAL fast in a short time. There is absolute NOTHING that gets in the way of moving around (remember, I did do a dialog witch hunt here!). It also gives users a sense of real speed of movement. There are no squeaky wheels that don’t turn when the users turns their direction in the application.

When you move through the application you can push as hard as you want. Most operations can be done via the key board also. Thus, often, then next 2 forms are a quick Enter key followed by another Enter key as the user blazes through those prompts.

I am right now considering taking some actual videos of users working the software and posting them on the web. This UI process is rather interesting to me. Remember, this software works with the person while on the phone with the customer most of the time.

I do believe that the trend in our industry is to get rid of save prompts, and the only real big thing holding this back this is the web came along and again started using things like submit buttons.


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Thursday, June 19, 2003

Yet again I find myself asking "Is Albert incapable of making a short post?" ;-)

So Much To Read
Thursday, June 19, 2003

You're wrong about save prompts in Word, Albert.

What the save prompt in Word is asking is "Do you want to overwrite your old copy?" Normally the answer will be yes, but a lot of times it could be no. For example you open document and start playing around with it. You are half way through and get called away. The last thing you want to do is to overwrite the old finished document with this half written mess.

With Access however data entry is atomized. You don't use databases to play around with ideas.

With Excel you wil have to save the first time because you have created a new file (in Access you have to create the new file before you start writing anything). The reason Excel doesn't behave like Access is that plenty of people use Excel as a super-calculator. You're not going to create an Access or an Oracle database just to do a bit of quick Math.

Save on a database app is asking for data corruption. If people didn't want the database to have the data they wouldn't have put it in in the first place.

Stephen Jones
Thursday, June 19, 2003

Dear so much to read,
                                  How many more tomes do you need to wade through before you can see the obvious?

Stephen Jones
Thursday, June 19, 2003

You can also look at the "save" question as:
Was this a straight edit or should I branch?
Is this a good time to GC the undo list?

Just me (Sir to you)
Thursday, June 19, 2003

*  Recent Topics

*  Fog Creek Home