Core Dump

Nancy and I are looking for a new fridge; the one we have is fourteen years old and suffering from a number of probably terminal maladies. So we went over to Home Depot last night and spent an hour or so browsing through their selection of fridges and found one we liked, an LG bottom freezer model.

When we came home, I thought I'd do some comparison shopping online. I found the fridge for $200 less at Future Shop, but it looks like an online offer only, and I'm not sure I want to buy a fridge online. So I started browsing some of the other appliance and hardware store sites and found that some retailers just have got the Internet yet.

Lowes doesn't seem to sell anything, at least that's the impression I get from their web site. No product catalog, no prices, and the weekly specials page is blank. The Brick has a good selection but their site is poorly organized - you can't find out the brand or model number until you start drilling down into each item. Leon's is better organized, although I couldn't find prices at first, until I realized I had to enter my postal code. Bad Boy makes you drill down into the product page to get a price too, which is annoying if you are looking at a lot of models.

It seems that the hardware stores have a ways to go to compete online with the electronics superstores, both in ease of use of their web sites, and on price (at least in the case of Future Shop, which has the lowest price we've found so far).

Labels: technology, usability

Embedded user assistance or embedded help is the technique of building your help right into the application. It's probably the best way of handling help, but it's not often done because it requires extra effort on the part of both the writer and developers. TC World has a good article about how embedded help can improve usability in your applications.

Why is embedded help an excellent way to increase the usability of your software application?

Because embedded user assistance is task-specific, context-specific, and does not require users to search for it or ask the right question to find the answer. Unlike traditional online help, users continue their workflow and do not have to split their focus between two different windows. Best of all, users don’t see embedded help as help.

According to Wilbert Galitz in The Essential Guide to User Interface Design, a typical user interaction with documentation involves three steps: “(Users) need to find it, understand it, and apply that understanding to solve the task at hand.”

Online help is passive, with the user taking the initiative. Embedded help is non-intrusive and does not require the user to take the initiative, says Lynne Hall in the International Encyclopedia of Ergonomics and Human Factors.

Embedded help also encourages learning. According to Mike Hughes in the Cutter IT Journal, “users shift from a learning/exploration mode to a task execution mode … they stop exploring and experimenting.” Embedded help can delay that shift.

Labels: technical communication, usability

Here's an interesting story about redesigning a newspaper using modern, web-based design principles. The designers didn't get the commission, but they did come up with some interesting ideas that sound quite workable, to me anyway.

Basic rule: Ignore all rules of newspaper design to start with and keep only the ones that are useful to the reader:

1. Optimize text for reading: Big leading, big body text. We did several reading tests and found this combination to work best for reading. We perfectly knew that this leading doesn’t look very newspaper like (see Basic Rule).
2. Reduction to two fonts: Frutiger Next and the new, amazing Frutiger Serif, a heavenly fit, honoring the great Adrian Frutiger for his life work.
3. Scannability and print link: Make the articles scannable by using key words in blue. If you speak German you can actually read the front page in 20 seconds by flying over the blue key words. It gets better: If you type any of those key words on the website search, you will get a list of articles with the respective keyword in a chronological order. That way you avoid the necessity to print http;//www.abc.com/abc style links in print. Links in print obviously doesn’t mean that you can click it, it means linking the paper to the online edition.
4. Order: Every page is structured from top left to bottom right. Important articles are top left, unimportant ones are bottom right.
5. Four columns for soft news, five columns for hard news, mixed 4/5 columns for sports. Ragged text for opinion.
6. Big pictures, big info graphics, use the strength of the paper medium

Labels: technical communication, usability

Color Scheme Designer is a web-based application that will help you pick a pleasing color scheme from a color or small set of colors. It's easy to use and has some sophisticated features. According to LifeHacker:

You can generate single monochromatic, complimentary, triad, tetrad, analogic, and accented analogic color palettes. You can simulate color-based vision disorders to see how your design colors will look—they even list the percentage of people suffering from the disorders. A preview function populates a dummy web page with your color scheme, which is a handy tool for seeing how your selected colors look together off the palette.

While the page-simulator is a really great trick, the best feature of Color Scheme Designer is the ability to export your palette not just as a Photoshop palette—a common limitation of many web-based generators—but as HTML+CSS, XML, TXT, and GPL (the palette format for GIMP).

Labels: software, usability

Here's a very funny lexical analysis of a car manual - just what is the writer of the manual really telling us and what can we learn from his or her word choices?

The Knee Impact Bolsters help protect the knees and position you for the
best interaction with the airbag.

You don't know it, but all the time you're sitting there staring into space
you're being positioned for an "interaction" with the airbag. In
anticipation of this explosive event, the Knee Impact Bolster performs a
kind of foreplay on you, whispering intimately, "Move your leg a little
bit. No, higher. There. That's better."

The manual goes on about airbags, rightly sensing that their recent mention
in the news calls for reassurance. Airbags can abrade you when they
inflate, and the language on this subject hits just the right tone:

The abrasions are similar to friction rope burns or those you might get
sliding along a carpet or gymnasium floor.

The chumminess disarms us, taking us right back to our school days. It
seems to say, "Remember the time big-mouth Sally dared you to slide down
the rope in the gym and you were still mad about what she told Judy at the
party so you slid down fast just to show her? Remember the rope burn you
got? That's what an airbag abrasion feels like."

Labels: language, technical communication, usability

Here's a compreshensive list of user interface style guides, including guides from Apple, Microsoft, and Sun, as well as guides for various operating systems and classes of devices (such as mobile phones).

Labels: language, technical communication, usability

Tom Johnson looks at the help for Google's new Google Voice service and finds that it could be better.

Google puts a lot of effort in the overview video. That’s a smart move. When people want to learn about Google Voice, the overview video communicates the service in a catchy way, with more of Google’s branding. This video is probably watched thousands of times (a lot more than any other video), so it makes sense to go to the effort of including animation.

What I don’t like about Google’s help is the lack of integration between the video and help content. Not every topic deserves a video. Many times I’d rather read the help. And sometimes I’d rather watch a video. Separating the two formats so strongly is a poor usability move. The forum and blog also need to be more closely integrated with the other help materials.

Labels: usability, wikis

Mike Hughes of UXMatters has a long article looking at the reasons people usually give for producing PDF manuals and explaining why other online formats are better. I'm one of those people who's still producing PDF versions of some of our manuals, although I do plan on trying to make the online versions the primary documentation, now that we have MadCap Flare.

Let me describe a familiar user assistance experience. A user installs a new application, and when the user wants Help, the application directs her to the user documentation on a Web site or CD-ROM. What the user finds there is a PDF file containing the manual—or a collection of PDF files, representing a library of manuals, including a user guide, configuration guide, troubleshooting guide, and various references. And the layout of each of these PDF manuals is exactly the same as if it were a printed book. This raises an interesting question: If we’re giving manuals to users to read online, why do we design and write them for paper?

I’m not down on every use of PDF files online. Campus maps, article reprints, and my aunt’s Christmas letters all work quite well as PDF files. What I want to challenge in this column is the use of PDF files for distributing user assistance online, in the form of large books.

Labels: technical communication, usability

Here's a list of 25 usability checklists that you can use as guidelines for testing web site usability. (You could certainly adapt them to online help systems, and possibly other documentation, with a bit of tweaking). This is definitely worth bookmarking.

Labels: usability

While at the STC Summit, I attended a seminar put on the the principals of Design to Read, a company dedicated to improving the lives of people who do not read easily. You may want to check out the Resources section of their web site, which isn't large but is high-quality.

Labels: technical communication, usability

Writers often get in to the rut of writing everything the same way, and that isn't necessarily the best way for their users. Tom Johnson, in a long and interesting article, examines ways to make your documents (print or online), more usable. It's well worth reading, more than once.

I’ve written about eight principles of documentation usability. Here they are in review:

* Find out what users want
* Move help into the interface
* Provide one-page quick reference guides
* Remember that most users are visual learners
* Write for frustrated users
* Adjust help based on expanding needs
* Communicate the big picture
* Watch users follow your help

Tape this list next to your monitor as you work on your help material. None of these points of usability is a simple item you can check off, such as ensuring tasks have between 5-10 steps, that you have an index, or that your topic titles are parallel. Instead, implementing some of these usability principles is hard — you have to go out of your way, and you may not like the results.

Labels: technical communication, usability

This article in the CyberText Newsletter provides some good guidelines for providing user assistance in web forms. Writers who have to document web-based applications will find this quite useful. It's a summary of the presentation given by Luke Wroblewski at the recent WritersUA Conference.

Labels: technical communication, usability

When I have trouble documenting a user interface, it's often a sign that the interface is badly designed. Sometimes, if I'm lucky, I can get the developers to fix the problem. And more often not, unfortunately. Very often, the problem is one of those listed in this article. I've found that especially true for web-based applications; many developers have trouble making the transition from Windows application design to web application design.

Labels: technical communication, usability

I've watched my son playing World of Warcraft and wondered how the heck he keeps track of everything that's going on on screen. I've also wondered how I'd document it, if I was tasked with doing the help system. If you want to see what I mean, take a look at this Wired article, which explains what all the various interface elements are for. And there are a lot of them. I've had to document some messy interfaces, but nothing comes close the the complexity of the WoW interface.

Labels: gaming, usability

One of the reasons I used to justify the purchase of my first computer in the 1980s was that it might be a useful tool to help me copy with my increasing nearsightedness. Fortunately, I've never needed the really advanced vision aids that are novw available for the blind or people with serious vision problems. (I fall into that gray area called low vision - not legally blind, but not sighted enough to be able to drive).

One aspect of the computer revolution has caused serious problems for blind computer users, and that's the graphical user interface. Properly designed Windows and Linux progams contain hooks that screen reader programs can use to help blind users navigate through the maze of windows and dialog boxes. But what about portable devices like and iPhone or iPod Touch?

The New York Times has an article about T.V. Raman, a blind Google engineer, whose work to help other blind users is leading to innovative new interfaces that may help both blind and sighted users.

Mr. Raman, 43, is now working to modify the latest technological gadget that he says could make life easier for blind people: a touch-screen phone.

“What Raman does is amazing,” said Paul Schroeder, vice president for programs and policy at the American Foundation for the Blind, which conducts research on technology that can help visually impaired people. “He is a leading thinker on accessibility issues, and his capacity to design and alter technology to meet his needs is unique.”

Some of Mr. Raman’s innovations may help make electronic gadgets and Web services more user-friendly for everyone. Instead of asking how something should work if a person cannot see, he says he prefers to ask, “How should something work when the user is not looking at the screen?”

Such systems could prove useful for drivers or anyone else who could benefit from eyes-free access to a phone. They could also appeal to aging baby boomers with fading vision who wantto keep using technology they’ve come to depend on.

Labels: computing, technology, usability

I don't play computer games as much as I used to, but when I do, or when I watch my kids play, I'm usually impressed by the slickness of the interfaces. Some games have very complex interfaces, but yet they manage to stay out of the way of good gameplay. Designing an interface like that is something of an art, and not many people do it well. One person who does is Colm Nelson, the interaction designer for Halo 3. Boxes and Arrows has a long and quite fascinating interview with him.

Online systems that facilitate player experiences around social interaction, custom content sharing and online communities have received a lot of attention by both the gaming press and fans and is definitely a hot trend in gaming. The gaming press has even begun to draw comparisons with these features to You Tube, My Space and Facebook. My observation is that developers that are offering more features in [the] user experience around the game are seeing more of a need to specialize and fill roles specifically around user experience and interface design.

Games with success in these areas have generally done a good job developing a solid feature set and matching the social goals of gameplay with the accessibility and usability of the features. Ultimately these features add to the longevity of a game’s popularity, which translates directly to sales. I think as a result there are more opportunities for traditional interaction designers in the games business.

Labels: gaming, usability

I used to work in radio while I was in university (both at the student radio station and during the summer holidays in the Soo), so I've got some (dated) familiarity with audio production. I'm amazed at how much easier things have gotten in the intervening years; my home PC is the equivalent of a radio production studio, or would be if I had decent microphones. And now, with the advent of the Internet and podcasting, pretty much anyone can produce the equivalent of a radio program.

But that doesn't mean it'll be good, and very often it's not. Part of the reason for that may be lack of familiarity with the technology and tools, but often it's not understanding that audio is a different medium than print, and works by different rules. If you want to understand some of those rules, then read Information Architecture for Audio: Doing It Right on the Boxes and Arrows site, especially if you're a podcaster or plan to be.

Content today is increasingly delivered by audio both online and in the real world. We have radio shows and newscasts, and in recent years, podcasts, audio books and navigation/car assistance systems have been added to the field. Audio is more emotional, as sound effects and acoustic atmosphere enhance content to help deliver its messages. It also affords users the opportunity to interact with content while their hands and eyes are busy (i.e. when doing physical work, driving, walking, etc).

However, the inclusion of audio often results in usability issues that make it difficult for users to access and understand content. That is why we need new tools to organize linear content like audio. Luckily, a wide range of techniques employed in information architecture, journalism, usability engineering and interface design are available. All that’s required is the knowledge to combine them effectively. This article presents a practical framework for designing and implementing audio-based content, such as podcasts.

Labels: technical communication, usability

Scott Nesbitt recently bought an OLPC for his eight-year-old daughter and she's become quite attached to it.

But just how intuitive is the XO laptop? As I mentioned ealier in this post, I bought this device for my daughter. She’s eight years old and suffers from autism. While she lives in a house with several computers, she hasn’t had much hands-on experience with them. Well, beyond playing with my wife’s laptop and using an old Mac at her former school. But after using the XO for less than 30 minutes — and being mesmerized by it the entire time — my daughter is now able to launch and use a number of activities without any hesitation

He has some interesting comments on usability based on their experience.

The SUGAR interface on the XO laptop was definitely a design risk. But it’s one, I think, that interface designers can learn from. I’m not saying that all applications — regardless of their platform — should ape the SUGAR interface, but they should be willing to take risks. They should be willing to deviate from the status quo. I mean, how many toolbars, icons, and menus do users really need? And how many do they actually use?

Don’t be afraid to design an application not just for your audience, but the way in which your audience will actually use the application. Consider how people are bound to use an application and build from there. One of the reasons that Aaron and I enjoy using applications developed by 37 Signals — applications like Basecamp, Highrise, Writeboard, and Backpack — is that they’re designed with the user in mind. Those applications enable users to perform certain tasks, without a lot of overhead or features that only a fraction of them wil ever use. There is no all-in-one solution.

I'm hoping he'll bring it into work one of these days so I can see it for myself, if he can tear it away from his daughter.


Update: As it turned out, Scott brought his daughter's OLPC in to work today and several of us had a good look at it. The interface takes some getting used to, especially if you've used Windows a lot, but the PC itself is well built and has lots of nice features that I wouldn't expect in a machine of that price. Like all well-designed devices, it appears to be more than the sum of it's parts - it has a certain, undefinable quality that just feels - right. It should be a perfect fit for its intended market, the developing nations of the world.

Update2: Here's another perspective on the OLPC, from someone who didn't have a very good experience with it.

Labels: usability

Usability can be a tricky thing, as this usability analysis of Microsoft's Live.com web site demonstrates. At first glance, the site looks good, with a clean, uncluttered look, but the devil is in the details.

Cobblestone 5. Inconsistent tab order. From the homepage, I selected the “Video” tab and searched for google. The video tab was in third position on the homepage, but now it moved to the right of the “more” dropdown into 7th position. Not only doesn’t this make much sense and is confusing due to a lack of consistency, this approach is also inconsistent in that it’s not repeated when you e.g. choose the “Image” tab (as that tab will not move to the 7th position). The user model doesn’t match the programmer’s software model: the “rule” here seems to be that Video is in Beta and thus somehow must move to the right on search results (and results only), but this rule is too arbitrary to be intuitive. Programmers & designers should always try to match the user model, that “mental understanding of what the program is doing for them,” as Spolsky says.

Readers should note that much of the analysis is applicable to online help, especially web-based help.

Labels: technical communication, usability