If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

In general, advertising doesn’t work on the Web, a fact that has been clear to usability researchers since 1997. Users ignore ads because they are contrary to the Web’s basic imperative, which is to let users go where they want and get their information needs instantly gratified.

From the beginning, it was also clear that this indictment of Web advertising had two exceptions:

• Classified ads work because as far as users are concerned, they are content, not advertising: people actively seek out the classifieds when they are looking to buy. This explains the success of eBay, Monster/HotJobs, and many such sites. The superiority of Web classifieds portends dire times ahead for traditional printed newspapers, as their most lucrative income source continues to migrate online.
• Search engine ads work because search engines are the one type of website that people visit with the explicit goal of finding someplace else to go. Thus, if users see an ad for what they’re looking for, there is a high probability that they’ll click that ad. Advertisers can satisfy a user’s immediate needs because they target ads based on the user’s query terms. (This also explains why ads on search engine homepages don’t work: it’s impossible to target the ad to the user’s current quest until the server knows what that quest is.)

Both are examples of request marketing: prospects have explicitly asked for the promotions they are being shown, as opposed to having unwanted messages thrown at them. Text-only ads on search engines have become particularly successful in recent years, and non-search sites are now experimenting with this format in hope of replicating that success. However, it’s doubtful that their efforts will work because non-search sites lack the equation’s crucial element: users’ single-minded goal to leave the site as quickly as possible.

From Banner Blindness to Box Blindness?

Text-only ads might continue to work better than traditional graphics-based ads for some time to come. Web users have long exhibited strong banner blindness and avoid anything that looks like an advertisement. Text-only ads don’t resemble the designs that people have trained themselves to screen out, and the resulting visibility surely contributes to the success of text-only ads. Also, text-only ads benefit from a temporary novelty effect, as does any new advertising format that people have not yet learned to ignore.

Over the long term, however, the novelty effect will obviously fade. Users might also develop box blindness, ignoring little text boxes just as they’ve long ignored banner-shaped areas of the screen. Thus, text-only ads are not guaranteed a bright future outside their native search engine habitat.

Communicative Content

Text-only ads might have one durable advantage: because they’re a low-end media format, users might take them more seriously. Being forced to express a message in a few words concentrates the advertiser’s mind, and probably leads to more communicative ads that are better focused on explaining how users will benefit from the product or service. Although there is no inherent reason that you can’t use text for mindless chatter — like “where do you want to go today?” — there is no way users will click on such ads. Ignoring users’ immediate needs is certain death on the Web.

Companies that run rich-media ads that ignore user needs can delude themselves into thinking that they’re “promoting the brand”; in reality, they’re simply being ignored because they don’t connect with people’s needs. The text-only format more clearly exposes content-free messages as useless, however, and thus might save advertisers from the bad instincts they honed on old media.

After ten years of watching Web users, one clear conclusion is that they 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.

• 0 Comments

Microcontent needs to be pearls of clarity: you get 40-60 characters to explain your macrocontent. Unless the title or subject make it absolutely clear what the page or email is about, users will never open it. The requirements for online headlines are very different from printed headlines because they are used differently. The two main differences in headline use are:

• Online headlines are often displayed out of context: as part of a list of articles, in an email program’s list of incoming messages, in a search engine hitlist, or in a browser’s bookmark menu or other navigation aid. Some of these situations are very out of context: search engine hits can relate to any random topic, so users don’t get the benefit of applying background understanding to the interpretation of the headline. The same goes for email subjects.
• Even when a headline is displayed together with related content, the difficulty of reading online and the reduced amount of information that can be seen in a glance make it harder for users to learn enough from the surrounding data. In print, a headline is tightly associated with photos, decks, subheads, and the full body of the article, all of which can be interpreted in a single glance. Online, a much smaller amount of information will be visible in the window, and even that information is harder and more unpleasant to read, so people often don’t do so. While scanning the list of stories on a site like news.com, users often only look at the highlighted headlines and skip most of the summaries.

Because of these differences, the headline text has to stand on its own and make sense when the rest of the content is not available. Sure, users can click on the headline to get the full article, but they are too busy to do so for every single headline they see on the Web. I predict that users will soon be so deluged with email that they will delete messages unseen if the subject line doesn’t make sense to them.

If you create listings of other people’s content, it is almost always best to rewrite their headlines. Very few people currently understand the art of writing online microcontent that works when placed elsewhere on the Web. Thus, to serve your users better, you have to do the work yourself.

Guidelines for Microcontent

• Clearly explain what the article (or email) is about in terms that relate to the user. Microcontent should be an ultra-short abstract of its associated macrocontent.
• Written in plain language: no puns, no “cute” or “clever” headlines.
• No teasers that try to entice people to click to find out what the story is about. Users have been burned too often on the Web to have time to wait for a page to download unless they have clear expectations for what they will get. In print, curiosity can get people to turn the page or start reading an article. Online, it’s simply too painful for people to do so.
• Skip leading articles like “the” and “a” in email subjects and page titles (but do include them in headlines that are embedded within a page). Shorter microcontent is more scannable, and since lists are often alphabetized, you don’t want your content to be listed under “T” in a confused mess with many other pages starting with “the”.
• Make the first word an important, information-carrying one. Results in better position in alphabetized lists and facilitates scanning. For example, start with the name of the company, person, or concept discussed in an article.
• Do not make all page titles start with the same word: they will be hard to differentiate when scanning a list. Move common markers toward the end of the line. For example, the title of this page is Microcontent: Headlines and Subject Lines (Alertbox).
• In email sent from your website, make the “From” field clarify the customer relationship and reduce the appearance of spam or anonymous intrusion (but don’t use the name of the customer service rep. unless the user has actually established a relationship with that person: mail from unknown people also has a tendency to be deleted and will be harder for users to find in a search).

