Friday, September 24, 2010

Stateless User Interfaces

Is there such a thing as a user interface with no states? Normally, they have dozens of states, several of which may be active at any given moment. Envisage launching a program. You, the user, are given a starting point. This is the initial state of the user interface. From here onward, the changes in state are triggered by user input. Large programs, with many user interface elements, have numerous potential states while smaller programs might only have a handful. Desktop GUI applications are fundamentally different from web applications, including how different states are maintained. Is one ideal more complex than the other?

The visual elements of a user interface are called widgets. Widgets are the basic building blocks - larger widgets are composed of smaller ones. For example, a button is a widget. So is an input field. Both can be in one state or another. A text input widget can be in a focused state. This is what happens when the user clicks inside the widget. It changes state. Prior to being in a focused state, the text input must have been in another state. Probably a normal state. Another distinctive state found in the text input is when the user is actively typing. This puts the widget into a composite state since it must also be focused in order to type in it. The state of any user interface is the sum of all the widget states. This is a complex configuration.

Can a user interface exist without being in one state or another? An HTML page is an example of a stateless user interface. This is counterintuitive given that they contain widgets. Consider an input field. Does this widget have have any states in an HTML page? HTML widgets do have states but they are of no concern to the application. Only the browser. In a desktop application, widgets are created with a programming language. HTML is a markup language. Widgets created using a programming language have much greater control over the potential states of a widget.

For example, a desktop application might create an input widget. In addition to the basic construction parameters, id, default value, and so forth, an event handler might be set. The event handler is executed when the widget enters some state, like a hover state. Events are often triggered by changes in state. The event handler can do whatever the programmer deems appropriate. This flexibility exists in programming languages, not in markup languages.

If Javascript is considered a programming language, can widgets in an HTML page have states? Indeed, this is the intent of Javascript - when a widget changes state, a function can execute. Javascript libraries provide their own widgets that build on those found in HTML. These abstract widgets also have states. The goal of these custom widgets, and Javascript in general, is to make web pages look and feel more like desktop applications. So why is it that desktop applications feel better in comparison to HTML pages? CSS can add styles to a page that captivate the user. They can also destroy the whole user experience. Web pages with HTML and CSS that are done right can surpass the feel of some desktop applications.

A desktop application uses a single programming language and widget library. The developer has to consciously separate the logic from the presentation. A web application also uses a single programming language but places the presentation in a markup language. Here, the developer also needs to consciously separate the presentation from logic. But HTML is naturally separated from the application logic because it is a presentation language. A web application that uses a programming language for logic and a markup language for presentation is easy to understand because of this. Adding Javascript on top of the presentation means adding state to the page and isn't so easy to understand.

Stateless user interfaces aren't necessarily better than user interfaces with states. They have less complexity. The challenge, is to create something that looks good and is maintainable. Javascript, especially asynchronous HTTP stuff, lowers maintainability. Desktop applications are meant to have different user interface states that the programmer can use and react to. Javascript adds state to something that is supposed to be static. If the level of user interactivity is important, if you need to handle complex user interface state configurations, consider building a desktop application instead.