These days, I'm a lot better known for my writing on agile processes and management than for anything I ever tried to do in user interface design. In my book, I apply something called The Theory of Constraints to software engineering. TOC as it gets called is really very simple. Just 5 focusing steps.

1. Identify what constrains a process - its bottleneck
2. Protect the constraint to maximize the throughput at the bottleneck
3. Subordinate all else to the decision to protect the constraint
4. Elevate the constraint
5. Do not let inertia stop you from repeating from Step 1 by finding the next constraint.

So how is this relevant to UI design, usability and interaction? Good question. First a digression...

Jakob Nielsen has followed up with his latest guidelines on link color for optimal web usability. Somewhat surprising some of the web design community actually feel he is adding value. This funny and educational piece from Design By Fire gives it the thumbs up but suggests that it is time for a makeover at Jakob's own site. So they assemble their own fab five with a design eye for the usability guy.

It seems that Jakob Nielsen is back grinding on one of his old organs with the current AlertBox and the tune is "standard link colors improve usability". No one can blame Jakob for recycling old material. My goodness, he has been publishing a weekly column for almost 10 years, things are bound to come around again and again. This link color thingie has come up again and again for me too. The first time was while I worked at IBM on a project called PartnerInfo which later morphed into the engine which powers the ibm.com e-commerce web site. "We can't have red links", came the cry from marketing. "Red is the Digital (Equipment Corporation) colors! We're blue! They're red!" Do I hear anyone say, "fighting the last war"? The second time was when I was at Sprint and it was deja vu all over again. "We can't have blue links!", came the cry from Marketing Communications. "We're red, silver and black. We're Sprint!" This old saw ground back and forth between the usability engineers in the user experience team and the mar comm people for months. "Blue is ATT" they would say. Wait a minute, don't you mean Cingular? But they're orange, right? No, Orange is a UK carrier, owned by France Telecom. No, they call it Orange France now! No, France isn't orange, that's Holland. France is red, white and blue - touché, the correct colors to use on a web site. Ah the French were correct all this time.

So, let's take a look at the link colors on this new look uidesign.net site...

It's been a long time since uidesign.net was a regular feature of my life. Well I have finally set up a content management system to make life maintaining this site a lot easier. I still have an interest in good product design and excellence in user interfaces. I have a particularly strong interest in architecture and modeling techniques for making user interface development more robust, more agile and more transparent to management. I will be maintaining an occassional weblog here and publishing some occassional papers. This month I publish a paper by guest author Ritchie Macefield. Look out for a weblog entry every couple of weeks, no more often than that. I'll also be bringing across all the best material from the old site into the new content management system. For those of you looking for the old site in the meantime click here.

By guest author Ritchie Macefield...

Abstract

Amongst other things, the bursting of the dot.com bubble signalled a reassertion of the principle that only businesses who have a good customer proposition can succeed in the long term. Simply offering products and services on-line via the web is no substitute for a sound 'go to market' model. Further, this paper demonstrates how many would be e-businesses, seduced by the lure of the emerging 'virtual-world' on the web, have ignored 40 years of accumulated wisdom in how to design usable information systems, and have seemingly forgotten that a satisfying 'user experience' is key to the successful implementation of any information system, particularly one in that operates in the public domain. The paper uses the allegorical experience of a 'real' user to provide some powerful insights into how, and by what rationales, the e-marketeers, graphic designers, web designers and programmers responsible for many B2C sites are creating user experiences on the web that are confusing, frustrating and time consuming. Having explained the main problem areas, it goes on to explain why 'clicks and mortar' companies may be better placed to exploit the web than many pure e-tailers, not just because of their business experience, brand identity and multi-channel capability, but because they retain a focus on the importance of user-centred thinking.

Download the whole paper [PDF]

From the Proceedings of ForUse2003, here is the paper I co-presented at the conference.

"Lean Interaction Design and Implementation: Using Statecharts with Feature Driven Development"

Abstract

Lean UI development in Feature Driven Development is achieved through right-first-time implementation of the interaction designer's intent using David Harel's Statechart notation to model the interaction design. Statechart notation can be directly mapped to an MVC Type-II architecture and Mediator Pattern. With a few minor extensions Statechart notation can be used to model complex application behavior such as exception handling and transactions. Statecharts can be mapped into UI Features for tracking using an FDD Knowledge Base. The Statechart can be drawn using a UML modeling tool, and imported into the JStateMachine engine which implements a table driven Mediator and Command pattern system in either a Web Servlet or JFC (Swing) environment. The result is reduced variation in UI development and precise implementation of the interaction designer’s intent. JStateMachine (an application framework) validates the runtime code against the original interaction model insuring accurate runtime implementation of the UI design.

[Download in PDF]

