Low-Fi Usability Testing

Pop quiz, hotshot. How do you know if your application works? Sure, maybe your app compiles. Maybe it passes all the unit tests. Maybe it ran the QA gauntlet successfully. Maybe it was successfully deployed to the production server, or packaged into an installer. Maybe your beta testers even signed off on it.

But that doesn't mean it works.

Can users actually understand your application? Can they get their work done in your application? That's what defines a working application. All the other stuff I listed is just noise. You don't know if your application truly works until you've performed usability tests on it with actual users.

And you regularly do usability testing on your application, right?

That's what I thought. One of the central concepts in Steve Krug's book Don't Make Me Think is that usability testing is essential to any software project. Krug calls his simplified approach to usability testing lost our lease, going-out-of-business-sale usability testing:

Usability testing has been around for a long time, and the basic idea is pretty simple: 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 run into trouble. Then fix it, and test it again.

In the beginning, though, usability testing was a very expensive proposition. You had to have a usability lab with an observation room behind a one-way mirror, and at least two video cameras so you could record the users' reactions and the thing they were using. You had to recruit a lot of people so you could get results that were statistically significant. It was Science. It cost $20,000 to $50,000 a shot. It didn't happen very often.

But in 1989 Jakob Nielsen wrote a paper titled "Usability Engineering at a Discount" and pointed out that it didn't have to be that way. You didn't need a usability lab, and you could achieve the same results with a lot fewer users. The idea of discount usability testing was a huge step forward. The only problem is that a decade later most people still perceive testing as a big deal, hiring someone to conduct a test still costs $5,000 to $15,000, and as a result it doesn't happen nearly often enough.

What I'm going to commend to you in this chapter is something even more drastic: Lost our lease, going-out-of-business-sale usability testing. I'm going to try to explain how to do your own testing when you have no money and no time. 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.

Krug points out that usability testing is only as difficult as you make it. It's possible to get useful results from a usability test with a single user, even:

[Usability] testing always works, and even the worst test with the wrong user will show you things you can do to improve your site. I make a point of always doing a live user test at my workshops so that people can see it's very easy to do and it always produces an abundance of valuable insights. I ask for a volunteer and have him try to perform a task on a site belonging to one of the other attendees. These tests last less than ten minutes, but the person whose site is being tested usually scribbles several pages of notes. And they always ask if they can have the recording of the test to show their team back home. Once person told me that after his team saw the recording, they made one change to their site which they later calculated had resulted in $100,000 in savings.

For more proof that you don't need a lot of users to have an effective usability test, Jakob Neilsen offers the following graph:

Obviously, not doing any usability testing at all is a disaster. But what's not so obvious is that usability testing with just a few users is remarkably effective. And it can be relatively painless if you follow Krug's broad guidelines for low-fidelity usability testing:

• When should I test? Ideally, once per month. You should be running small usability tests continuously throughout the development process. The tests should be short and simple, so you can conduct them almost any time with little advance planning.
• How many users do I need? Three or four max.
• What kind of users? Grab some people. Anyone who can use a computer will do. The best-kept secret of usability testing is that it doesn't much matter who you test. It's a good idea to get representative users, but it's much more important to test early and often. Don't be embarrassed to ask friends and neighbors.
• How much time will it take? 45 minutes to an hour per user. Keep it simple. Keep it small. Although it does take extra time to conduct usability tests, even simple ones, ultimately you will save time. The results of the usability tests will prevent you from wasting time arguing endlessly, or redoing things at the end of a project.
• Where do I conduct the test? Any office or conference room. All you need is a room with a desk, a computer, and two chairs where you won't be interrupted.
• Who should do the testing? Any reasonably patient human being. Choose someone who tends to be patient, calm, emphathetic, and a good listener. With a little practice, most people can get quite good at it.
• What equipment do I need? All you need is some form of screen recording software, such as Camtasia. If you want to get really fancy you can bring in a camcorder to record the person and the screen.
• How do I prepare for the tests? Decide what you want to show. Have a short script (doc) ready to guide the participants through the test.
• How much will it cost? Minus the moderator's time, a $50-$100 stipend per user.
• How do we interpret the results? Debrief the development team and any interested stakeholders over lunch the same day. One of the nicest things about usability testing is that the results tend to be obvious to everyone who's watching. The serious problems are hard to miss.