Examples

Email subject: Opportunity

Makes the message seem like spam. A sure way to be deleted unread.

Email subject: Web Design Conference in Norway

Sounds like a conference announcement: would be deleted unread by somebody who doesn’t plan to travel to Norway any time soon. Better subject line: Invitation: Keynote speaker at Norwegian Web Design Conference.

Email from line: musicblvd@musicblvd.com
Email subject: Your Music Boulevard Order

Not a horrible subject, but it would have been better to say Music Boulevard Order Shipped to You Today (starting with an information-carrying word and being more precise than the original). The from line should have included a human-readable name like Music Boulevard Customer Service

Page title: Big Blue and Wall Street too

Probably has something to do with investing in IBM, but people who don’t know that nickname would be at a complete loss and would never be attracted to clicking on this headline. Even people who do realize that the story will be about IBM don’t get told what’s new or interesting in the article.

Page title: Reading your PC

Say again? What can this possibly be about? This is a real example (as are all the others) from a major U.S. newspaper. It probably worked fine in print, but not in a listing of headlines on a third-party website.

Page title: Sound Card Competition Heats Up

When shown on a computer-related site, this is a great headline. When placed out of context it may be better to add a qualifier: Sound Card Competition Increases in PC Market. Note that the page title will still work if the last part is chopped off in some listings.

• 1 Comment

Well-designed B2C sites can easily explain their products and services in text that is short enough that users will actually read it online. AutoTrader.com, for example, tells us to “Search the largest inventory of cars and trucks on the Internet. More than 1.5 million listings, updated daily.” Given this information, most people can figure out what the site does.

Relative to B2C, most B2B sites sell products or services that are much more complex and have less connection to everyday experience. Summarizing a website’s purpose is thus much harder in B2B than in B2C. That’s why they pay copywriters the big bucks, or so you would think. On closer examination, it seems that most sites pay their copywriters to obscure the site’s purpose rather than state it clearly.

Obscurity in action

Here are the taglines from four websites: Angara, Calico, CSG Systems, and E.piphany:

• Creating customers online
• eBusiness for leaders: Enabling corporations to control the key elements of eBusiness selling
• Harness the power of convergence with (company’s name)
• Software for the customer economy: next-generation CRM software

Can you match the taglines with the company they describe? Can you tell which company does what? Is there a difference between these companies? Do you care?Regarding the first question: I listed the taglines in the same order as I listed the companies above them. But the real point here, as you no doubt discovered, is that these taglines are basically content-free word count. They do nothing more than clutter up their respective home pages.

Getting it (half) right

I collected the above taglines a few months ago. As I prepared to write this column, I revisited the sites and found that CSG Systems had dropped the tagline “Harness the power of convergence.” The company is now wisely willing to tell us what they actually sell: “customer care and billing solutions.” Much more specific, and thus more likely to harness the attention of stressed-out business executives looking at the homepage in search of products.The new CSG Systems website actually does several things right. The home page is reasonably simple, despite an annoying Flash animation that will likely distract visitors. The main text looks like it’s written based on my guidelines for online content: Short paragraphs, scannable layout, a bulleted list:

Unfortunately, when you read the words, you realize that the company is still paying copywriters to avoid communicating with prospective customers. Note how the “solutions” are robust, integrated, efficient, and cost-effective. As opposed to what? A product that was buggy, fragmented, inefficient, and expensive? Given that a website would never advertise such a product, stating the opposite has zero informative value.

Tagline guidelines

Users decide quickly whether to stay or leave a site. To assess whether your homepage communicates effectively to visitors in the crucial first 10 seconds, follow two simple guidelines.

• First, collect the taglines from your own site and your three strongest competitors. Print them in a bulleted list without identifying the company names. Ask yourself whether you can tell which company does what. More important, ask a handful of people outside your company the same question.
• Second, look at how you present the company in the main copy on the home page. Rewrite the text to say exactly the opposite. Would any company ever say that? If not, you’re not saying much with your copy, either.

When I’m attempting to build a shortlist of potential vendors, the experience of looking at home pages reminds me of the frustration I usually feel walking a tradeshow floor. I recently attended an intranet conference that had booths from at least 20 different search engine providers. I simply could not tell the difference between these companies. Who did what? Which technologies would make sense for which type of problem? Which products would fit the budget for which projects? The booths were essentially random designs. While they clearly cost huge amounts of money, they failed to communicate anything distinct to a tired tradeshow visitor pacing up and down the aisles.Think about your home page as analogous to a tradeshow booth. Why do you stop at some booths and skip others? And, no: having a live magician is not the answer for your home page. Clearly saying what you do and why users should care is the way to go.

