How do you USE this darn thing????

The Things Users Do

DanaCoffey — Mon, 21 Jul 2003 21:26:00 GMT

In testing and putting the finishing touches on a current application, I've been dismayed to discover that my users do not necessarily use my interfaces as I would have believed they do. I'll share these few tidbits that I've learned with the class:

Do not set a default selection (or at least filter it out in form processing) in a multiselect dropdown list. Users automatically press the control key before clicking selections. They will unknowingly select the default in that group over 60% of the time.
Some users are unable to watch animations and read text at the same time. - When using animated gif's for whatever reason, do not position text directly above, below or next to that gif if you intend for your users to read that text - especially directions. They may end up emailing you for explanations that are right beside the images. ;-)
Inline datagrid editing may confuse your users - One of the things I like about the ASP.NET data controls are the ability to edit the contents of a row from right within the row. This seems to have dismayed some of my users as they've asked me where the "edit page" is. I could address this issue with instructional text, but as discussed before in a previous blog, it is unlikely to be read.
Text at the bottom of the page is never read - this may be an exaggeration but I've noticed any additional instructions or information at the bottom of a page goes completely unnoticed, causing the user to phone me and ask. I think this spot is really only good for a copyright notice and a date.

Eli and Opt -In

DanaCoffey — Thu, 08 May 2003 10:16:00 GMT

Eli Robillard wrote a bit about "Common Sense and Opt-In" in his blog for May 8.

Everyone is familiar with the little checkboxes on websites with an option to "remember me". These also exist to "remember my settings", etc. This reminds me of what Cooper referred to as both protecting the user from himself, and also adding an extra unnecessary step for the user.

Eli maintains that we should make this seamless via the use of cookies, and instead of having users opt in that your code should seamlessly handle cookies instead. He goes a step further and says that sites should educate the users about cookies as well. Here is where I disagree. Users are not going to be bothered to take the time to read that sort of thing. I think that yes, we should get rid of the opt-in checkbox, but do allow an opt-out one. Since experienced users already know about cookies, and might already have privacy concerns, they will understand the concept and appreciate the option.

I guess it all depends on who your intended audience is. If you are designing for developers or techno-savvy people, they will fully understand when they return, that their information was saved in a cookie. Average and novice users on the other hand, don’t need to know this. All they know is "hey lookie I was here yesterday and the site remembered me! How cool!"

Web GUI Bloopers

DanaCoffey — Tue, 06 May 2003 22:08:00 GMT

Jeff Johnson wrote an excellent book called GUI Bloopers that has been very enlightening. In Chapter 6, he addresses a few particular bloopers:

Website Structure Reflects Organizational Structure or History
Back Doesn’t Go Where Users Expect
Complicating Searching

In this world of partnerships and acquisitions, many companies seem to find it necessary to reflect their internal structure in their websites, which leaves sites often structured around several brands at once. The main blooper happens when they present the site to reflect their internal business structure, which is of little concern to the user. The user may not be familiar with the internal departments or hierarchy of the company as its employees might be. Corporate marketing sites should assume the user has never heard of the business or the company.

In addition to careful architecture of corporate sites, designers also need to be aware of particular issues with the case of acquisitions and mergers. Merging of brands should be seamless. I’ve seen many sites with patchwork branding and have stopped to make sure I did not leave the original site. This not only causes confusion, but often the two organizations will have conflicting information.

How does a designer address this? Every one of us has experienced the situation where a client does not want to spend money on requirements gathering, interviewing potential users, prototyping and usability tests, and instead asks us to just code a prototype for them to review (which they review and decide it’s not at all what they wanted and that you are the most evil programmer since Satan himself). With web applications in particular, every single step in the design process for stand alone applications should also be followed here.

Other factors to consider are whether user can tell the difference between which pages were developed internally and which were outsourced, whether all internal pages follow the same design conventions and style; if pages or components inherited from a legacy site have been revamped to match overall design look and feel, and making sure that when links leave a site, it’s obvious and the user can get back easily (I put all external links into smaller, strategically positioned new browser windows for this purpose).