If you don't already own a copy of Don't Make Me Think, shame on you. In the meantime, I highly recommend downloading Chapter 9 of Steve Krug's Don't Make Me Think (pdf), which has much more detail than the summary I've presented.

Usability testing doesn't have to be complicated. If you really want to know if what you're building works, ask someone to use it while you watch. If nothing else, grab Joe from accounting, Sue from marketing, grab anyone nearby who isn't directly involved with the project, and have them try it. Don't tell them what to do. Give them a task, and remind them to think out loud while they do it. Then quietly sit back and watch what happens. I can tell you from personal experience that the results are often eye-opening.

The benefits of usability testing are clear. You just have to do it to realize any of those benefits.

Stylesheets for Print and Handheld

A commenter recently noted that it was difficult to print the Programmer's Bill of Rights post. And he's right. It's high time I set up a print stylesheet for this website. I added the following link tag to the page header:

<link rel="stylesheet" href="/blog/styles-site-print.css"
 type="text/css" media="print" />

The printer-specific CSS is very simple. On a modern site using <div> based layout, optimizing for printers is easy.

1. Hide named <div>s on the page that aren't relevant to printouts.

   #links {
   display: none;
   }
   
   #searchbox {
   display: none;
   }
   
   #newcomment {
   display: none;
   }
   

2. Adjust a few margins and widths, and set a default font.

   body {
   margin: 0; padding: 0;
   font-family:calibri, tahoma, arial, sans-serif;
   }
   
   #content {
   width: 100%;
   margin: 0; padding: 0;
   }
   
   #container {
   width: 100%;
   position:relative;
   margin: 0; padding: 0;
   }
   
   .blog {
   padding: 0;
   }
   

The entire printer-friendly CSS file is a mere 35 lines including generous whitespace. Testing the print stylesheet is a piece of cake, too. Just use the File, Print Preview menu:

Looks good to me.

Once you've set up a print stylesheet, you might as well set up a mobile stylesheet, too, because they're almost identical. We just add another link tag to the page header:

<link rel="stylesheet" href="/blog/styles-site-mobile.css"
 type="text/css" media="handheld" />

The CSS is a subset of the printer CSS, so I won't reprint it here. I only hide the links <div>. Testing rendering on a mobile device is a bit more difficult, but it is possible. Here's what it looks like on the new Samsung Blackjack phones we received at work:

If you're wondering what your website looks like on a mobile device, wonder no longer. Try it yourself and see. The Windows SmartPhone / PocketPC emulator was surprisingly easy to get up and running. Here's what you'll need:

• A clean Windows XP SP2 virtual machine
• The latest version of ActiveSync.
• Standalone Device Emulator with Windows Mobile OS Images (download both items listed here)
• Virtual Machine Network Driver for Microsoft Device Emulator

Once you've downloaded it all, install it in this order:

1. Install ActiveSync
2. Unzip and install V1Emulator (standalone_emulator_V1.exe)
3. Install the Virtual Network Driver (netsvwrap.msi)
4. Install the Emulator Images for Windows Mobile 5.0 (efp.msi)

I chose to launch the "Smartphone QVGA - Coldboot" emulator. Once it's running, the only tricky part is enabling internet connectivity. This post describes how to enable internet connectivity in the emulator; you place the emulated smartphone in the virtual "cradle" so it can access the network through ActiveSync. Note that you'll also need to set "Allow connections to one of the following" to "DMA" in the File, Connection Settings menu of ActiveSync.

Setting up proper print and handheld stylesheets was fun. And easy. I truly regret not doing it sooner. Don't make the same mistake I did. If you don't have print and handheld stylesheets set up on your website, what are you waiting for?

How To Become a Better Programmer by Not Programming

Last year in Programmers as Human Beings, I mentioned that I was reading Programmers At Work. It's a great collection of interviews with famous programmers circa 1986. All the interviews are worth reading, but the interview with Bill Gates has one particular answer that cuts to the bone:

Does accumulating experience through the years necessarily make programming easier?

Bill Gates: No. I think after the first three or four years, it's pretty cast in concrete whether you're a good programmer or not. After a few more years, you may know more about managing large projects and personalities, but after three or four years, it's clear what you're going to be. There's no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight. I can talk to somebody about a program that he's written and know right away whether he's really a good programmer.

We already know there's a vast divide between those who can program and those who cannot.

But the dirty little secret of the software development industry is that this is also true even for people who can program: there's a vast divide between good developers and mediocre developers. A mediocre developer can program his or her heart out for four years, but that won't magically transform them into a good developer. And the good developers always seem to have a natural knack for the stuff from the very beginning.

I agree with Bill. From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't. No amount of putting your nose to the grindstone will change that. But if you accept that premise, it also presents us with a paradox: if experience doesn't make you a better programmer, what does? Are our skill levels written in stone? Is it impossible to become a better programmer?

To answer that question, you have to consider the obsessive nature of programming itself. Good developers are good at programming. Really good at programming. You might even say fanatically good. If they're anything like me, they've spent nearly every waking moment in front of a computer for most of their lives. And naturally, they get better at it over time. Competent software developers have already mastered the skill of programming, which puts them in a very select club. But if you're already in the 97th percentile for programming aptitude, what difference does a few more percentile points really make in the big scheme of things?

The older I get, the more I believe that the only way to become a better programmer is by not programming. You have to come up for air, put down the compiler for a moment, and take stock of what you're really doing. Code is important, but it's a small part of the overall process.

This piece in Design Observer offers a nice bit of related advice:

Over the years, I came to realize that my best work has always involved subjects that interested me, or -- even better -- subjects about which I've become interested, and even passionate about, through the very process of doing design work. I believe I'm still passionate about graphic design. But the great thing about graphic design is that it is almost always about something else. Corporate law. Professional football. Art. Politics. Robert Wilson. And if I can't get excited about whatever that something else is, I really have trouble doing a good work as a designer. To me, the conclusion is inexcapable: the more things you're interested in, the better your work will be.

Passion for coding is a wonderful thing. But it's all too easy to mindlessly, reflexively entrench yourself deeper and deeper into a skill that you've already proven yourself more than capable at many times over. To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.

Bill Gates, in a 2005 interview, follows up in spirit to his 1986 remarks:

The nature of these jobs is not just closing your door and doing coding, and it's easy to get that fact out. The greatest missing skill is somebody who's both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that. And so that sort of engineering management career track, even amongst all the people we have, we still fall short of finding people who want to do that, and so we often have to push people into it.

I'd love to have people who come to these jobs wanting to think of it as an exercise in people management and people dynamics, as well as the basic engineering skills. That would be absolutely amazing.

And we can promise those people within two years of starting that career most of what they're doing won't be coding, because there are many career paths, say, within that Microsoft Office group where you're part of creating this amazing product, you get to see how people use it, you get to then spend two years, build another version, and really change the productivity in this very deep way, take some big bets on what you're doing and do some things that are just responsive to what that customer wants.

You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business.

The more things you are interested in, the better your work will be.

Extending The Windows Vista Grace Period to 120 Days

If you're on the fence about the impending release of Windows Vista, I recommend trying before you buy. Every Vista DVD includes the ability to install any edition of Vista without a product key. When you install without a product key, you get an automatic 30 day evaluation period.* This probably isn't news to anyone.

What may be news to you, however, is that you can easily extend the 30-day Windows Vista grace period to 120 days. No hacks required. This is an official, supported operation directly from Microsoft.

To extend the grace period another 30 days, simply start a command prompt as Administrator, and issue this command:

slmgr -rearm

Reboot for the change to take effect, and voila, you have 30 more days. You can only extend three times, so the total grace period for a Vista evaluation is 120 days. You do, however, need to be careful that you've installed the correct edition of Vista. At the end of that 120 day grace period, you'll have to pony up a license fee for the edition of Vista you've installed. Now that the OEM editions are out, the pricing breaks down like so, at least at Newegg:

• Vista Home Basic OEM - $100
• Vista Home Premium OEM - $120
• Vista Business OEM - $150
• Vista Ultimate OEM - $200

Microsoft is semi-officially supporting the OEM versions for resale to end users, but the bad news is that there's not much savings at the low-end. The pricing for the basic OEM editions are nearly identical to the full retail upgrades. The primary difference is that the OEM copies will support full install as well as upgrade install. If you're looking for deeper Vista discounts, you may be interested in the Vista Family Pack, which includes the option to buy two $49 copies of Vista Home Premium, provided you pay full retail price for a copy of Vista Ultimate.

Now that we've gotten the sticky matter of pricing out of the way, let's take a deeper look at this little utility Microsoft provides. It's actually a Windows Script Host file, slmgr.vbs. First, let's switch our default WSH handler to the command-line version so we aren't dealing with aggravating window popups from the command line.

cscript /H:Cscript

If you run slmgr without any parameters, you'll get the help.

Windows Software Licensing Management Tool
Usage: slmgr.vbs [MachineName [User Password]] [<Option>]
           MachineName: Name of remote machine
           User:        Account with required privilege
           Password:    password for account

Global Options:
-ipk <Product Key>
    Install product key (replaces existing key)
-upk
    Uninstall product key
-ato
    Activate Windows
-dli [Activation ID | All]
    Display license information (default: current license)
-dlv [Activation ID | All]
    Display detailed license information (default: current license)
-xpr
    Expiration date for current license state

Advanced Options:
-cpky
    Clear product key from the registry (prevents disclosure attacks)
-ilc <License file>
    Install license
-rilc
    Re-install system license files
-rearm
    Reset the licensing status of the machine
-dti
    Display Installation ID for offline activation
-atp <Confirmation ID>
    Activate product with user-provided Confirmation ID

I just re-armed tonight and re-booted, and I can verify that the grace period extension worked via the -dli command:

C:\Users\Jeff>slmgr -dli

Name: Windows(TM) Vista, Ultimate edition
Description: Windows Operating System - Vista, RETAIL channel
Partial Product Key: RP8F7
License Status: Initial grace period
Time remaining: 43100 minute(s) (29 day(s))

This is my third and final grace period extension. I now have 29 days to decide if I want Ultimate edition or not.

(update: Ed Bott posted how to set up a scheduled task so you rearm automatically after 30 days. I set mine up to run monthly for 3 months rather than setting up 3 individual tasks as Ed suggests.)

* Note that this does not apply to the Enterprise edition of Vista, which only allows a 3 day grace period. The enterprise edition has an entirely different activation scheme; it uses a local volume license key server.

Dynamic, Lightweight Visualization

Edward Tufte's print world is filled with stunningly beautiful visualizations. Even seemingly mundane things like visualizations of Ruby, Java, and JavaScript grammars can be beautiful. But they're static. They don't move. They're not interactive.

That's where Ben comes in.

If you haven't visited Ben Fry's website before, I envy the experience you're about to have. (Be sure to visit his old MIT site, too.) Ben Fry is Edward Tufte armed with a compiler. Ben produces incredible dynamic visualizations with his custom Java-based, open-source processing language. It even comes with its own custom IDE:

We think most "integrated development environments" (Microsoft Visual Studio, Codewarrior, Eclipse, etc.) tend to be overkill for the type of audience we're targeting with Processing. For this reason, we've introduced the 'sketchbook' which is a more lightweight way to organize projects. As trained designers, we'd like the process of coding to be a lot more like sketching. The sketchbook setup, and the idea of just sitting down and writing code (without having to write two pages to set up a graphics context, thread, etc) is a small step towards that goal.

The idea of just writing a short piece of code that runs very easily (via a little run button) is a direct descendant of John Maeda's work in Design By Numbers, and our experiences maintaining it. (Yes, other languages and environments have done this first, but in our case, the concept is drawn from DBN).

It's amazing stuff, more akin to sketching than coding.

Once you have the Java dependency and Processing installed, be sure to browse through the examples gallery to see what's possible.

Ben's latest Processing visualizations, baseball salary vs. performance, and isometric blocks, are like pages from an Edward Tufte book come to life. And who can forget his classic zipdecode?