• 0 Comments

Sometimes technological progress backfires, and the “better” technology turns out to be worse for users. The Web is no stranger to this problem, and has experienced many innovations that would have been best avoided. Examples include frames, changing the color of browser scrollbars, and scrolling text.

Another example of harmful Web technology comes with the increasing use of style sheets, which let web designers specify the exact size of text down to the pixel. Unfortunately, many designers are using this ability, leading to reduced readability of an increasing number of websites.

The State of Font Control

I’m hereby launching a campaign to get Microsoft to make user preferences override any fixed font size specification in Web designs. It may be okay for the browser to initially render the page with the designer’s text size, but users should be able to easily enlarge text, no matter what the style sheet says. After all, it’s my screen, my computer, and my software, and they should do what I say.

Granted, some web browsers have a geeky feature that lets users specify their own style sheets. Fine for experts, but 99% of users simply want to make text bigger if it’s too small to read. The Mac-only iCab browser gives users this simple control; let’s make Internet Explorer equally friendly to users’ needs.

So, why is so much website text so hard to read in the first place? Two theories:

• Most web designers are young, and so have perfect vision. Tiny text doesn’t bother them as much as it bothers people on the other side of 40. Designers also tend to own expensive, high-quality monitors that are easier on the eyes.
• While creating a website, designers don’t actually read the information on the pages. They simply glance at the text to make sure it looks great. In fact, many designs are approved with “lorem ipsum” standing in the place of real copy. When you don’t have to read the words, it doesn’t matter that the characters are small.

Because so many sites have made bad decisions regarding font size, users commonly need to change it. Early IE versions supported this need, offering users two standard toolbar buttons: one that made text bigger, and the other that made it smaller. That’s the way things should be. Mr. Gates, please give us back the good design you shipped in IE4 for the Mac.

Simplifying Browser Font Control

Unfortunately, recent versions of IE have eliminated IE4’s good design, replacing it with an approach that has two serious usability problems:

• The text size button is no longer visible by default. Only the minuscule percentage of users who customize their toolbars will get this highly useful button. Most users see instead the default toolbar, which is polluted with buttons that have much less utility. Because the feature is hidden, few users realize that their browser can change text size.
• Separate buttons no longer exist for text-bigger and text-smaller. If users can find it at all, they’ll get a single button to control both directions of text change.

For those few experienced users who do prevail and restore the missing button to their customized toolbar, actually changing the text size in IE6 requires several steps:

1. Acquire the button by moving the mouse pointer over it. Since buttons are reasonably big in IE, this step is fairly quick according to Fitts’s Law.
2. Press down the mouse button.
3. This causes a pull-down menu to appear, with five possible font sizes. Scan this menu, making a mental note of which font size is currently selected.
4. Mentally compute which new font size you want. This is typically one size bigger (or smaller) than the current selection.
5. While you continue to press the mouse button, move the pointer down the menu until it points to the desired new font size.
6. Let go of the mouse button.

Compare this awkward, six-step process with the interaction technique required by a design that includes separate buttons for “make text larger” and “make text smaller”:

1. Click the desired button.

Of course, I am cheating a little: You would still have the initial step of deciding whether you want the text larger or smaller, thus determining which button you’d click. Still, since the entire change-font-size procedure is triggered by your annoyance at trying to read unpleasantly sized text, you already know that you want bigger (or smaller) text by the time you decide to change the size. (The average user doesn’t have a mental model of a single “change size” command that is parameterized with the desired direction of change; the user’s model includes two actions: “bigger” and “smaller.” How the code is implemented is irrelevant for the user illusion which should be designed to match the users’ mental model.) The two-button approach frees users from the cognitive overhead of calculating how big they want the text to be. Just make it bigger. Users don’t want to specify exactly how big. They can easily keep clicking the “bigger” button if the initial click doesn’t make the text big enough.

Usability is enhanced by single action buttons that move along a uni-dimensional axis in simple steps, as long as each step’s result is immediately clear after each click. That’s also why the Back button is so precious to users, and why it’s used much more frequently than history list navigation.

Improving Future Browsers

Reverting to IE4’s design for the Mac would be a great step forward for font size usability. Still, we can do better.Instead of having users manually change the text size every time they come across a user-hostile design, let’s take advantage of the Internet and track font size preferences: Every time your browser loaded a page from a new website, it would first check a database for information about your predicted font size preference:

• If it’s a site you had visited before, a database on your local machine would keep a record of whether you had clicked the text-larger or text-smaller buttons during your previous visits. If so, it would automatically adjust the text accordingly.
• If this were your first visit to the site, your browser would contact a central database for information about the actions of users similar to you who’d visited the site. It would then apply these users’ average adjustment to the first page you see from the site. If you make any additional changes, your local database would note a revised preference and log the modification with the central database.

To expedite response time, your browser might pre-fetch the preference settings for all websites that the current page linked to before you even clicked a link.The central database itself would be a straightforward case of collaborative filtering, since it would be easy to find other users with the same text-size preferences. For any given web page, most users would either leave it alone or request text that’s one or two sizes larger or smaller. Because a total of five options would account for the vast majority of users, font size preferences would be much easier to model than, say, taste in books or films.