This is the long awaited third part in the series of articles describing a generic server-side architecture for transactional eCommerce websites, using a Model View Controller architecture or Mediator Pattern [Gamma 95] configuration.

Part 1, outlined the architecture to be used to handle the event driven nature of an http request - html response, server to client system, and detailed how to deliver this in a 3 tiered model of Presentation Layer, Business Layer and Persistence Layer. The Presentation Layer is modeled using UML Statecharts [Horrocks 98] which lend themselves to easy implementation using Mediator Pattern which provides the View and Controller elements of the MVC model.

Part 2, explained how to implement the infrastructure to run the MVC model using UML Class Diagrams, Statecharts and Java code to process and respond to http request events.

In Part 3, we look at how all this hard work developing infrastructure can be made to pay off and deliver real advantages. We look at how to protect the system from unexpected browser (client-side) events or activities such as refresh, back, and bookmarks. We will see that this can be achieved with a single piece of code to manage all of this activity.

We will also see how Statecharts can be used to cleanly model the boundaries of logical transactions and how the MVC engine can be used to provide protection of these transaction boundaries (transaction isolation [Gray 93]) and scoping using a single piece of code.

Finally we will look at how exceptions to normal operation can be cleanly handled and implemented within the same system.

Handling Statecharts Generically

With interaction architecture documented using a UML  Statechart, it is possible to simply develop a hard coded solution where one HTML page invokes another. Event transitions would be hard coded into links and form submissions, and the next states into the requested URLs. I have seen very adequate implementations of this - particularly using Servlets. However, it is an inflexible approach which doesn't easily support condition evaluation and is likely to involve considerably more maintenance. It does not provide for a central facility to protect against unexpected use of bookmarking, back button or refresh and can lead to extensive code to protect the back end application from unexpected browser events. As a result many transactional implementations simply ban the use of the highly desirable web browser features.

Far better, if you have time and are willing to make the long term commitment, to invest in a genericised architecture which allows you to "soft" code the design of the system as a description in a database. This is the 2nd paper is a series of three which shows how to build an  engine for the generic treatment and processing of events and state transitions.

Why do we need a server side Presentation Layer Architecture?

The Presentation Layer of a web server application is rarely designed. It's usually just coded. For small and medium sized sites this can work perfectly well but it becomes chaotic on larger sites. This article provides and structure and notation for designing the implementation model for large scale web server presentation layers. This can lead to better project management, more accurate tracking and ultimately better time estimating and closer control. This leads to developer and management confidence that the system under construction will work soundly and will be finished within a reasonable time frame. The advantages for project management and how to track a Presentation Layer development cycle using the techniques in this paper will be discussed in a future White Paper at this site.

The increasing demand on web applications is making them more and more complex. Very quickly they are becoming as sophisticated as many GUI Client/Server applications. This is puting a strain on the traditional "stateless, thin client" idea of a web application. Modern web applications have to carry out conversational transactions with the client. This requires the server to have a firm idea of the client state and a strong knowledge of the transaction boundaries. Part 3 of this article will show you how to scope the transaction boundaries within a Presentation Layer and how to enforce them leading to improved Transaction Isolation.

Introduction

Back around New Year 2000, I was considering how best to replace the Book Reviews at uidesign.net. It seemed that rather than analyse what the authors had to say, it might be better to ask the authors directly - Interviews. So I was left with the next big question, "Who do you ask to do the first Interview?". The new site branding and slogan, "The Webzine for Interaction Designers" provided the answer. It had to be Alan Cooper. As author of two excellent books, "About Face" and last year's "The Inmates are Running the Asylum" he is the founding father of Interaction Design and perhaps its greatest advocate. To my surprise he said yes about a month later. The eventual result was an 80 minute phone call on Friday 11th February.

You don't so much interview Alan Cooper as the whole Cooper Interaction Design media machine. All the questions were submitted in advance for approval. It was to my surprise then that we strayed off the script right at the beginning and never quite regained the plot. The result was a fascinating 80 minutes of conversation which did much to help define what uidesign.net is all about and to lay out the road map for areas that Interaction Design needs to address. In part 1, Alan takes his time to explain exactly what he means by Interaction Design and why it isn't Interface Design and exactly what role Interaction Design plays in the whole gambit of User Centered Design disciplines.

Before the interview started I really thought I had some chance of holding my own with Alan Cooper. I thought I knew a bit about Interaction Design and I could ask some intelligent questions. We had a good script and we had an hour of his time. However, what was intended to be an Interview immediately became an audience with the master. It became difficult to slide in the questions as Cooper began to tear up the rulebook for the technology industry and throw it out. He discusses why Interaction Design is about complete systems architecture and he hits on what's wrong with relational databases; what's wrong with file systems; why Interaction Design is a lot more than Interface Design; and why he really doesn't like Usability much either.

We kicked off with an introduction to uidesign.net and a discussion of the audience and the message...