To save or not to save

Every time I write something on this blog I am reminded that some software is so transparent that I don't even need to think about it. Take Blogger for example. As I type this text, I often stop typing for a few seconds at a time to think... like just then...When I become idle for a bit Blogger notices and takes that time to automatically save my work.

It tells me when it last did it so I can be sure that if something went wrong and I lost my internet connection or my machine crashed, all but the last few words would be safe. If I click SAVE NOW, I get this so I can differentiate when I saved vs. an auto-save.


Notice that the text saying when it was saved is not modal, so I can happily ignore it if I want. This is much better than an Alert saying the same thing since you can't ignore an Alert.

Usually the argument against this goes like this "We can't decide when the user should save" or "What if the user doesn't want to save?" In actuality, it is safe to assume that the user always wants to save. After all, how often do you spend a bunch of time writing something and then not want to save it? You may infrequently, discard changes but that certainly happens much less often. Since it happens so infrequently, Blogger has no way to not save. This was no doubt a concious decision based on knowledge of real users' goals.

Now, some applications may need the ability to not save. But, that doesn't mean that you can't have auto-save. One solution would be to store the last manually saved data in a secondary location until the next manual save. Then if you wanted to revert to your last save after auto-saves have occured, you could simply retrieve it from that secondary location. If revert is never needed, then you could just throw that data away when the session ends.

I can already hear the arguments now. "That would be very difficult to implement", "We should spend our time on REAL features", "How would referential integrity be maintained?", etc.

In some applications this not trivial. But, as usual, the arguments against rarely mention Jane Smith, the professional writer. Remember, software is meant for humans to use to solve their problems. We can't leave them out of the equation.

Worst UI Ever: Error Messages Part 3

As a user, I always find these terribly frustrating. As a Interaction Designer, I find these somewhat funny. Here is a tandem set of error messages from Microsoft Excel that were really frustrating at the time.

First off, my Excel document had a Word document embedded in it. I had double clicked the icon to launch Word. When I tried to close Excel with Word still open I received this error message.

Now, assuming that the error had something to do with the open Word document, you have to wonder why the error message didn't say something like "You cannot close this spreadsheet while the embedded document is open". Obviously at some point in the development, someone decided that "Reference is not valid" was going to be an appropriate message to show Bob Smith the accountant tracking inventory. Even as a developer, I have no idea what that could mean. But, since the only choice is "OK", I guessed that I should click it. After that, nothing seemed to happen, so I decided to try quiting Excel entirely. And then...

Ummm..... huh? What do you mean you can't quit Excel? Am I not in control of my own computer. I said quit and and you should quit. Again, somewhere in the development process someone decided that it would be ok to be in a state in which the application cannot stop. Like a bus with no brakes, all we can do is honk the horn and tell people we can't stop.

I assumed that the problem has to do with this Word document. So I just hit "OK" (By the way... things DO NOT feel ok at this point). I close Word and then try to quit word again and get...

... hmmm... So now things are not looking good. So I do what everyone would do and open up Task Manager, click on the Process tab, find excel and click End Process. So, if I could "quit" Excel, why did Excel say it couldn't?

This is a case where these messages were probably not expected to occur, but even if there is an unlikely chance of it, a small amount of time could have been spent to at least give some idea of why the program was in this state. A few minutes more, and the message could have explained how to recover, albeit a round about way. Almost anything would have been better than these messages.

Before all the Mac followers start proclaiming that this is why Microsoft is evil, let me just remind you of this:

Watch out... its gonna blow!

In Apple's defense though, most of the time they at least did a better job of telling you how to get past your problem.

However, the bomb icon is a bit disturbing and there is really no point in saying "unimplemented trap".

The bottom line is that if you are going to say something to the user about an error condition, make sure it is in a language they can understand. "Referenence Error" and "Unimplemented Trap" might as well be in Greek to most people.

RIAs give new life to browsers

I was poking around the IE 8 beta site and had a thought. Given that the developer community seems to be looking outside the typical browser standards (HTML, CSS, Javascript) for ways to build richer applications, it might be easy to jump to the conclusion that the browser will be reduced to a simple delivery mechanism for Flash/Flex, Silverlight and JavaFX applications.

However, I think this trend is likely to release the browser of its responsibility of an application platform. Since it was never intended to be that platform, all the complexity that went along with it just detracts from its value as a platform for retrieving and displaying information. In the role of information delivery I think the browser is a wonderful thing. Features like the new WebSlices and Activities features of IE8 are information-centric features.

Just like any employee, if we let the browser do the job it was hired to do, it can really excel at it.

User Experience - Homer Simpson Style - take 2

