Tuesday, March 25, 2008
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.
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.
Sunday, March 23, 2008
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.
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.
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.
Wednesday, March 19, 2008
Klok version 2 - Mac testers wanted
In the next major version of Klok, I intend on adding many new features. One of those features is the ability to minimize to the system tray. You would then be able to "pause" and "restart" your current task if you get pulled away from your desk for example.
It has been a long time since I worked on a Mac, so I can't even remember if they have any equivalent feature. If so, I would like to add it and would need some help testing it. If not, I would appreciate somone with a Mac testing it out to make sure I don't inadvertantly cause a bug that isn't apparent on Windows.
If you are interested, email me at rob (at) mcgraphix (dot) com
It has been a long time since I worked on a Mac, so I can't even remember if they have any equivalent feature. If so, I would like to add it and would need some help testing it. If not, I would appreciate somone with a Mac testing it out to make sure I don't inadvertantly cause a bug that isn't apparent on Windows.
If you are interested, email me at rob (at) mcgraphix (dot) com
Monday, March 10, 2008
Klok makes Mashable.com "10 Adobe Air Apps Worth a Look" list
I was wondering why around March 5 and 6 the Klok site got 50 times more hits than usual. Not all is attributed to the mashable.com post on March 5, but a good chunk was. Thanks to whomever put that up.
Thursday, March 6, 2008
Flash...iPhone...What the hell?
In my opinion not having Flash on the iPhone is not good for anyone... it isn't good for Apple or Adobe, yet somehow neither one seems to be ready to give in. If it is really just an issue over PDF rendering, it is even worse. If you were putting out a hand-held computer (which is what the iPhone really is) with all the power of the iPhone, wouldn't want to give the consumer the best possible experience? Wouldn't you want developers all over the world to create apps that run on it?
Apparently Steve Job's is either a complete nut-job or a genius beyond all of our understanding. Ordinarily I would say that he is making a huge mistake, but for some reason he seems to pull off some long shots.
Apparently Steve Job's is either a complete nut-job or a genius beyond all of our understanding. Ordinarily I would say that he is making a huge mistake, but for some reason he seems to pull off some long shots.
Subscribe to:
Posts (Atom)