One blooper is inconsistent traveling backwards. Designers’ use of frames, templates and complex navigation can serve to confuse a user when she clicks the “BACK” button on her browser. One of the larger offenders is a long FAQ type page with lots of anchors in the document. If the user tries to click the back button, she will find herself on the same page, and often become confused and assume the button did not work. Putting “back to top” links are helpful in this case, but a better approach is to split content up into smaller sections on different pages. There are other ways to help make use of the back button consistent for the user. The basic rule is developers should determine where their users will expect the back button to take them, and design accordingly. Provide plenty of descriptive links instructing the user to go “back to xxx page” and ensure your page navigation is consistent and usable across each page of the site.

The final blooper for today’s blog is “Complicating Searching”. There are two main offenders in this category: not including search criteria in search results and forcing users to distinguish “keywords” from “search terms”. Displaying the search terms on the results page is helpful as a visual reminder for the user to compare results against his search, and also to help him evaluate and refine the search. Many search engines do not do this. The other problem occurs when search boxes give the user options for “keywords”, “search terms”, “boolean search”. Most users have no idea what the differences are between these and will most of the time select whatever is the default. Many search sites do not offer any assistance in explaining this. Do YOU know the difference between keywords and search terms? I myself didn’t! J

Jeff Johnson’s book covers tons of GUI bloopers. Chapter 6 alone has many more than those I discussed today. For more information about Jeff and his ilk, go to www.uiwizards.com.

Do Users Pay More Attention to Banners or Text Advertisements?

DanaCoffey — Mon, 05 May 2003 13:53:00 GMT