Doh!....Sorry for the re-post, but it seems that something went wrong with my first post on the subject which I think I have now fixed.

Does Forrester think AJAX is over?

There is an interesting synopsis of a Forrester paper over at Computerworld which seems to indicate that the sky is falling if you are building AJAX apps. While I agree that performance problems and lack of rich interactivity still put AJAX behind Flex or Flash for applications, I think the authors took it a little too far. I don't intend to go pay for the actual paper from Forrester, but I have to imagine that their conclusion is a little less alarmist.

Having built many AJAX and Flex applications I personally feel that it is harder to deliver as rich a user experience using AJAX as with Flex. My gripe with the article however, is that the synopsis specifically talks about power users as being disappointed. The reality is that only a small percentage of users of most applications are ever power users. Similarly, only a small percentage are novice users for very long. The majority of users are intermediate users. So be careful about choosing a technology based on the wrong population.

User Experience Problems - Not just for software anymore

Recently, I found myself the unfortunate victim of a poorly redesigned User Experience. No... this wasn't a new version of some software program. This was a change in the cafeteria at my office. Bear with me...this isn't just me ranting.

I don't eat in the cafeteria much. In fact I almost never eat in the cafeteria. I do, however, get a drink at the cafeteria daily. Up until last week, the process was very simple. I could go to the soda machine which had the cups, lids and straws kept in a plastic dispenser directly to the right of the soda machine. So the process of getting a drink was simple. Pick up the cup, fill with ice and soda, retrieve a cover from the dispenser, get a straw and off I go.

One day I noticed there were no straws next to the machine. I assumed the dispenser needed to be refilled. I asked someone for more straws and he quickly walked out into the the area where all the tables are (the soda machine is in the area with the kitchen and salad bar) and opened the cabinet below the counter where the utensils and napkins were stored and pulled out a box of straws. I took one and off I went.

Ever since that day, there have been no straws near the soda machine. They are now stored along side the napkins and utensils.

So here is the problem. The straws appear to now be kept in the current location for the sake of keeping them near the place where the extra stock is stored, instead of where they are actually needed. This is often a problem in software development as well. How many times have you heard a developer say "it is easier to put the button here" or "we have to do it this way for techincal reasons." There may be times when it is techincally challenging to make software do what is best for its users. However, the problem could have easily been solved before it was a problem, by thinking about how it might be used.

One could argue that many people who come to the cafeteria are there to eat so they will likely need napkins and utensils as well. However, the is a whole other type of visitor, that frequent the cafeteria. This is also a common problem in software. As developers, it can be very difficult to think about anything other than "The User". The problem is "The User" is a combination of every possible type of user which leads to an interface created for a person that doesn't really exist. If the cafeteria manager thought about "customers here to eat", "customers here for a snack" and "customers here for a beverage" then it would be obvious that things should be set up to accomodate each of them. For example, customers planning to eat would likely need utensils, napkins and straws. The current set up would work well for them. Customers who came in just for coffee or a soda would probably never need to visit the seating area at all. Placing sugar, creamer, straws and napkins right by the checkout would make a lot of sense.

We can do this in software design as well by thinking about the types of users the system might have. The point is to make sure you are supporting the real users of your software so that you don't make the system difficult or ineffecient for a significant amount of them.

User Experience - Homer Simpson Style

I happened upon a Simpson's episode the other day that, despite having nothing to do with User Experience, made me think of a common experience in web applications. The episode in question is called The Wizard of Evergreen Terrace. The basic plot of the episode is that Homer realizes that he hasn't done much in his life and decides to be an inventor. Obviously, many funny gags follow. The thing that prompted this blog entry was one of Homer's inventions. He called it the "Everything's ok alarm". Basically it beeps loudly every three seconds unless something isn't ok.

If you are wondering what that has to do with the User Experience of software, let me set the stage. How many times have you been prompted with an Alert box telling you that some was "ok". This might be something like "Your changes were saved successfully" or something to that effect. The reality is that, while it would be appropriate to Alert the user when changes failed to be saved, it isn't appropriate to say "everything's ok" with the software equivalent of an alarm going off.

Homer's invention illustrates the absurdity of using the wrong method of communication in the "real world", however, sometimes we forget that the same care must be taken when selecting a method to communicate in software.

A better way to alert the user that something was successful would be to display a message, perhaps next to the save button, saying "Changes were saved at 12:34 pm" This notifies the user that the changes were saved without forcing the user to acknowledge what a great job the software did doing its job. It also adds more value because it indicates the last time changes were saved which may be important in some applications.

So lets leave the "Everything's OK alarm" to the cartoons... and I don't want to see any software equivalents of the "makeup gun" either.