If you've gone this far with Java-based visualization, you might as well continue on to IBM's Many Eyes site. You can't write your own visualization code here; you're stuck with the predefined visualizations they provide. You can, however, upload and share the data sets you're using to visualize from.

But you might wonder, what's with all the Java? Couldn't we do this dynamic visualization stuff with something more lightweight, something more appropriate for a web page?

• JavaScript is a possibility. After all, we had Wolfenstein 5k, a JavaScript clone of Wolfenstein 3D written in only 5 kilobytes of JavaScript, way back in 2002. Sadly, it doesn't work in any modern browser, or even in any Microsoft OS newer than Windows XP Service Pack 2. But it's an impressive piece of work nonetheless. It foreshadowed just how reliant the web would become on JavaScript. One such JavaScript visualization, Kyle Scholz's music recommendation connected graph, is ponderously slow. It leaves me wondering if JavaScript is really up to the task of visualization, even with the HTML Canvas element.

• What about Flash? Surely visualization is a better use for Flash than the legions of advertisements (and, now, video advertisements) I'm subjected to every day. Although I can find some isolated visualizations in Flash, I'm not seeing a vibrant visualization community there.

• On the Windows side, there's some hope for Windows Presentation Foundation, which ships in every Vista box. WPF, and its lightweight cousin WPF/E, could enable lightweight, hardware accelerated visualization-- something that's sorely lacking from all the other options. To see what I mean, try this WPF 3D sample, which runs entirely in the browser. But the technology is far too new to have any kind of community.

If I wanted to see static illustrations, I'd read a book. But dynamic visualizations aren't quite there yet for web pages. Right now, you have to pick your technology poison. They all have their downsides. Still, it's something worth striving for. I yearn for the day when web pages are regularly illustrated with the kind of beautiful, dynamic visualizations that Ben Fry creates.

Would you rather be a Navigator or an Explorer?

There's an interesting comment in this Amazon user review of The Microsoft Manual of Style for Technical Publications:

My favorite entry, especially fun to find in light of Microsoft's legal problems arising in part from its relationship to Netscape Navigator, is this Orwellian directive, found on p. 185: "Navigate. Avoid the verb 'navigate' to refer to moving from site to site, page to page within a site, or link to link on the Internet. [...] Instead, use 'explore' to mean looking for sites or pages generally..."

Would you rather be a Navigator or an Explorer? And what, exactly, is the implied meaning of this IE error:

The wording of the "Navigation Canceled" error message can't possibly have been a coincidence, given the intense rivalry with Netscape Navigator back in the heady days of Internet Explorer 3 and 4. The message now seems quaint in the wake of Netscape's near-irrelevance. Still, I wonder which cheeky little monkey at Microsoft came up with this particular error message way back when.

Of course, there's a long history of semi-friendly rivalry between Internet Explorer and its browser competition. In 1997, immediately after the release of Internet Explorer 4, Microsoft dropped a giant IE logo on the Netscape campus.

And more recently, the Internet Explorer team sent the Firefox team a cake to congratulate them on the release of Firefox 2.0.

If It Isn't Documented, It Doesn't Exist

Nicholas Zakas enumerates the number one reason why good JavaScript libraries fail:

Lack of documentation. No matter how wonderful your library is and how intelligent its design, if you're the only one who understands it, it doesn't do any good. Documentation means not just autogenerated API references, but also annotated examples and in-depth tutorials. You need all three to make sure your library can be easily adopted.

James Bennett expresses a similar sentiment in choosing a JavaScript library:

There's one other thing which can really make or break a JavaScript library, and it's surprising how often it's overlooked, because the same thing makes or breaks an awful lot of software in other fields: documentation. The greatest library in the world would fail if the only way to learn it was reading the code (and, in fact, it already has to a large extent). Some packages have managed to overcome this by way of lots of unofficial documentation -- blog entries and the like -- but there is absolutely no substitute for full, well-written documentation. The ideal, for me, consists of:

