![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
recommends web application design handbook: best practices for web-based software for web app design
the most important rule for making a web site easy to use: "don't make me think"
the second most important rule: minimize # of words
user "should be able to "get it" -- what it is and how to use it -- without expending any effort thinking about it"
how self-evident? site should be sufficiently self-evident that someone "with no interest in the subject of your site and who barely knows how to use the back button" "could look at your site's Home page and say, 'Oh, it's a ____.""
this property is distributive. the user should be able to look at any part of any page and see what it is for without thinking.
examples of what the user should not have to think when looking at various parts of the page or the page as a whole:
more examples of things that make us think:
note that the thought required for the user to resolve these questions takes less than a second (e.g. if the user is not sure if something is clickable, they can point at it and see if the cursor changes). these things should still be avoided when possible.
p.s. don't make a design checklist with these things; instead, just understand the basic principal of "eliminating question marks" (over the heads of the user, if imagined as cartoon icons overlayed on the web page, looking at various parts of it). "... you'll begin to notice all the things that make __you__ think while you're using the web, and eventually you'll learn to recognize and avoid them in the pages you're building"
"Why are things always in the last place youlook for them? Because you stop looking when you find them" -- children's riddle
"when we're creating sites, we act as though people are going to pore over each page, reading ... figuring out how we've organized things, and weighing their options before deciding which link to click. What they actually do... is __glance__ at each new page, scan __some__ of the text, and click on the first link that catches their interest of vaguely resembles the thing they're looking for. we're thinking... "product brochure" ... while the user's reality is much closer to 'billboard going by at 60 miles an hour'". there are exceptions, but in general it's closer to this than most of us imagine.
"what we see when we look at a Web page depends on what we have in mind, but it's usually just a fraction of what's on the page... we tend to focus on words and phrases that seem to match (a) the task at hand (b) our current or ongoing personal interests, ... (c) the trigger words that are hardwired into our nervous system, like 'Free', 'Sale', and 'Sex', and our own name."
"one of the things that becomes obvious as soon as you do any usability testing... is the extent to which people use things all the time without understanding how they work, or with completely wrong-headed ideas about how they work...very few people take the time to read instructions...muddling through is not limited to beginners. Even technically savvy users often have surprising gaps in their understanding of how things work"
Why? "It's not important to us" (lack of caring, not lack of intelligence) and "If we find something that works, we stick to it". "Web designers often have a particularly hard time understanding -- or even believing -- that people might ((not care to understand how things work)), since they themselves are usually keenly interested in how things work."
What to do? "If your audience is going to act like you're designing billboards, then design great billboards"
"
"the __appearance__ of the things on the page -- aoo of the visual cues -- clearly and accurately portray the __relationships__ between the things on the page"
e.g. in newspapers, the picture that goes with a certain story are spanned by the same headline; the most important stories have larger headlines, wider columns, and a more prominent position
we parse visual hierarchies quickly and preconsciously. "...when a page doesn't have a clear visual hierarchy -- if everything looks equally important, for instance -- we're reduced to the much slower process of scanning the page for revealing words and phrases, and then trying to form our own sense of what's important and how things are organized."
"parsing a page with a visual hierarchy that's even slightly flawed -- where a heading spans things that aren't part of it, for instance -- is like reading a carelessly constructed sentence ('Bill put the cat on the table for a minute because it was a little wobbly')"
"at some point in our youth, without ever being taught, we all learned to read a newspaper. Not the words, but the conventions."
e.g. headlines, photo cations, photo credits
"...all newspapers ((use)) the same conventions (with slight variations), so knowing the conventions made it easy to read __any__ newspaper"
"every publishing medium develops conventions and continues to refine them and develop new ones over time" (e.g. the "small semitransparent logos ... in the corner of ((tv screens)) to tell you which network you're watching" didn't appear until TV had been around for about 50 years
web conventions are "very useful" -- "as a rule, conventions only become conventions if they work" "well-applied conventions make it easier for users to go from site to site without expending a lot of effort figuring out how things work" "there's a reassuring sense of familiarity, for instance, in seeing a list of links to the sections of a site on a colored background down the left side of the page"
designers are often reluctant to take advantage of web conventions (because they want to do something new and different, because sometimes that's what they've been hired to do, and also because it helps them make their name)
"if you're not going to use an existing Web convention, you need to be sure that what you're replacing it with either (a) is so clear and self-explanatory that there's no learning curve -- so it's as good as a convention, or (b) adds so much value that it's worth a small learning curve. If you're going to innovate, you have to understand the value of what you're replacing, and many designers tend to understimate just how much value conventions provide.
my recommendation: innovate when you __know__ you have a better idea (and everyone you show it to says, 'Wow!'), but take advantage of conventions when you don't.
"ideally, users should be able to... ((glance around and point)) at the different areas of the page and say, "things i can do on this site!" "links to today's top stories!" "products this company sells!" "things they're eager to sell me!" "navigation to get to the rest of the site!"
"several ... eye-tracking studies of Web page scanning suggest that users decide very quickly which parts of the page are likely to have useful information and then almost never look at the other parts -- almost as though they weren't there"
e.g. on a web page in which the whole page is colorful, making some text colored isn't a good indicator of clickability.
(minor point: if you use a little triangle near the link like an arrow to mark the link as a link, make sure the arrow points towards the link)
busy noise (loud) : e.g. invitations, exclamation points, bright colors
background noise (quiet): black lines between menu items (they should be gray)
"some people have no problem with busy pages and background noise, but many do"
"it doesn't matter how many times i have to click, as long as each click is a mindless, unambiguous choice" -- krug's second law of usability
usability professions give recommendations about "how many times you can expect users to click to get what they want without getting too frustrated". some specify a maximum number of clicks to get anywhere in the site (usually 3-5). "but i've come to think that what really counts is ... the amount of thought required, and the amount of uncertainty about whether i'm making the right choice"
"the rule of thumb might be... three mindless, unambiguous clicks equal one click that requires thought" exception: "if i'm going to have to drill down the same parts of a site repeatedly, ... or if pages are going to take a long time to load"
e.g. "if i go to Symantec's Virus Updates page because i want to update my copy of Norton Antivirus, i'm faced with two choices i have to make before i can continue", language and product. the pulldown for product gives choices including "NAV for Windown 95/98". "Now, I'm sure that it's perfectly clear to everyone who works at Symantec that NAV and 'Norton AntiVirus?' are the same, but it requires at least a small leap of faith on my part.
and even though i know for certain that i'm using windows 98, there's a least the tiniest question in my mnd whether that's exactly the same as 'windows 95/98'. maybe there __is__ something called 'windows 95/98' that i just don't know about "
e.g. "when i'm trying to buy a product or service to use in my home office, i often encounter sites that ask me to make a choice like" Home or Office -- which one is me?
e.g. "standing in front of two mailboxes labeled Stamped Mail and Metered Mail with a business reply card in my hand." "what do __they__ think it is -- stamped or metered and what happens if i drop it in the wrong box?"
"get rid of half the words on each page, then get rid of half of what's left" -- krug's third law of usability
(actually if you just remove half, you're ok -- but the point is, be ruthless about it)
two kinds of things can usually be shortened:
e.g. "introductory text that's supposed to welcome us to the site and tell us how great it is, or to tell us what we're about to see in the section we've just entered. ". translates to "blah blah blah blah blah..."
"unlike good promotional copy, it conveys no useful information, and ... focuses on saying how great we are, as opposed to delineating what makes us great"
"is sometimes found on Home pages -- usually in paragraphs that start with the words 'Welcome to...' -- its favored habitat is the front pages of the sectons of a site ('section fronts'). Since these pages are often just a table of contents with no real content of their own, there's a temptation to fill them with happy talk.... the effect is as if a book publisher felt obligated to add a paragraph to the table of contents page saying,'This book contains many interesting chapters about ____, and ____, and ____. We hop you enjoy them."
"Happy talk is like small talk -- content free, basically just a way to be sociable. But most Web users... want to get right to the beef."
"the main thing you need to know about instructions is that no one is going to read them -- at least not until repeated attempts at 'muddling through' have failed. And even then, if the instructions are wordy, the odds of users finding the information they need is pretty low.
Your objective should always be to eliminate instructions entirely by making everything self-explanatory, or as close to it as possible. When instructions are absolutely necessary, cut them back to the bare minimum"
e.g. "Please help us improve the site by answering these questions. It should only take you 2-3 minutes to complete this survey.
NOTE: If you have comments or concerns that require a response don't use this form. Instead, please contact <link>Customer Service</link>"
how do you create the proverbial "clear, simple, and consistent" navigation?
you go to Sears to buy a chainsaw. you walk in the door, thinking, "hmmmm. where do they keep chainsaws?". you decide whether or not to ask a salesperson. if not, you look at the large department name signs. you choose between tools, housewares, laws and garden (you choose tools). then, when you reach tools, you look at the signs on the end of each aisle. if you can't find it, you may ask a salesperson, or you may just leave.
similarly, on the web, the user is usually trying to find something. the equivalent of asking a salesperson is the "search" function.
some ppl ("Jakob Nielsen calls them 'search-dominant' users) tend to want to use a search box upon arriving at a site. some people tend to want to browse the site. some do either depending on various factors.
if you browse, you'll make your way through a hierarchy on the site.
diffs:
bookmarks are important, and the back button accounts for between 30-40% of web clicks
the web vs. physical space: pros: teleportation -> sense of weightlessness; get "lost" in a web page like in a good book. cons: "figuring out where you are" can be a problem
the Home page of a site is so important b/c it is like the North Star; a relatively fixed place. "being able to click Home gives you a fresh start"
obvious purposes:
often overlooked purposes:
follow conventions! helps users not think
current basic conventions for a website:
the five elements "you most need to have on hand at all times":
your navigations elements should stay the same on almost every page! exceptions:
in these cases you can offer no or reduced navigation.
don't forget tertiary, quaternary, etc navigation: " it's happened so often i've come to expect it: when designers i haven't worke with before send me preliminary page designs so that i can check for usability issues, i almost inevitably get a flowchart that shows a site four levels deep...and sample pages for the Home page and the top two levels ((only)) .... failing to give lower-level navigation the same attention as the top ... users usually ... ((spend)) as much time on lower-level pages as they do at the top"
page names:
highlight the current location in navigational elements, using e.g. pointers next to it, change of text color, bold, reversed foreground/background color, change of background color
"The most common failing of 'you are here' indicators is that they're too subtle. They need to stand out; if they don't, they lose their value as visual cues and end up just adding more noise to the page. One way to ensure that they stand out is to apply more than one visual distinction -- for instance, a different color __and__ bold text.
Too-subtle visual cues are actually a very common problem. Designers love subtle cues, because subtlety is one of the traits of sophisticated design. But Web users are generally in such a hurry that they rountinely miss subtle cues.
In general, if you're a designer and you think a visual cue is sticking out like a sore thumb, it probably means you need to make it twice as prominent "
not good enough to be the only navigation system, but often good as an accessory navigation system, esp. on large sites with a deep hierarchy. if you do use them:
i love tabs
"one of the very few cases where using a physical metaphor in a user interface actually works...(the idea of dragging things to a trash can icon....is the only other one that springs to mind...sadly, Apple couldn't resist muddying the metaphorical waters by using the same drag-to-trash action to eject diskettes -- ultimately resulting in millions of identical thought balloons says, "But wait. Won't that erase it?")"
"Imagine that you've been blindfolded and locked in the trunk of a car, then driven around for awhile and dumped on a page somewhere ... in ... a web site. If the page is well-designed....you should be able to answer these questions without hesitation:
here's how you perform the trunk test:
site IDs should be in the upper-left corner (mb not above breadcrumbs, if they are there, tho)
avoid stacking underlined text links
"...flush left or right alignment is more effective than centering in "telegraphing" a visual hierarchy" so you may want to put a page name flush left if it is a subpage within a hierarchy similarly, u may want to put search button next to search box, on the left or right edge of the page
avoid making pages like this: "navigation spread all over the page, making it much harder to tell what's navigation and what isn't. The navigation, ads, promos, and content all run together... it's hard to tell where the content actually starts...((the page)) seems to keep starting over, forcing you to scroll down just to find out what it is"
amazon.com is generally awesome, a good example of what to do
todo: pics of 90-93
"...if you're going to scope a search, it's worth adding the word "for" so it reads like a sentence: 'Search ___ for ___'"
the home page often has to accomodate:
more abstractly, it must:
issues:
you usually can't do all of this, so Home page design involves compromise.
priority one: CONVEY THE BIG PICTURE. make it clear __what the site is__. "as quickly and clearly as possible", answer these 4 questions for a first-time visitor:
"i need to be able to answer these questions at a glance, correctly and unambiguously, with very little effort...don't get me wrong: Everything else __is__ important. You __do__ need to impress me, entice me, direct me, and expose me to your deals. But these things won't slip through the cracks; there will always be plenty of people -- inside and outside the development team -- seeing to it that they get done. All too often, though, no one has a vested interest in getting the main point across."
places to explain what the site is:
when explaining what the site is:
"taglines are a very efficient way to get your message across, because they're the one place on the page where users most expect ot find a concise statement of the site's purpose". every site should have one.
make it:
p.s. if too long, at least put a few key words in boldface to make it scannable.
"after a quick look around the Home page" a new user should be able to answer:
The Home page navigation doesn't have to have navigation exactly matching the way the rest of the site's navigation looks/works. But it shouldn't diverge too much. some potential divergences:
but should keep the sections names exactly the same (same wording, etc, and even the same visual cues if possible)
they save space, but: you have to click on them to see the list, they're hard to scan, and they're hard to read because the list comes and goes quickly. some users like them and some dislike them. they're okay for alphabetized lists of things with known names, though, like countries or states.
there's a tragedy of the commons danger; each department gains when their item is added to the home page, but this is outweighed by a loss suffered by all departments as the home page becomes more cluttered
ppl on web design teams often end up assuming that their personal usability prefs are everyone's prefs. and they have different personal prefs, causing arguments.
there is no "typical user", just a bunch of users with various idiosyncracies.
"the point is, it's not productive to ask questions like, 'do most people like pulldown menus?" The right kind of question to ask is "Does __this__ pulldown, with __these__ items and __this__ wording in __this__ context on __this__ page create a good experience for most people who are likely to use __this__ site? And there's really only one way to answer that kind of question: testing'
the key is to do lots of usability tests, and start doing them early. do them cheaply
don't start usability testing only 2 weeks before product launch!
often usability testing is done to settle arguments. often the result is that the thing that was being argued about isn't that important, and that the site has bigger problems that were not known; "People often test to decide which color drapes are best, only to learn that they forgot to put windows in the room"
"In a focus group, a small group of people (usually 5 to 8) sit around a table and react to ideas and designs that are shown to them. It's a group process, and much of its value comes from participants reacting to each other's opinions. Focus groups are good for quickly getting a sampling of users' opinions and feelings about things. in a usability test, one user at a tiem is shown something (whether it's a Web site, a prototype of a site, or some sketches of individual pages) and asked to either (a) figure out what it is, or (b) try to use it to do a typical task.
Focus groups can be great for determining what your audience wants, needs, and likes -- in the abstract. They're good for testing whether the idea behind the site makes sense and your value proposition is attractive. And they can be a good way to test the names you're using for features of your site, and to find out how people feel about your competitors.
But they're __not__ good for learning about whether your site works and how to improve it.
The kinds of things you can learn from focus groups are the things you need to learn early on, __before__ you begin designing the site. "
the basic idea is: "if you want to know whether your software or your Web site or your VCR remote control is easy enough to use, watch some people while they try to use it and note where they ran into trouble. Then fix it, and test it again."
"__If you can afford to hire a professional to do your testing, by all means do it__! But __don't__ do it if it means you'll do less testing"
do it really cheaply, with 3 or 4 users, no special room, almost any users. costs $300/user or less. pay each user a $50-$100 stipend.
2 tests with 3 users is better than 1 test with 8 users
"Recruit loosely and grade on a curve ... In other words, try to find users who reflect your audience, but don't get hung up about it. Instead, try to make allowances for the differences between the people you test and your audience. "
don't bother to find users who reflect the target audience, because:
exceptions:
"typical stipends for a one-hour...session range from $50... to several hundred dollars for professionals from a specific domain, like cardiologists for instance. I like to offer people a little more than the going rate."
"keep the invitation simple. 'We need to have a few people look at our Web site and give us some feedback. It's very easy, and would take about forty-five minutes to an hour. And you'll be paid $__ for your time.'"
"avoid discussing the site (or the organization behind the site) beforehand. You want their first look to tell you whether they can figure out what it is from a standing start."
"Don't be embarrassed to ask friends and neighbors. You don't have to feel like you're imposing if you ask friends or neighbors to participate. Most people enjoy the experience." (but pay them normally)
room with two chairs, computer, camcorder, long video cable, and tripod. point the camcorder at the screen and use it to broadcast a live feed to the rest of the team in another room. don't record the session with a camcorder -- but do use a screen recorder on the computer (he likes Camtasia)
"almost anyone can facilitate a usability test; all it really takes is the courage to try it. With a little practice, most people can get quite good at it.
Try to choose someone who tends to be patient,calm, empathetic, a good listener, and inherently fair. Don't choose someone whom you would describe as 'definitely not a people person' or 'the office crank'.
anyone who wants to. and anyone who needs to be convinced of the need for spending resources on usability.
test early.
before designing your site, test comparable sites.
two kinds of testing: "get it" testing and key task testing.
"...you'll...get more revealing results if you can find a way to observe users doing tasks that they have a hand in choosing. It's much better, for instance, to say, 'Find a book you want to buy, or a book you bought recently" than "Find a cookbook for under $14".
"As you begin designing your own site, it's never to early to start showing your design ideas to users, beginning with your first rough sketches. Designers are often reluctant to show work in progress, but users may actually feel freer to comment on something that looks unfinished.... also... users won't be distracted by details of implementation and they can focus on the essence and the wording."
"I also recommend... what I call Cubicle tests: Whenever you build a new kind of page -- particularly forms -- you should print the page out and show it to the person in the next cubicle and see if they can make sense out of it"
usability test script from http://sensible.com/ (http://sensible.com/Downloads/test-script.doc):
" Usability test script Reprinted from Rocket Surgery Made Easy © 2010 Steve Krug
Web browser should be open to Google or some other “neutral” page Hi, ___________. My name is ___________, and I’m going to be walking you through this session today. Before we begin, I have some information for you, and I’m going to read it to make sure that I cover everything. You probably already have a good idea of why we asked you here, but let me go over it again briefly. We’re asking people to try using a Web site that we’re working on so we can see whether it works as intended. The session should take about an hour. The first thing I want to make clear right away is that we’re testing the site, not you. You can’t do anything wrong here. In fact, this is probably the one place today where you don’t have to worry about making mistakes. As you use the site, I’m going to ask you as much as possible to try to think out loud: to say what you’re looking at, what you’re trying to do, and what you’re thinking. This will be a big help to us. Also, please don’t worry that you’re going to hurt our feelings. We’re doing this to improve the site, so we need to hear your honest reactions.
If you have any questions as we go along, just ask them. I may not be able to answer them right away, since we’re interested in how people do when they don’t have someone sitting next to them to help. But if you still have any questions when we’re done I’ll try to try to answer them then. And if you need to take a break at any point, just let me know. You may have noticed the microphone. With your permission, we’re going to record what happens on the screen and our conversation. The recording will only be used to help us figure out how to improve the site, and it won’t be seen by anyone except the people working on this project. And it helps me, because I don’t have to take as many notes. Also, there are a few people from the Web design team observing this session in another room. (They can’t see us, just the screen.) If you would, I’m going to ask you to sign a simple permission form for us. It just says that we have your permission to record you, and that the recording will only be seen by the people working on the project.
Give them a recording permission form and a pen While they sign it, START the SCREEN RECORDER
IF YOU ARE USING A NON-DISCLOSURE AGREEMENT (optional): I know we also sent you a non-disclosure agreement that says that you won’t talk to anybody about what we’re showing you today, since it hasn’t been made public yet. Do you have that with you?
Accept the NDA and make sure that it’s signed. If they don’t have it with them, hand them a copy and give them time to read and sign it.
Do you have any questions so far? OK. Before we look at the site, I’d like to ask you just a few quick questions. First, what’s your occupation? What do you do all day?
Now, roughly how many hours a week altogether—just a ballpark estimate— would you say you spend using the Internet, including Web browsing and email, at work and at home?
And what’s the split between email and browsing—a rough percentage?
What kinds of sites are you looking at when you browse the Web?
Do you have any favorite Web sites?
OK, great. We’re done with the questions, and we can start looking at things.
Click on the bookmark for the site’s Home page. First, I’m going to ask you to look at this page and tell me what you make of it: what strikes you about it, whose site you think it is, what you can do here, and what it’s for. Just look around and do a little narrative. You can scroll if you want to, but don’t click on anything yet.
Allow this to continue for three or four minutes, at most.
Thanks. Now I’m going to ask you to try doing some specific tasks. I’m going to read each one out loud and give you a printed copy. I’m also going to ask you to do these tasks without using Search. We’ll learn a lot more about how well the site works that way. And again, as much as possible, it will help us if you can try to think out loud as you go along.
Hand the participant the first scenario, and read it aloud. Allow the user to proceed until you don’t feel like it’s producing any value or the user becomes very frustrated. Repeat for each task or until time runs out. Thanks, that was very helpful. If you’ll excuse me for a minute, I’m just going to see if the people on the team have any follow-up questions they’d like me to ask you.
Call the observation room to see if the observers have any questions. Ask the observers’ question, then probe anything you want to follow up on. Do you have any questions for me, now that we’re done?
Give them their incentive, or remind them it will be sent to them. Stop the screen recorder and save the file. Thank them and escort them out. "
"don't hesitate to admit your ignorance about anything. your role here is not to come across as an expert, but as a good listener"
the user may not be sure how much time e really spends on the internet. that's ok, accurate answers aren't important there, "the main point is just to get her talking and thinking about how she uses the Internet and to give you a chance to gauge what kind of user she is"
"don't get too excited by individual reactions to site aesthetics" -- i.e. some users will like or hate the colors, etc
if the user isn't thinking out loud much, the conductor might ask "what are you thinking?"
"I strongly recommend doing three or four tests in a morning and then debrief over lunch."
During debriefing, do both triage ("reviewing the problems people saw and deciding which ones need to be fixed"), and problem solving ("figuring out how to fix them").
"The important things that you learn from usability testing usually __just make sense__. They tend to be obvious to anyone who watches the sessions."
three most common problems you'll see in testing:
and also:
"Sometimes the real challenge isn't fixing the problems you find -- it's fixing them __without__ breaking the parts that already work."
"...when you're making something more prominent that it was, consider what else might end up being de-emphasized as a result."
"In a morning, you can test three or four users, then debrief over lunch. When you leave lunch, the team will have decided what you're going to fix, and you'll be done with testing for the month. No reports, no endless meetings. Doing it all in a morning also greatly increases the chancs that most team members will make time to come and watch at least some of the sessions, which is highly desirable."
debrief on the same day, conference call rather than written report
suggest:
with 3 users/test. if you pay each user $100, and do the max recommended 3 tests when it says 1-3, then that's 13 tests times 3 users, which costs $3900 in user stipends ($1500 is the min recommended).
don't hide information that users want, e.g. customer support phone numbers, shipping rates, or prices
don't require users to format their data in a certain way. e.g. your site should work with or without dashes in social security numbers, spaces in credit card numbers, parentheses in phone numbers
don't ask for information that isn't really needed, e.g. personal information
don't display "faux sincerity, or "disingenuous attemtps to convince me that you care", e.g. "your call is important to us" on a phone wait queue
don't "put sizzle in ((the user's)) way", e.g. a long Flash intro, or pages bloated with feel-good marketing photos
don't allow your site to look amateurish, sloppy, disorganized, or unprofessional (however, "note that while people love to make comments about the appearance of sites -- especially about whether they like the colors -- almost no one is going to leave a site just because it doesn't look __great__ ... ignore all comments that users make about colors during a user test, unless 75% of people use a word like "puke" to describe the color scheme)
sometimes there is a business case to do something that make users unhappy for some other reason -- e.g. users hate uninvited popups, but if they give you 10% more revenue, you might do them anyway -- but at least be clear about the tradeoff.
do "know the main things that people want to do on your site and make them obvious and easy...((this is)) usually not hard...even people who disagree about everything else about their organization's site almost always give me the same answer when i ask them,'what are the three main things your users want to do?'. The problem is, making those things easy doesn't always become the top priority... ((e.g.)) if ... people are coming to your site to apply for a mortgage, nothing should get in the way of making it dead easy to apply for a mortgage"
do tell the user what they want to know. "be upfront about things like shipping costs, hotel daily parking fees, service outages -- anything you'd rather __not__ be upfront about"
do save the user steps whenever you can. e.g. "instead of giving ... the shipping company's tracking number, put a link in my email receipt that opens their site and submits my tracking number..."
do know what questions users are likely to have, and answer them. keep FAQs up to date by asking customer support and tech support what the top questions are each week. be candid in the FAQs.
do provide users with creature comforts like printer-friendly pages (without ads)
do make it easy to recover from errors. you can read Defensive Design for the Web for help with this.
do apologize when you know there's a problem, and you can't fix it
section 508 of the 1988 amendments to the rehabilitation act gives some usability standards for companies that want to do business with the U.S. government
but really, why do usability? because it is nice to help disabled people
make the site work when the user increases or decreases the font size with their browser
you can "use a validator like Bobby to make sure your site complies with the WCAG guidelines", bu it doesn't work too well yet, and might intimidate you with a long list of warnings
provide alt text
supporting mobile devices shares some issues with accessibility
fixing usability problems that confuse everyone is a prerequisite for successful usage by disabled people, too
recommended short article: http://www.redish.net/content/papers/interactions.html
recommended books:
use CSS
"make your forms work with screen readers. this largely boils down to using the HTML 'label' element to associate the fields with their prompts..."
"create a 'skip to main content' link at the beginning of each page. imagine having to spend 0 seconds (or a minute, or two) listening to the global navigation at the top of every page before you could look at the content, and you'll understand why this is important"
"make all content accessible by keyboard. remember, not everyone can use a mouse"
remember that some users won't be able to use javascript
"use client-side (__not__ server-side) image maps. alt tags don't work with server-side image maps"