Auto-adjusting font sizes based on collaborative filtering is a simple example of the benefits that could accrue from more network-aware browsers. It would also be possible to auto-repair many broken links, auto-remove annoying ads or pop-ups, and make many other improvements to individual users’ experience based on feedback from prior site visitors.

We must stop thinking of browsers as trivial pieces of free software that aim at nothing more than rendering web page pictures on the screen. We need user-supportive environments that facilitate navigation and protect users from the excesses of bad websites.

Readability Guidelines for Websites

We can’t wait for Microsoft to ship a good browser, though that has to be the ultimate solution to the font size problem. For now, websites can increase readability by following these guidelines:

• Do not use absolute font sizes in your style sheets. Code font sizes in relative terms, typically using percentages such as 120% for big text and 90% for small text.
• Make your default font size reasonably big (at least 10 point) so that very few users have to resort to manual overrides.
• If your site targets senior citizens, use bigger default font sizes (at least 12 point).
• If possible, avoid text that’s embedded within a graphic, since style sheets and font size buttons don’t have any effect on graphics. If you must use pictures of text, make sure the font size is especially large (at least 12 point) and that you use high-contrast colors.
• Consider adding a button that loads an alternate style sheet with really big font sizes if most of your site’s visitors are senior citizens or low-vision users. Few users know how to find or use the built-in font size feature in current browsers, and adding such a button within your pages will help users easily increase text size. However, because every extra feature takes away from the rest of the page, I don’t recommend such a button for mainstream websites.
• Maximize the color contrast between the text and the background (and do not use busy or watermarked background patterns). Despite the fact that low-contrast text further reduces readability, the Web is plagued by gray text these days.

• 0 Comments

The oldest usability guideline for any type of navigational design is to help users understand where they’ve been, where they are, and where they can go (past, present, and future). The three are somewhat interrelated: a good grasp of past navigation helps you understand your current location, since it’s the culmination of your journey. Knowing your past and present locations in turn makes it easier to decide where to go next.

On the Web, links are a key factor in this navigation process. Users can exclude links that proved fruitless in their earlier visits. Conversely, they might revisit links they found helpful in the past.

Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

The Price of Uniform Link Color

Generally, Web browsers are severely deficient in supporting user navigation. However, they do provide one feature that helps users orient themselves: browsers let designers display links in different colors, depending on whether the links lead to new pages or pages that users have seen before. Changing the color of visited links has been part of Web browsing since Mosaic arrived in 1993, so it’s completely standard; almost all users understand it. Currently, 74% of websites use different colors for visited and unvisited links, making this design approach a strong convention that people have come to expect.

Hypertext theory, the Web’s history, and current design conventions all indicate the need to change the color of visited links. Further, empirical observations from user testing have identified several severe usability problems on sites that violate this convention. When sites use the same color for visited and unvisited links, users:

• unintentionally revisit the same pages repeatedly;
• get lost more easily because their understanding of each link’s meaning is reduced;
• often misinterpret or overlook the difference between two similar links if they’re unsure about which one they’ve already visited; and
• give up faster because they have a reduced sense of mastery when the site fails to reflect their actions and thus help them navigate.

Such usability problems are particularly damaging to users with weak short-term memory, who often have trouble remembering what they’ve clicked without a visual representation. Of course, “weak short-term memory” is an inherent shortcoming of all humans, which is why all users are harmed by unchanging link colors. But this definitely impacts some people more than others, so it’s particularly important to change link colors if you have many older users.Given the extensive theoretical and empirical support for using different link colors, it’s astounding that a quarter of all websites continues to inflict extra usability problems on people by choosing a uniform link color.

Why the Problem Persists

Even people who believe in usability sometimes question the need for changing link colors. I think this is because they don’t pick up on the problems caused by unchanging links when they conduct their own user testing. Unfortunately, the symptoms of these problems are among the most difficult to detect when you observe users. User testing is basically easy: we teach it in three days. Most important usability problems are so glaring that anybody can identify them through a simple test. Once you know the basics of how to write good tasks and how to facilitate the session without biasing user behavior, you can clearly see users get into trouble when they encounter poorly designed components of your site.

Say, for example, that a user clicks the wrong button. It’s obvious to any observer that such behavior represents a design error. Listening to users’ comments prior to clicking usually tells you why they misunderstood the design, thus guiding you to make it better in the redesign.

Cases in which users don’t do something are harder to discover. Even so, most usability facilitators can identify many such problems. You might, for example, observe that no one in your test clicked on one of your major features. Users’ thinking-aloud comments will make it clear whether they (a) saw the feature, but didn’t find it relevant; or (b) never considered the feature because it looked too much like an advertisement.

Detecting Distributed Usability Problems

Some usability problems require more detective work and are often overlooked by people relatively new to user testing. This is particularly true for problems that are a composite of multiple individual issues scattered around the site. Identifying these problems is even more difficult when none of the individual issues cause difficulties on their own. A relatively simple example of a multi-location problem is when a homepage link sets certain expectations that cause users to misinterpret the information on the destination page. The link text itself might be clear, and users are unlikely to complain about it. The destination page might also be clear, and users might not complain about it, either, because they think they understand it. The problem is that they understand it wrong because they interpret it in the context of their misguided expectations. This type of usability problem requires test observers to make high-level conclusions based on remembering what happened on the previous page, even though nothing that happened seemed to cause users difficulties.

