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.

Didier suggests that Jakob's site is ssssoooo 1996. However, those of us who remember useit.com back in 1996 will tell you it wasn't nearly as cute looking in those days. The current design dates from about 2000 but I'm sure Jakob could tell us more precisely. We have to remember the raison d'etre for Jakob's design (lets be charitable on this). He was primarily preaching that page load time was the key to usability. Long load times turned people away and as his client base was e-commerce web sites, that meant lost sales. So the message was keep it simple, keep it under 100K per page and keep it fast. Keep those clicks coming. It would be fair to say that Jakob was arguing that bandwidth was the primary constraint to usability. Notice that this is step 1 of our 5 step process.

So if we have identified a constraint what do we do next - we protect the constraint. How do we do that? We keep page sizes under 100K and smaller if possible. What next? We subordinate all else to the decision in step 2. That means you can forget those nice graphics and complex table layouts.

But then we get to step 4 - elevate the constraint. And there have been a few threads running there. The web development community has not been idle. Nowadays we have standards which reduce markup size and use CSS for layout [uidesign.net isn't up with the times yet, is it? Ed.]. But the real elevation came with the adoption of low cost broadband. In most developed countries adoption is around 50% already and dial-up connections are faster than they used to be for many people. The bottom line here - bandwidth is no longer the constraint!

What that means is that all bets are off. All the rules and guidelines, all the policies designed to protect the constraint and subordinate all else to the decision, are history. We need new rules which identify the new constraint.

So the question is, from a usability perspective are we letting inertia stop us from going and searching for the real new issues which constrain web sites from achieving their goal, or are we moving on, forgetting the last war, and actively out looking for that new constraint and seeking to write the new rules for a world where broadband is ubiquitous?

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. Hmmm. Standard links in the main body of the text are blue-ish, and they have a lit, fly-over in a stylish pale orange to match the site design. When you traverse the link and return to the page, you get a red-ish pink link to show that you have traveled that way before. Seems pretty usable to me and still fits with the site design. However, there are exceptions. The headlines of each article are hot and a fly-over lights them with a brighter, paler orange. However, if you follow the link and return, they hold the standard orange headline color. Why is this OK-ish? Well the headlines are redundant links for convenience - they are also larger targets than the primary link which is the "read more..." at the end of the article teaser.

There are two other exceptions: the primary banner navigation simply uses a fly-over pale orange, and so does the secondary sidebar navigation. I have deferred somewhat to standards. The links are darker in color and when lit for navigation they are lighter in color. This follows the basic - blue is darker than red - principle. If you were watching in monochrome, you could still understand the navigation. The main and secondary navigations, don't change color after you return. I have two different reasons for justifying this. On the banner navigation, the links take you to major parts of the site with additional navigation lists of articles, interviews, book reviews and so forth. They banner links aren't destination links, they are merely signs on the road. Knowing whether you have visited the list of book reviews is not particularly useful. With the side bar navigation, the links are mostly offsite links. The teleport you to another web site from which you may not return. There is limited utility in having these links change color. If they did change color to red-ish pink when traversed, this would truly only be useful within a single session, i.e. if I were using the Favorite Links lists to go surf a blog roll using the back button from each one to return to the list. However, across sessions, say from one day to the next, I really want those "already navigated" red-ish pink links to reset back to dark green. As my web site has no way of knowing about user sessions, I defaulted to not displaying a previously navigated state.

Did this break the rules? Yes. Are the rules correct yet? Probably not! Do we know all we need to know about this space? Again, probably not. Did it all get too boring before we got the real science done to provide truly useful design guidelines. Yes, it probably did. Do old saws like "untraveled links are blue, and traveled links are red" really help us in the modern web design world? Comments, please...