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.

I’ve been playing around with ArgoUML, an open-source UML modeling and code generation program. So far, the major drawback for me is the non-standard UI elements because of Swing—I really hate Swing File dialogs—even the “Windows” look and feel ones.

My first impressions are very good. I have spent seven years with Rational Rose and like it very much, but it is out of my price range right now. I haven’t used any other products and I am only interested in packages with some kind of code generation and deep UML knowledge (that rules out generic drawing packages). And, price is an issue. So far, Argo meets all of my basic requirements.

One of the features I think I will like is what they call cognitive support. It manifests itself in a list of suggestions about your model. For instance, in playing around, I have a class with no non-static members or associations. In the to-do list, I see a suggestion to make this a Singleton. Argo also helped me understand some of its conventions by suggesting names for the packages I made. In general, Argo understands UML, and does a great job of helping you create it.

The code generation is in the early stages, and in inadequate for use on a project unless you are using an editor that will seamlessly fix the code into your standard tabbing style. Even when I use UML as a sketch, I like to generate the code as a sanity check to make sure the UML says what I think it says—it’s good enough for that.

Large multi-person projects might find the lack of external packages (packages each stored in their own file) a deal breaker. Rational has very good support for this, and it’s essential when you try to use UML as a programming language, since having one big file becomes a impediment to collaborative development. This extends to property sets as well, which I don’t see how to share between models.

Here’s my first model:

Created to mimic the design in this NUnit presentation.

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.

Although UML is usually not associated with agile processes, there are two ways I think it can play a major role in an agile development project.

The first is a full adoption of a UML toolset, including full round-tripping through the entire implementation. In this case, UML becomes part of your programming language. It maps very well onto the constructs of Object-Oriented implementation languages, and there is nothing about it that will stop you from doing all of the things you do in an agile process (Simple Design, Test First, etc.) The benefit is that you have a up-to-date UML document at the end of the implementation (why you might want this, I’ll save for a future entry). I have done this with Rational Rose for C++ with great success, and if you want UML diagrams that actually match the implementation, this is the way to go.

The other use is to not even attempt to keep UML documents consistent with the implementation as it progresses, and just use UML to convey design ideas. This is more precise than a text description, and certainly a good supplement to one. Design Patterns by the GoF is a good example of a book that uses UML to convey design ideas. Martin Fowler’s Patterns of Enterprise Application Architecture uses it extensively as well, and he says this about the UML in his books.

Most UML diagrams shown in books, such as mine, are sketches. Their emphasis is on selective communication rather than complete specification. Hence my sound-bite “comprehensiveness is the enemy of comprehensibility”

Unless UML is the implementation language (where completeness is essential), then there is no need to include every detail in the drawing. In fact, inclusion communicates importance in this context.