I’ve been playing around with the Furl Beta. It’s looking pretty good. Essentially, it’s a personal online cache of web pages that you can view, search, and share. Better than bookmarking because you can search the contents of it later, and it’s accessible from any browser. You can even provide RSS feeds to your Furl content.  Collaborative research on the internet just got a whole lot easier.

One drawback, there does not appear to be any way to make the cache private, so I can’t possibly use it, because there is no way I want a public database of every site I find interesting or useful. I definitely would share some of it with some people, but totally public is not an option.

Perhaps there will be a pay service for a private space.

Update: My bad. Just mark the item private when you Furl it.  Duh.  Didn’t see that on the Furl dialog and still don’t see how to make a public item private (except to change its topic to personal, but then I lose the utility of topics). Anyway, now the biggest drawback is that the first dialog comes up at the wrong size and there is no scrollbar, so you can’t see the buttons.

Any program that accepts user input will need to separate good input from bad, and to make sure little of the latter gets recorded.

So begins the CHECKS Pattern Language of Informational Integrity by Ward Cunningham. I read this article years ago and loved it—mostly because it jibed with my experience for writing usable business software. The theme of the language is to make sure that data entered by the user is correct, and accomplishes this with various kinds of validation and data representation techniques.

I find that two of the patterns are invaluable for usable user interfaces—Echo Back and Visible Implication. The section they appear in starts with:

A person reaches through a program’s interface to manipulate the domain model. Although the interface is itself a program (an interface model and graphical machinery), its purpose is to enable the direct manipulation of the domain model as transparently as possible. The user interface is programmed to create the illusion of control in the mind of the user. To this end it must provide sufficient clues of the model’s state so that sensible operation is the norm.

These ideas are so important to the usability of software and so difficult to implement in HTML based software, because there is little domain knowledge accessible from the client side. For instance, Echo Back requires that a field, once entered, is transformed into a domain object and injected into the model. It is then read back from the model and displayed as understood by the model. Visible Implication further requires that any cascading consequences are also displayed. This kind of interface is the norm in the Fat Client or Client-Server world, and mostly absent in the web-based software world. As a consequence, it is harder for users to enter data.

We’ve all had the experience of filling out a huge form on a web page and submitting it, only to be told that we’ve made a mistake and have to go back. That’s Deferred Validation used in isolation of the other patterns, and was never considered a good UI decision until the web made it commonplace. And yes, I know that you can get part of the way there with javascript, but only simple validations are possible. Imagine correcting a pay date in a maintainable and configurable way as described in the example for Echo Back.

I appreciate the revolution that the web has brought us, but something better is needed for software with high usability or productivity requirements (as opposed to high learnability or deployability requirements). Philip Brittan describes an architecture we worked on that can recapture the connection between UI code and the domain model, while still maintaining the benefits of web based software.

If you want to add the results of Database queries to HTML files before they are published (and keep them as static pages), you can use my new utility, HTML DBScript. It will work on any HTML, but is designed to fit well with CityDesk’s “Before Copy” publishing location feature.

It’s in Beta right now, but well tested and has decent error reporting. Let me know if you have any comments by using the Contact Page.

Update: v1.0 is released. FogCreek is featuring a link to it on their CityDesk News Page.

It’s great that unit testing is getting a lot of attention. There are xUnit frameworks for every language, and secondary tools are emerging. It is also becoming common to designate some developers as “in test”, meaning that they develop software to test their organization’s development projects. More importantly though, developers are thinking about testing, educating themselves, and taking responsibility. A similar movement needs to take place in software usability.

A usability department is more rare than a QA department ever was. Most developers will never work with a usability expert, and even if they did, they still would have a lot of usability decisions to make. Like other aspects of software creation, developers need to learn the concepts of usability. But, unlike many aspects of development, usability is not clearly quantifiable or automatable. There are some rigorous methods, but usability knowledge is essentially a set of heuristics and the ability to imagine yourself as the user.

The heuristics can be learned either by example or counter-example.  But imagining yourself as the user is a little harder.

You spend all day with the software you create. It is probably one of the most important things in your life—it pays for your food and rent. You know everything about it.

Your users prefer not to even think about your software. They have tasks they are trying to accomplish (to earn money to buy food and pay the rent). Even vitally important software, like my web browser, my e-mail client or my compiler, are insignificant when compared to my family, my job, paying my bills, and having fun—and I would replace them in a second if they got in the way of those things. Keep that in mind.

The only way to learn about your users is to watch them use your software in their environment, with their distractions. You must learn what they typically know, the words they use, the things they care about. If you are a developer, don’t let yourself be shielded from the users. You need to meet them and hear what they have to say. You need to ask questions. And by “users”, I mean the people who use your software—not their bosses or their IT staff or your boss or a UI expert or a marketing guy or whoever. If you manage developers, put them in front of users.

I have learned more about financial trading software by sitting with traders than the entire time I spent writing it. There are idiosyncrasies that I would never know unless I watched them work (how little time they have to do a trade, how many hands they have free, the distractions, their patience level, their technical level, their vocabulary, etc), and I guarantee that your users are similarly unique.

For further reading: Bruce Tognazzi’s First Principles of Interaction Design, Joel Spolsky’s UI Design for Programmers series, Jakob Nielsen’s Ten Usability Heuristics. Learn from the mistakes of others by looking at the original User Interface Hall of Shame  or this other one from Pixelcentric.

If you are new to unit testing, but the source base is old, the sheer size of code to test will seem daunting. Here are some strategies for adding unit testing to old code.