The damage that unchanging link colors cause is one of the most tricky usability problems to identify in user testing. On any given page, users seem to understand the links just fine. Users almost never complain about link colors, as long as they’re distinct from the rest of the text and reasonably legible. Life is good, or so it seems.

Observe carefully, though, and you’ll notice that users frequently move in circles. They’ll visit the same page multiple times — not because they want to, but because they don’t realize that they’ve already been there. Users will give up when they’ve tried most links in a list, even though there’s one link that they haven’t tried; if the links don’t change colors, users don’t realize that there’s only one unvisited link remaining.

Unchanging link colors also create navigational confusion because users don’t quite understand their different choices or where they are. Of course, this problem could also be a symptom of muddled information architecture or poorly written labels, which is why it requires experience to identify the true root cause of the users’ difficulties.

Even though the downsides of unchanging link colors are easily overlooked in user testing, they’re very real and problematic for users. Many other design strategies for helping users navigate, such as site maps, require a good deal of work. But the browser lets you change link colors for free, so there’s no reason not to take advantage of this simple way to help your users.

Using different colors for visited and unvisited links makes your site easier to navigate and thus increases user satisfaction.

• 0 Comments

Textual links should be colored and underlined to achieve the best perceived affordance of clickability, though there are a few exceptions to these guidelines. Here are the current usability guidelines for showing textual links:

• To maximize the perceived affordance of clickability, color and underline the link text. Users shouldn’t have to guess or scrub the page to find out where they can click.
• Assuming the link text is colored, it’s not always absolutely necessary to underline it.
  • There are two main cases in which you can safely eliminate underlines: navigation menus and other lists of links. However, this is true only when the page design clearly indicates the area’s function. (Remember: your design might not be as obvious to outside users as it is to your own team members.) Users typically understand a left-hand navigation rail with a list of links on a colored background, assuming it resembles the navigation areas on most other sites.
  • Exception: underlining is essential if you use link colors such as reds or greens, which cause problems for users with common forms of color-blindness.
  • Exception: underlined links are important for low-vision users’ accessibility, so retain underlines if accessibility is a priority for your site or you have many users with low vision.
• Don’t underline any text that’s not a link, even if your links aren’t underlined. Reserve underlining for links. Because underlines provide a strong perceived affordance of clickability, users will be confused and disappointed if underlined text doesn’t have an actual affordance to match this perception.
• Use different colors for visited and unvisited links.
  • The color for unvisited links should be more vivid, bright, and saturated than the color for visited links, which should look “used” (dull and washed out).
  • The two colors should be variants or shades of the same color, so that they’re clearly related. Using drastically different colors (say, orange and green) makes it hard for users to understand the relationship between the two types of links and to identify which color is the “used” version of the other.
  • Shades of blue provide the strongest signal for links, but other colors work almost as well.
  • As always, when using color to signal information, you should provide redundant cues for color-blind users. Making unvisited links brighter and more luminous than visited links will usually accomplish this goal.
• Never show text in your chosen link colors unless it’s a link.
  • You should generally avoid color for text unless it’s a link. However, assuming it differs from the link color, you can sometimes use colored text without causing major usability problems. For example, in a checklist summary, you could show the word “okay” in green and the word “error” in red. (The fact that the word meanings are clearly different provides the required redundant cue for color-blind users.)
  • Don’t use blue for non-link text, even if you don’t use blue as your link color. Blue is still the color with the strongest perceived affordance of clickability.
• There is no need to use special colors or other visualizations when the cursor hovers over a link. Doing so only makes the page appear more cluttered as the user moves the mouse across the screen.
  • Exception: if you’ve opted to present links with less than the maximum perceived affordance for clickability, you can recover some of the lost usability by signaling clickability when the user hovers over the link. For example, if your links aren’t underlined, you can make an underline appear while hovering.
  • In any case, don’t use bold-facing as a hover effect, because making the font wider may cause the text to re-align.
  • One useful hovering effect is to use link titles to help users predict where a link will lead before they click it. (If you’re using a mainstream browser, you can see this effect by hovering over the links in this column.)
• Don’t use tiny text for links. Don’t place links so close together that users with reduced motor skills will have difficulty selecting them. These guidelines are particularly important to ensure usability for older users.
  • Exception: It’s okay to use small font for links that few users will need (such as copyright info), as long as you place those links in a secondary location (such a footer) so users don’t feel obligated to read them.
  • If you target seniors or otherwise have many older users, ensure that your links appear in a big font (12 points or higher) and that links include enough text to make them easy to click on.

These guidelines all relate to the textual link appearance. It’s even more important that you carefully choose the link content (the actual words), but that’s another topic. Graphical links are yet another story, but it’s usually best to use text for most links anyway. Following the usability guidelines for link appearance on your site will make it easier for users to immediately determine what they can do on each page and will reduce the probability that they’ll overlook important links.

• 0 Comments

PDF is great for one thing and one thing only: printing documents. Paper is superior to computer screens in many ways, and users often prefer to print documents that are too long to easily read online.

