Good UI's are engineered.

I have crossed the designer-engineer border many times, and I have come to the conclusion that many people have the wrong mindset about "UI Design". Many relate the "design" closer to designer jeans, than they do to say designing a bridge. While it is the decoration that makes the finished product appealing, it is the structure that is most important.

This is how most UI Design processes go:

1. List out desired features
2. Sketch a few ideas
3. Mock until everyone agrees on something

The bitter truth is:

1. Features change
2. Usually your first instincts are wrong
3. Design by committee will give you a camel

UI Design is really no different than Network Design, Architectural Design, or any other form of structural design. You need to approach it with a set of given base parameters and develop a metric to measure all proposals against. A more proper procedure would be as follows:

1. Define the primary needs that the product provides
2. Script out the most common use cases
3. Draw flow charts to illustrate user paths
4. Define set of controls and display elements
5. Group related/parallel actions accordingly
6. Sketch out various options of all necessary screens
7. Measure if controls are present when wanted
   
8. Measure distance to action and number of clicks to complete action

Once screens, grouping and positioning is defined, it is now the time for decorations that will make actions intuitive and draw the right attention to the right items for each screen and to invoke the appropriate emotional responses from users. But, doing this earlier in the process often blinds you to other layout possibilities.

Now when you look at this second process, it may seem longer and more daunting. However, the truth is that when you skip over the initial scripting and mapping process, you loose the metrics by which you may measure the successfulness of all future design proposals. When you follow the complete design process, you actually can spend less time in mocking process, and have a more measurable certainty of success in the end.

Client MVC

A solid framework can make or break an evolving application. All to often, a simple application will grow too big for its britches and you are left with an organic mess. Lately, I am witnessing this the most with the re-emergence of fat-clients utilizing Ajax or similar technologies.

There is little in the way for JavaScript framework out there, with Google's Web Toolkit being one of the few that is widely used. JQuery/Interface + DOJO or SAJAX could also bring back some sanity to your project, but the lines between Model, View and Controller are still blurry and unmanaged.

I have found a couple good blogs that start to touch upon this problem, but no great projects that deal with the problem on a whole.

triad: a javascript mvc framework

Do RIAs Make You Rethink MVC?

And even beyond the all so common Ajax-backed fat clients, there are still other technologies in the client scripting world that need an MVC framework to work with. JSON, Flash, XAML, and XULE are just a few that come to mind.

Perl has Catalyst. Java has Struts. PHP has Mojavi. Python has Rails. But, JavaScript still lacks a flexible, multipurpose MVC framework that fits nearly any project. It seems the ideal candidate would be able to utilize existing toolkits interchangeably.

Avoiding 'Slow Script' Errors

So, you need to render 2,968 widgets to the DOM? Or, you really, really rather compute your data on the client, because the architectural geniuses you work with never thought you would want to cross-relate these two data sets, and it will be a load of work to re-architecture the back-end to handle this task? Well generally, my advice would be to avoid doing such tasks on the client, but that is not because it is not possible.

Sometimes when prototyping algorithms or cross-linked data presentations, I find myself pushing the computational barrier of JavaScript. Anyone who has done this, has managed to repeatedly trigger the 'Slow Script' warning asking the user to either stop or continue. These messages are easy to avoid with a little code modification.

function RenderDataSet(start) {
    var SEGMENT_SIZE = 100;
    var index = 0 + start;
    do {
        RenderData(index);
        index++;
    }
    while (index < dataset.length
        && index < start+SEGMENT_SIZE);

    if (index<DataSet.length)
        setTimeout("RenderDataSet("+index+");",1);
}

Since you are only allowed a few seconds of the thread's time to carry out your task, and there is no forking or spawning available for you to make new threads, you simply have to rely on setTimeout(expr,time). This releases the thread for a very small fraction of a second to allow other browser actions to occur. This is also a good practice to get into for real-time applications as well, since expensive tasks can slow down other features of your web application.

Crash IE6: With HTML!

Any serious client-side web developer has managed to crash a browser with some string of complex JavaScript, XSLT transform, or ActiveX Object. But what about with just some good old HTML?! Certainly a sixth-generation browser with several years on the market, such as Internet Explorer 6 could not be brought to its knees with some simple HTML. Well, guess again.

Ponder the HTML below and see if you can guess what evil it possesses:

<div>
<div><a name="input1"/><input name="input1"/></div>
<div><a name="input2"/><input name="input2"/></div>
</div>


I mean that looks perfectly safe and sane to me. Well, not to IE6. See, IE6 does not like self-closing anchor tags. But, instead of dropping the tag from the DOM, or adding an immediate </a> to correct the problem, it must do something completely different, because IE6 will crash when it stumbles upon this code.

I spent an hour of trial and error, searching for the culprit, before I isolated this code on one the web pages I was building. Not even for a split second did I suspect that it would be a bit of HTML causing IE6 to stop dead in the water.

AJAX: Asynchronous?

Asynchronous?

So AJAX stands for Asynchronous JavaScript and XML. As a technology, it sounds perfect for supporting client-server communications for fat-client web applications. But is it really? I mean, it is 'asynchronous' and it's HTTP, right? Well, not totally...

While the XMLHTTPRequest object does make an asynchronous call to the back-end server, these calls in themselves are not asynchronous on the TCP layer, only at thread-level are they asynchronous. Therefor, the calls themselves are synchronized and prone to being queued.

According to HTTP 1.1 specifications, only two connections are supported per process. Internet Explorer sticks to this limitation, while other browser such as Firefox support a higher connection limit by default. The means that requests get queued if there is more than the browser limit already active.

When requests queue up, long requests will block other requests, including images, javascript and css file calls. So, if you really want an asynchronous call system, AJAX is not the solution. But most likely a piece of the total solution.