• Test code before refactoring or optimizing – The purpose of refactoring and optimizing is to make the code do the exact same thing but in a different way. It is perfectly suited to being unit tested since tests you write at the beginning of the change need to pass at the end.  And, the unit tests will let you make more aggressive changes.




• Test code while learning what it does – When you’re trying to learn a body of code, a unit test is a good way to check your assumptions about how the code works. This strategy also works well in training a new developer—explain the code by writing new tests for it together.




• Before fixing a bug, write a failing test – This is the perfect time to add a test since reliably reproducing the bug is a good first step. The beauty of this is that now the bug won’t return.

In general, I would not make a project out of writing unit tests for old code (except during the period where you are installing the xUnit framework and getting used to it). Unit testing works best when it isn’t the end, but instead a means to accomplishing something else.

It was my turn to present to the DotNetSaps. Here are the slides and code to score bowling games that I wrote during the presentation.  Get NUnit, FitNesse and look at XProgramming.com for more information on unit testing.

Note on the code: This code is not done. There are at least three bugs in it, but it passes all of the tests. This means that there are more tests to write.  Here are some that would fail:

public void testNonStrikeAfterDoubles()
{
  game.bowl(10);
  game.bowl(10);
  game.bowl(5);
  game.bowl(5);
  assertEquals(game.getScore(), 55);
}

public void testSimpleEndOfGame()
{
  for (int i = 0; i < 10; ++i) { 
    game.bowl(0); 
    game.bowl(0); 
  } 
  assert(game.getIsOver()); 
} 

public void testEndOfGameStrikeInTenth() 
{ 
  game = new BowlingGame(); 
  for (int i = 0; i < 10; ++i) { 
    game.bowl(10); 
  } 
  assert(!game.getIsOver()); 
}

Not to mention scoring the tenth frame correctly. Fixing those tests and finding others is left as an exercise to the reader.

Jakob Nielsen has been supporting his book, Homepage Usability: 50 Websites Deconstructed, with a few of articles on homepage design. I took the opportunity to make some changes to my own site after reading them.

The first article, Top Ten Web Design Mistakes of 2003, lists what’s been annoying him recently. I did well on this one—I only needed to add some ALT text to my images (Tip #5 is Overly detailed ALT Text—oops, I actually didn’t have any) and make pages stop linking to themselves (#10). The latter improvement is not directly supported in my CMS tool (CityDesk) and took a fair amount of scripting, but armed with CityDesk keywords and my keyword organizing utility, I got it done.

That article linked to The Ten Most Violated Homepage Design Guidelines. I didn’t do too badly on that one either, but I decided to differently color visited links and make it more clear where you are on the site (#3). I rewrote my tag line to be more informative (#5) and made my tags more descriptive. I was already following #2 (Use a liquid layout that lets users adjust the homepage size), since that’s a pet-peeve of mine.
Finally, I read Top Ten Guidelines for Homepage Usability. By this point, most of the tips were redundant. I haven’t added a search yet, but I’ll do that soon.

The book has over a hundred guidelines sure to improve any site.

Last week I had my first experience with a GPS based guidance system, the NeverLost from Hertz. I was struck by some of the good UI choices and want to highlight them here. For a more in-depth analysis, see this evaluation. I will limit this entry to my current blog topic of usability vs. learnability  as it applies to the disengaged user.

The designers of NeverLost certainly had to design for both usability and learnability. Few will have the time or inclination to read the manual once they get to their rental car, and many will be first time or occasional users. More importantly though, the NeverLost must be easy to use. I’m sure the designers of NeverLost understood the possibility of their device contributing to an accident, and let that be the overriding concern in all of their choices. The NeverLost is a good example of designing for disengaged users, that is, users that are doing something else while using your software. The principles of the NeverLost design have wide applicability (e.g. software for call centers or traders).

Here are some of the basic principles they have adhered to:

1. Constraining choices rather than interrupting on errors: A good choice in any application, the NeverLost takes it to an extreme. Typing is hard (you choose letters by navigating over a pick-list), so the search interface only shows letters that will actually return a result. So, for example, if you pick the letters “H-O-L-I-D” in the Yellow Pages search, only the letter “A” appears on the pick list, because the “Holiday Inn” is the only item in their list that starts with those letters. Searches never fail to return a result, and you can correct errors immediately. Of course, a keyboard or a touchscreen might have made this easier, but they would also add to the cost.
2. Speech rather than text: Essential for this kind of system since you really should not be looking at it while driving.

• The display is easy to glance at: While driving, the display is simply the major routes with the current one highlighted and the car showing the driving direction.  It’s very easy to see that you are on the right track.  All other information is via speech.

• Anticipation rather than waiting for input:  We made two deviations from the directions. The first was missing our exit, and the NeverLost immediately calculated a new route and let us know what it was doing. The second was getting off at an exit to make a rest-stop—in that case, the NeverLost let us get back to the route ourselves without recalculating. Both choices were exactly what we wanted, so we didn’t need to fiddle with the interface.

• Mistakes are easy to correct: The NeverLost keeps a list of the destinations you have input and lets you easily go back to them. A Cancel button lets you back out of all choices. Having these features lets the NeverLost stay out of your way most of the time, because it knows that you can revert to an old state when you need to.

All of these are good ideas for any interface, and if you imagine that your user is distracted, your user interfaces will be even easier to use when they aren’t. Of course, a speech interface is not right for all applications, but sounds usually are, and can help to alert users when their attention is required.
When conducting usability tests, keep in mind the environment your users are in, and try to match it. For example, don’t gather users to your pristine environment. Go to them if you want to see how they really use your software and the distractions they encounter.