For online reading, however, PDF is the monster from the Black Lagoon. It puts its clammy hands all over people with a cruel grip that doesn’t let go.

PDF Usability Crimes

The usability problems that PDF files cause on websites or intranets are legion:

• Linear exposition. PDF files are typically converted from documents that were intended for print, so the authors wouldn’t have followed the guidelines for Web writing. The result? A long text that takes up many screens and is unpleasant and boring to read.
• Jarring user experience. PDF lives in its own environment with different commands and menus. Even simple things like printing or saving documents are difficult because standard browser commands don’t work.
• Crashes and software problems. While not as bad as in the past, you’re still more likely to crash users’ browsers or computers if you serve them a PDF file rather than an HTML page.
• Breaks flow. You have to wait for the special reader to start before you can see the content. Also, PDF files often take longer time to download because they tend to be stuffed with more fluff than plain Web pages.
• Orphaned location. Because the PDF file is not a Web page, it doesn’t show your standard navigation bars. Typically, users can’t even find a simple way to return to your site’s homepage.
• Content blob. Most PDF files are immense content chunks with no internal navigation. They also lack a decent search, aside from the extremely primitive ability to jump to a text string’s next literal match. If the user’s question is answered on page 75, there’s close to zero probability that he or she will locate it.
• Text fits the printed page, not a computer screen. PDF layouts are often optimized for a sheet of paper, which rarely matches the size of the user’s browser window. Bye-bye smooth scrolling. Hello tiny fonts.

Users Hate PDF

In several recent usability studies, users complained woefully whenever they encountered PDF files. Following are quotes from investors testing the investor relations area on corporate websites:

“It’s a pain that I have to download each PDF. Pain in the ass… I find it to be annoying. It’s slow to load. It’s hard to search within it. I find HTML easier to deal with… This is all PDF instead of a chart. My dream site is to come to a site and get a bar chart for the sales within the last ten years.”

“I hate Adobe Acrobat. If I bring up PDF, I can’t take a section and copy it and move it to Word. There could be stuff like graphics I don’t want. I prefer documents in HTML format so that it’s editable.”

The following user quotes are from journalists testing the PR area on corporate websites:

“They [PDF files] don’t behave like Web pages. It’s not the speed. It is like having a solid thing rather than a fluid thing.”

“What we’ve got is a page of a PDF document which is great when printed out, but on the screen it is hard to read. The print is too small…”

“I am a little frustrated with Acrobat… They made every page a file. So what happens here is when you scroll, it jumps, which is really not helpful.”

This quote is from an employee who was testing an intranet:

“It would have helped if the first page was an index and you could scroll to it. That must be what this side part means. But who am I to say?”

As the last quote shows, even when a PDF file has its own navigation aides, they don’t typically help because they’re nonstandard and based on a paper metaphor rather than hypertext navigation.

We’ve had similar reactions from users in many other studies, including tests of B2B websites where users complained when sites presented product specs or customer success stories in PDF instead of Web pages. Here’s a quote from a customer who shunned those parts of the site that were in PDF:

“It looks like I’m going to have to go to PDF, which I’m dreading.”

• 1 Comment

Forms, probably the one thing that made the internet popular among the business people. Thanks to this addition to HTML, users are able to interact with a website. Unfortunately, after web forms were first introduced, not a lot has been changed to them. However, with XForms and Web Forms 2.0 on the rise, this is probably going to change. But what are they? What are their new features? And more importantly, which one is going to be superior?

XForms

Lets start with the oldest technology: XForms. XForms 1.0 became a recommendation in late 2003 and an update, XForms 1.1, is already in development. One of the biggest advantages is that XForms is an XML namespace and can therefore be used in a lot of ways as a completely device-independant application. To understand what this means, take a look and/or read the introduction on XForms.

Now that I did my duty to give you a short introduction to XForms, lets take a look at its interesting parts: its features. XForms are always seperated into two 2 parts:

1. the XForm Model;
2. and the XForm UI.

The XForm Model is used to describe the form’s data and how to submit it, while the XForm UI is used to make the form available to the user. How the XForms UI should look is not described by the XForms specification in any way, so it’s up to the user agent to render the form in the most usable way. Because of this, it makes XForms very flexible and usable for the user.

First, lets take a look at the XForm Model. This is always defined in the model element. The model can take 3 different child elements:

• instance;
• submittion;
• and bind.

The instance element describes all the data which is to be gathered. Every piece of data gets its own element inside the instance.

The submittion element(s) describe(s) how and where to submit the data. Multiple submittion elements can be added to the model which make it possible to submit data to different servers, or using a different HTTP method. For instance, you can have 2 buttons in your form. One to save the data as a file on the server, and one to submit the data to a form which saves it in a database.

The bind element is where the actual fun begins. Using this element you can create a relation between elements. For instance, using a bind element you can specify that a certain element may only be enabled if the value of another element matches a predefined value. So if you have a form that can be used to pay for something, you can ask the user how he/she would like to pay. This could be either by Paypal, cash or credit card. In this case you can specify only to enable the input field where the user can enter the expiration date if the user selects credit card to be the payment method.

