How do you USE this darn thing????

Dana Coffey Blogs on User Interaction

May 2003 - Posts

Eli and Opt -In

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

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?

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?

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?

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!

 

More Posts