1. High-level overviews of each part of the library, touching on key objects and methods.
2. Practical examples showing how to handle common use cases.
3. Full API documentation for everything in the library. JSDoc is both good and bad for this: good because it makes API docs stupidly easy to generate, and bad because people assume that API docs are all you need. Javadoc, which inspired JSDoc, has wrought much ill on the Java world for largely the same reasons.
4. Comments throughout the code itself.

Pretty much everybody who's developing a JavaScript library has dropped the ball on this; very few libraries manage even one or two of those points, and out of the teeming multitude of JavaScript libraries floating around today I've seen exactly one which manages to hit all four points with any kind of success. Maybe there are other splendidly-documented libraries out there, but I've yet to see them; most treat documentation like an afterthought.

Mike Pope, who writes documentation for a living, neatly summarizes both opinions with this zinger:

We've been known to tell a developer "If it isn't documented, it doesn't exist." Not only does it have to be doc'd, but it was to be explained and taught and demonstrated. Do that, and people will be excited -- not about your documentation, but about your product.

Good documentation is hard to find. Particularly on open source projects. That's why I was so pleasantly surprised to see such excellent documentation for the open-source UrlRewriting.net project, along with a support forum.

The UrlRewriting documentation (pdf) is a pleasure to read. Far from being an afterthought, documentation was a first-class citizen on this project, and it shows. The presence of good documentation makes the code a pleasure to use, too.

So how do you keep your documentation up to snuff on a rapidly moving project? Maybe it's possible to use agile documentation methods alongside agile coding practices. Mike Pope's recent post on the "agile little" ASP.NET AJAX documentation set is a hopeful sign that we, too, can generate better documentation, faster.

Shipping Isn't Enough

Part of Chuck Jazdzewski's fatherly advice to new programmers is this nugget:

Programming is fun. It is the joy of discovery. It is the joy of creation. It is the joy of accomplishment. It is the joy of learning. It is fun to see your handiwork displaying on the screen. It is fun to have your co-workers marvel at your code. It is fun to have people use your work. It is fun have your product lauded in public, used by neighbors, and discussed in the press. Programming should be fun and if it isn't, figure out what is making it not fun and fix it. However, shipping isn't fun. I often have said that shipping a product feels good, like when someone stops hitting you. Your job is completing the product, fixing the bugs, and shipping. If bugs need fixing, fix them. If documentation needs writing, write it. If code needs testing, test it. All of this is part of shipping. You don't get paid to program, you get paid to ship. Be good at your job.

It's true. One key measure of success for any programmer is how much code you've shipped. But merely shipping is not enough. A more meaningful measure of success is to ask yourself how much code you've shipped to living, breathing, real-world users. But then total users doesn't equal total usage, either.

How many users actually use your application? Now that's the ultimate metric of success.

But it's a little scary when you start doing the math. Rich Skrenta explains:

I was just an engineer in this group, but the reality of what was happening in the market to our product line started to seep in. Here I was putting all of this effort into stuff that never would be used by anyone. It was still intellectually challenging...like doing crossword puzzles or something. But it had no utility to the world.

I started to look around and I saw many other examples of groups working on stuff that no one would ever use or care about. Mobile IP initiatives, endless work around standards that nobody cared about, research from the labs that would never be applied or even cited.

Yikes.

I had written stuff that people actually used, before. It felt good. I had written a usenet newsreader that was used by hundreds of thousands of people. I was running an online game, as a commercial hobby on the side, which had several hundred paying customers. Sheesh, I thought. My side projects have more customers than my day job.

So I made a simple resolution. I wanted to work on stuff that people would actually use.

This sounds simple. But if you walk the halls of Sun, AOL, HP, IBM, AOL, Cisco, Siebel, Oracle, any university, many startups, and even Google and Yahoo, you'll find people working on stuff that isn't going to ship. Or that if it does ship, it won't be noticed, or won't move the needle. That's tragic. It's like writing a blog that nobody reads. People make fun of bloggers who are writing "only for their mother". But what about the legion of programmers writing code paths that will never be traversed?

It's for precisely this reason that I've often wondered if writing code is really the most effective way for software developers to spend their time. A software developer that doesn't write code-- sacrilege, right?