But bind also has other features. Take the type attribute for example. This attribute tells the user agent what data is allowed. Combine this with XML Schema, and you have a very powerful way of specifying what kind of data is allowed. This can vary between strings or integers, but also dates or URIs. If these are not enough, you can of course create your own schema with XML Schema for total control.

Another feature of bind is to calculate an outcome. For instance the combined value of two numbers that the user has entered, or an average, etc. The outcome of this calculation can be displayed on the page without even submitting the form data or using scripting.

Below is a small example of how a model could look like:

<model xmlns="http://www.w3.org/2002/xforms"
       xsd:xmlns="http://www.w3.org/2001/XMLSchema"
       my:xmlns="http://jero.net/lab/xml/ns">
 <instance>
  <my:to/>
  <my:amount/>
  <my:details/>
 </instance>

 <submittion action="pay-me-now.php" method="post" id="pay"/>
 <bind nodeset="to" type="xsd:string"/>
 <bind nodeset="amount" type="xsd:integer"/>
</model>

Because there’s no such thing as stand-alone XForm documents, the model element in the example above would normally be placed inside the xhtml:head element.

Now that we have taken a quick look at the XForm Model, lets take a look at the UI. As I said earlier in this article, XForms does not, unlike HTML, specify how the form controls should look, but what they do. That’s a major difference here, so make sure you understand that. Once you’ve got that pumped into your brain, let’s take a look at XForm’s form control elements. I will compare them with HTML’s controls to make it as easy a possible for you to understand them (isn’t that nice?). But to avoid confusion, I will refer to XForm elements as xform:element and html:element for HTML elements. If no namespace is present, you can asume that the element is part of the XForms namespace.

The input element

Just like HTML, XForms also has this element. However, unlike html:input element, you do not need to specify the kind of form control (input field, password, radio button etc.) because xform:input is only suitable for text. So xform:input will probably render as <html:input type="text">. All other purposes that html:input has are divided into other element which are described below.

The secret element

Unlike you might think, this is not the equavalent of <html:input type="hidden">, but instead it is the equavalent of <html:input type="password">.

The textarea element

Same as html:textarea. However, the cols and rows attributes are not required in XForms (as a matter of fact, they don’t even exist). For visual user agents, you can specify the dimension using CSS.

The output element

As I said earlier in this atricle, you can use the bind element in the XForm Model to calculate something and display it on the page. Together with the ref element we can refer to a bind element to show the outcome of the bind’s calculation.

The upload element

Same as <html:input type="file">.

The range element

This element is something we’ve never seen before on the internet besides in Flash applications. With this element you can specify a value in a certain range. So if you want to let the user choose between the numbers -10 and 10, you could of course use the xform:input element to let the user type the number in for himself. But with the range element you can make it the user easier to select the correct value in the range specified by the min and max attributes.. Accessibility++! However, this is of course nothing new. Just take a look at your volume control.

The trigger element

Same as <html:button> and <html:input type="button">.

The submit element

Same as <html:input type="submit"> and <html:button type="submit">.

The select and select1 element

What!? A number in an element name!? Yes, a number! And you better not mess with it because xform:select and select1 are pretty darn useful. These two elements are not only the equivalents of html:select, but also for checkboxes and radio buttons. All you need to do is put the available options inside the xform:select or select1 and let the user agent decide how it should look. This can be a list of checkboxes/radio buttons, drop-down list, or whatever the user agent think it’s best for the user.The difference between the two elements is that with select1 the user can only choose one value, while the user can select multiple options from xform:select elements.

To give you an example of how an XForm UI may look like, take a look at the possible UI for the model we created earlier:

<group xmlns="http://www.w3.org/2002/xforms">
 <label>Transfer Money</label>
 <input ref="to">
  <label>Receiver</label>
 </input>

 <input ref="amount">
  <label>Amount</label>
 </input>

 <textarea ref="details">
  <label>Additional details</label>
 </textarea>

 <submit submission="pay">
  <label>Transfer!</label>
 </submit>
</group>

As you see, the group element is used to group all the payment controls. In HTML we’d normally use fieldset for this. The xform:label inside the group can be compared with html:legend as they both act as a title for the group/fieldset. The xform:labels inside the xform:input elements are used as text to describe the xform:input element. This is comparable to the function of html:label. The xform:label inside the submit element will probably be rendered as text on a button, just how <html:button>Submit!</html:button> would be rendered.

Web Forms 2.0

Now that I gave you some info about XForms (yes, only some as there is a lot more), lets take a look at XForms’s younger stepbrother: Web Forms 2.0 (WF2). WF2 is developed by the WHATWG which is the same group who’s developing the Web Applications 1.0 specification, aimed at extending current markup languages (HTML 4.01 and XHTML 1.0). The same applies to WF2. Unlike XForms, WF2 does not want to replace current web forms. Intead, WF2 aims at extending current web forms which has one very important advantage: backwards compatibility.

When you’d read the Web Forms 2.0 specification, you’d be delighted with the fact that because of WF2’s backwards compatibility it is very easy to pick up, especially compared to XForms which is basically a pain the ass to learn. Just take a look at the INPUT element. Yes! Exactly the same as HTML 4.01’s INPUT element, although with new values for the type attribute:

datetime, datetime-local, date, month, week and time