In Jacob Nielsen's Alertbox for April 21, 2003, he claims that advertising does not work on the web because it interferes with the user's goal - which is to find what she needs and then leave as quickly as possible. The two exceptions to this rule are classified ads (because they have content), and ads for search engines (because people always end up using search engines at some point.

Text-only ads on search sites however, have become more and more successful, and many non-search sites are attempting this approach as well. If this indeed proves to be a successful advertising tactic, it shall only be due to the novelty effect according to Nielsen. Web users have long ago become "browser blind" which means we naturally ignore the banner ads we see on websites. I personally could not tell you about any I've seen recently that are not ASP.NET related :-) . Text only ads are not necessarily guaranteed a bright future, because their novelty is likely to wear off, rendering them to be eventually be ignored by users. They do however have some advantages over traditional web marketing.

Because text ads are a low-level media format, users may take them more seriously. When advertisers are limited to a more simplistic and focused method of communication, it forces them to work harder at succinctly relaying the message to users. These ads are likely to better describe what the user will find when clicking on the link because of the lack of visual references.

Many companies use graphically rich ads with the notion that they are "promoting the brand", but in reality they are ignoring the user's needs and wants. We all hate banner ads and other graphical web advertisements (my pet peeve are those flash pop-up-and-takeover-my-browser ads - I would never buy ANYTHING from someone who uses those).

The future of the text only advertisement movement may be yet to be determined, but one thing remains clear. Successful advertising on the web depends on ONE sole item - giving the user what she wants today, and adjusting for what she wants tomorrow. According to Nielsen, web users are "are utterly selfish and live in the moment. Giving users exactly what they want, right now, is the road to Web success, and having to write small boxes of text encourages advertisers to travel it. "

Enjoy more from Nielsen at www.useit.com

Hyperlinks - Friend of Foe?

DanaCoffey — Fri, 02 May 2003 13:53:00 GMT

The success of users navigating with links depends on two things:

How well the user can predict where the link will lead
How well the user can differentiate one link from the other, nearby links.

-Jared Spool in Website Usability: A Designer's Guide

One of the prime goals of user interaction design on the web is to eliminate questions the user may have when arriving at a site. Vague, one word links causes a pause to think in the user's flow when reading the site. Steve Krug says one should not have to "think" when viewing a site. Navigation should be intuitive enough to eliminate questions. One way we can do this is to design our hyperlinks to aid a user's prediction of what comes next.

Let's suppose we had a site that sold cars. The user's main goal on the site will be finding and getting good information about cars in which she may be interested. Let's say the main navigation links were: "Shop", "New Releases", "Clearance", and "Finance". Upon arriving at any of these, the user will have questions about whether or not they will help her meet the goal at hand: "Shop" might make her stop to wonder if she couldn't just browse around to get information without buying. "Financing" would cause the user to wonder if pricing information was there also.

By designing these links to be more descriptive, the user will not have to guess: "Browse Used Cars", "Browse Used Trucks and SUV's", "Browse New Cars", "Browse New Trucks and SUV's", "Find a lender", "Find automobiles in your price range", "View price list of all models". These tell the user exactly what she can expect to find in the next page.

Link layout is another thing to which users respond. Putting text around links does not seem to work well. Users are often confused as to which portion of the text is a link for instance. In addition, users skim web pages - they do not read in depth. Many links embedded in text will be glossed over in the user's reading. Wrapping links that go onto another line are also distasteful. Also links that are side by side in a vertical list of links are ambiguous and confusing (attention Scott W - see how the links for Admin and Logout are beside each other in the admin section of the blogs. I thought for the longest time that it meant "admin logout" meaning I could log out from being in administrative mode).

Destination of links has been another thing that often confuses users. Links to other sites should open in a new, smaller window. Otherwise a user may become confused and his navigation will become muddled with his perceived inability to get back to where he started. Links to content within the same page should also come with a "back to top" link and a header to the content to which the link refers. The user needs to clearly be able to understand she is on the same page.

Most developers do not put much thought into hyperlinks. Most of what I've covered today is common sense, but it does pay to look back at your sites and see how you've structured your links. I've done this and been confused myself at times. Here is my best tactic: Although I design from a persona and goal oriented perspective, with hyperlinks I generally try to create links that my mother would understand. This keeps me safe 90% of the time :-)

What is "Excise" and Why is it Important for .NET Developers to be Aware of it?

DanaCoffey — Thu, 01 May 2003 14:02:00 GMT

I'm reading a GREAT book! It's called About Face 2.0 by usability Guru and Father of Visual Basic Alan Cooper and his co-author Robert Reimann. In Chapter 10, Cooper discusses the concept of excise:

Cooper defines excise as "the extra work that satisfies either the needs of our tools or those of outside agents as we try to achieve our objectives". To explain, he relates software to a car. With a car, our objective is driving to our destination. Inserting the key, opening the garage door, buckling the seatbelt, adjusting the temperature and putting the car into gear are not actions that help us reach our goal; they are actions that our tool (the car) requires to function to our needs.

When excise tasks are eliminated, the user becomes more productive and efficient, and our software becomes easier to use. Chapter 10 discusses some of the types of excise such as:

"Welding on Training Wheels" - This refers to all the things we try to do for novice users to make things easier for them. These same things become excise for experienced users. My best analogy to this concept is the Microsoft Office Assistant (or ms agent). To a novice user, this little guy is a friendly helpful addition to the user experience. However after one becomes proficient in Microsoft Office, he has no need to interact with that doggone paperclip anymore and he may indeed wish it dead - had not Microsoft Office designers been kind enough to provide the user with a method of turning him off and shutting him up for good. "No I do NOT need your help with this letter thank you!"....
"Stopping the Proceedings With Idiocy" - Known as one of the most disruptive forms of excise, this can be easily avoided with some foresight. Error messages and confirmation dialogues are the greatest offenders. The average user is not interested with information portrayed in an error message. This is usually information the user does not understand or care about or it requires more action to fix a problem that should have been handled in the software. Using good error logging and smooth exception handling to eliminate the need for error dialogue is an essential way .NET developers can address this. Kirk Allen Evans gave a great talk about the wonderful ways you can handle exceptions in .NET at the last Atlanta .NET User group Meeting. Write him and ask any questions you might have.
"Protecting us From Ourselves" - Developers need to remember that password protection is not necessary in all contexts. While appropriate for a professional setting, the novice user at home may not need them. There should always be a way to turn that option off, just as in the case of the MS Office Assistant.

Cooper sums up this chapter with a bulleted list of common excise traps. I'll quote them for you:

Don't force the user to go to another window to perform a function that affects this window.
Don't force the user to remember where he put things in the hierarchical file system.
Don't force the user to resize windows unnecessarily. When a child window pops up on the screen, the program should size it appropriately for its contents. Don't make it big and empty or so small that it requires constant scaling.
Don't force the user to move windows. If there is open space on the desktop, put the program there instead of directly over some other already-open program.
Don't force the user to re-enter her personal settings. If she has ever set a font, a color, an indentation, or a sound, make sure that she doesn't have to do it again unless she wants a change.
Don't force the user to fill fields to satisfy some arbitrary measure of completeness. If the user wants to omit some details from the transaction entry screen, don't force him to enter them. Assume that he has a good reason for not entering them. The completeness of the database (in most cases) isn't worth badgering the user over.
Don't force the user to ask permission. This is frequently a symptom of not allowing input in the same place as output.
Don't ask the user to confirm his actions (this implies a robust undo facility).
Don't let the user's actions result in an error.

Now that you have this great information, run along all of you and EXCISE that stuff from your products!

Usability Tip of the Day - Get rid of half the text on a page, and then half of what is left!

DanaCoffey — Wed, 30 Apr 2003 14:03:00 GMT

Steve Krug suggested in his book, Don't Make Me Think, that one of the most distracting hindrances to users is too much content. His suggestion mentioned in the title of today's blog is intended to make a point to "BE RUTHLESS ABOUT THIS".

In many web applications, I see many chunks of text that I most likely will never read. In addition, the mere existence of many chunks of content implies that it might be important to me, and over complicates my user experience. Good candidates for removal are the following:

Happy Talk - These are the chunks that usually say "hello and welcome to the blah site..." In fact, a good indicator to determine if text is happy talk is to see if you hear a "blah blah blah" in your head when you read it. Text that tells you what you will find at the site is also considered happy talk. You should convey this with intuitive navigation instead. Imagine if each television show had a 10-minute introduction telling you what you were about to see. You'd be saying, "Just show me the program please!"
Instructions - One thing developers do not understand is that users do not read instructions; at least they do not read them until they have "muddled through" the site with no luck using it. You should eliminate the need for instructions by making everything self-explanatory. When instructions are absolutely necessary, they should consist of as few words as possible. Remember that users are accustomed to the instant gratification the World Wide Web provieds, and will not linger long to read the instructions before clicking on things again.

Remember, according to Krug, removing all the needless words from your site enables you to:

Reduce the level of noise in a page
Make useful content more prominent
Make pages shorter, allowing users to see more of each page at a glance

Krug does not of course, recommend removing article content and such, just the "noise" so many of us overlook when trying to make user friendly sites. We assume the user's experience is improved with things they actually never bother to view.

That's the tip for today! Those of you in the Atlanta Area, come hear me speak more on usability at the June meeting of the Atlanta .NET User group (http://www.atlantadotnet.org/) .

Jack of All Trades?

DanaCoffey — Fri, 04 Apr 2003 14:21:00 GMT

Having to recently do a complete set of technical specifications for a client in addition to coding, I was wondering just how many developers are being called upon to also handle information architect tasks, dba tasks, project management tasks and support and training. Working as a private contractor/consultant, I probably run into this more than in the corporate sector. My last job in the corporate world was a bit different.... there was no documentation (I'm sure you guys are familar with this) - they just had us code prototypes which they ripped to hell and then informed us we had 15 hours of budget to do what had now grown to 80 hours of work. Well needless to say, they could not support an entire IT staff when all their projects go down like that. I have, however had jobs where the division of tasks was very clear. In one job the ONLY thing I messed with was ASP. We had html guys, IA guys, dba guys, and the com guys. The wanted me ONLY to tie it all together, and that was kind of cool.

I'm really curious to know how many different hats some of us wear on our jobs and how people feel about that. I kind of like the variety myself, as I have a bit of ADD .......now what were we talking about?

TGIF!!!!!

Very Cool Color Pallette Tool

DanaCoffey — Thu, 03 Apr 2003 18:05:00 GMT

Everyone seems to need to match up colors sometimes and often it's a real pain trying to get exact #000000-esque values by eye. I posted a sweet little tidbit on the aspFriends lists when they were active and again recently on the aspAdivce list. People really like it and keep telling folks, "ask Dana - she knows of a good one". Since folks keep asking me (Bryan Andrews *wink*) I figured it was too good not to share with the rest of the community. ANYHOW, it's called "Color Cop" and can be found at download.com or tucows.com. It's this neat little "always on top" program that has an eye dropper tool that you can drag over anything in your screen's display. As you drag it, watch how it tells you the values of each and every color. It also has some other neat color pallette features. It's very cool and I would DIE without it. Ok, that's a bit dramatic, but I sure do love it :)

"Color" me Perky :D