But wait a minute. A smart software developer knows that there's no point in writing code if it's code that nobody will see, code that nobody will use, code that nobody will ultimately benefit from. Why build a permanently vacant house?

A smart software developer realizes that their job is far more than writing code and shipping it; their job is to build software that people will actually want to use. That encompasses coding, sure, but it also includes a whole host of holistic, non-coding activities that are critical to the overall success of the software. Things like documentation, interaction design, cultivating user community, all the way up to the product vision itself. If you get that stuff wrong, it won't matter what kind of code you've written.

If, like Rich Skrenta, you want to work on software that people want to use, realize that it's part of your job to make that software worth using.

Identicons for .NET

Don Park invented Identicons last week.

An Identicon is a small, anonymized visual glyph that represents your IP address. Don explains it better than I do:

I originally came up with this idea to be used as an easy means of visually distinguishing multiple units of information, anything that can be reduced to bits. It's not just IPs but also people, places, and things.

IMHO, too much of the web what we read are textual or numeric information which are not easy to distinguish at a glance when they are jumbled up together. So I think adding visual identifiers will make the user experience much more enjoyable.

I think identicons have many use cases. One use is embedding them in wiki pages to identify authors. Another is using them in CRM to identify customers. I can go on and on. It's not just about IP addresses but information that tends to move in 'herds'.

It's genius. And the simple algorithm Don came up with produces beautiful, unique results. Just scroll through the comments on his blog to see Identicons in action. They work amazingly well, even at 16x16. Jon Galloway and I were inspired. We rolled up our sleeves and ported Don's Identicon code from Java to .NET 2.0.

Download the Identicon 1.3 sample for .NET 2.0 (13 kb)

Identicons aren't just for show. They're quite practical. Rather than printing everyone's IP address next to their comment, you can show their anonymized Identicon. It's more private, it's almost as useful, and it's much more fun. Download the sample and try it yourself.

(updated 3/18/2007 V1.3: fix a few minor bugs, improve documentation)

A World of Endless Advertisements

While reading Larry O'Brien's latest column in SD Times, I couldn't help noticing that the article text was dwarfed by the advertisements.

I was curious exactly how much of the page was dedicated to advertising. There's a clever technique used in the book Homepage Usability: 50 Websites Deconstructed to measure the composition of webpages.

The fifty corporate homepages used in the book didn't contain much advertising, but I was still amazed how little screen real estate is dedicated to actual content. Let's apply the same technique to the SD Times page. I'll highlight navigation, content, and advertising.

A full third of the page is dedicated to advertising. That's more than the content itself!

I carried a torch for micropayments for years, but it's never going to happen. Ad-supported content appears to be the only sustainible business model on the internet. Clay Shirky has been saying this for years. Just open a web browser and it's painfully obvious that he was right. The web is awash in advertising.

This model, which generates income by making content widely available over open networks without charging user fees, is usually called 'ad-supported content', and it is currently very much in disfavor on the Internet. I believe however, that not only can ad-supported content work on the Internet, I believe it can't not work. Its success is guaranteed by the net's very makeup - the net is simply too good at gathering communities of interest, too good at freely distributing content, and too lousy at keeping anything locked inside subscription networks, for it to fail. Like TV, the net is better at getting people to pay attention than anything else.

Indeed, ad-supported content is the house that AdWords built. It's difficult to criticize a system that works, a system that allows content creators to at least break even on their hosting costs.

We watched the movie Idiocracy this weekend. It's a brilliant bit of social satire from Mike Judge, which (among other things) takes ad-subsidized content to its logical extremes. People wear nothing but clothes plastered with corporate logos. Wallpaper and lampshades are made up of patterns of tiny corporate logos. Every square inch of every imaginable surface is covered with billboards and even more advertisements.

Watching television in Idiocracy bears an unfortunate resemblance to reading that SD Times article. To be fair, Larry's content is a bit more highbrow than "Ow! My Balls!". But it's still a tiny window of content, surrounded by dozens of flashing, animated advertisements. It's a disturbing vision of the future. It's supposed to be funny, but it's uncomfortably close to the experience of reading today's ad-supported internet content. Are we creating a world of endless advertising?