These new values tell the user agent that only values that are encoded as defined in ISO 8601 (dates like 1996-01-01T00:00Z). When a WF2 confirming user agent would see an INPUT with either of these values for the type attribute, it could make it the user easy and display the input field as . This way the user agent can make sure that the submitted date will always confirm to ISO 8601 and the user will have less problems with entering the date (some sites require a specific scheme like MM-DD-YYYY which would cause trouble for European users because they’re used to DD-MM-YYYY).

number

The INPUT will only allow numbers. No explanation needed I hope…

range

Ah, one of the new elements in XForms also found its way into WF2. Just like xform:range, the html:input with the value range for type will allow the user to select a value in the range of the numbers specified by the min and max attributes.

email

Once again, I think this input type would cause no problem understanding.

url

Same here…

If you still don’t like the new values for type, you can write your own regular expression that should be used to validate the user input. This regex can be included in the pattern attribute which will be used to validate the user’s input upon submission.

Of course, the additions to WF2 do not limit themselves to input types. Take the required attribute for example. If there is a form control forgotten that has the required attribute, the user agent should not submit the data. The same applies to the type and pattern attributes if a value is submitted that does not meet its field type.

Another new element we see in WF2 is the DATALIST element. This element allows the author to specify a list of default values for, for instance, a text field which will have a somewhat similar effect as your browser’s address bar. Once you click on the arrow at the right of it, a list of IRIs which you previously visited appear. You can think of the DATALIST element to contain such a list of options which can be selected by the user in the INPUT is he wishes to do so.

And I could go on and on and on about all the new features in both specifications. I didn’t even talk about Web Forms 2.0’s repetition model, XForms’s Repeat Module and the new events! However, doing all this research on these two forms did made me understand the two a lot more. Not only did I learn about the new stuff they bring, but also that it’s not 100% fair to compare the two with each other. First of all, the Web Forms 2.0 is still a Working Draft while XForms 1.0 is already a W3C Recommendation since October 2003. The WF2 specification also says that Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on HTML Web browsers that do not support XForms. Therefore we can’t really talk about two competing standards.

However, I think it’s clear that both are at least much, much better than the forms we have now. XForms of course being the more powerful of the two. Its power is incredible thanks to the powerful XML functions that allow the use of multiple namespaces in the same document. However, due to the lack of native support for XForms (only Firefox 1.5+) and XML in general (Internet Explorer), it’s going to take a long time until we can use this awesome namespace.

And that’s the sole reason why WF2 was born: because we have to wait for such a damn long time. Thanks to WF2’s backwards compatibility, we can use most of XForms’ features without discriminating legacy browsers like Internet Explorer because WF2 support is not needed to complete the form. The only advantage that WF2 adds is the fact that forms become a lot more usable for the user when the user’s browser supports WF2. Hopefully modern browsers like Firefox, Opera and Safari can use WF2 to win more users.

However, in the long run, I don’t see WF2 surviving. I still think XForms is a lot better, and once it gets proper support, I’m sure we can say goodbye to WF2. Now don’t get me wrong on this. I still think that WF2 is a great extension to current web forms until the browsers ship with native XForms support and I can’t wait for Firefox to support it.

• 1 Comment

As we all know, the table element shouldn’t be used for styling your document. The div element should be used instead, together with the id and class attribute to style it with CSS, just like the HTML 4.01 and XHTML 1.0 specs tells us to do. But aren’t we polluting our markup with these div elements, because we’re only using them for presentational purposes?

First, let’s take a look at an example. Here’s the HTML code of the top of previous layout:

<div id="logo">
 <h1>Programimi.com</h1>
 <hr>
</div>

As you see, I wrapped the site name and a hr element inside a div element. But the div element has absolutely no purpose in my document instead of having the id attribute and using CSS to style it. So by using divs, you don’t separate presentation from structure at all, nor does it have any semantic value, just like the font and center elements.

One might argue that the div element can be used to divide the document into sections. If this were true, the div would have a real purpose. Unfortunately, it isn’t. Just take a look at what the HTML 4.01 specification says about the element:

The div and span elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (span) or block-level (div) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute,etc., to tailor HTML to their own needs and tastes.

Ok, the spec does talk about adding structure, but that’s actually quite vague, don’t you think? What kind of structure do they mean!? Because the W3C didn’t give any real information on how the div element can give structure to a document that can also be understood by user agents, “adding structure” is actually not possible because no-one understands how it is structurized. The only possible way to do so is by using the id attrubute, but the value of this attribute can only be understood by humans, not user agents. Therefore, it’s still impossible to give structure to a document by using the div element so the only reason to use the element is to group certain elements together in order to style them (or give it a lang like the quoted piece from the HTML 4.01 spec says, but who uses the attribute anyway!?).

So should we just ditch the div element? I guess not. You should, but it would be impossible to make a decent layout at the moment. Which I, as a web designer, enjoy looking at. Another reason would be because we don’t have any alternatives. Well, not yet. Just take a look at the header element, introduced by HTML, or XHTML 2’s role attribute. By using either one of the methods instead of the div element from my previous example at the beginning of this article, that section will actually have a meaning. In other words, the document will become semantically richer.

• 0 Comments