The journeylism of @yreynhout

On CQRS, DDD(D), ES, …

Your UI is a statechart

Let that sink in for a minute … Raise your hand if you start out by designing a behavioral – not to be confused with a navigational – model of your UI before transforming those nice mock-ups into code. Yeah, I figured as much ;-).

Why on earth would you want to turn user interface development into a software design technique? For the same reason all those XP engineering practices are so appealing: So that it can be changed repeatedly throughout the lifetime of the system. I think most of us know how fast UI code can become  ‘spaghetti’-shaped, despite our best effort to adhere to patterns like MVC, MVP, MVVM et alii. We all aspire to have a UI that can be quickly and easily written, is easy to test using white box techniques, can be modified without introducing side-effects, and can be regression tested without manual labor. Yet, if we’re honest, that’s rarely what we end up with. I for one am a strong believer that using statechart notation for all but trivial User Interfaces is a must to get us there. It offers insight you can hardly get from looking at either a mockup or controller code.


Let’s look at a simple master detail screen from which I’ve deliberately omitted things such as navigation and paging. It’s a fictional “crud” screen used to edit Eurostar train stations.

Master Detail UI - Example

It’s pretty easy to spot the behavior you have on this simple screen:

  • Filter: Filter the list of stations
  • Sort: Sort either one of the textual list columns
  • New: Start editing a station to add
  • Save: Save the station being modified or added
  • Cancel: Cancel the modification or addition of a station
  • Delete: Delete an existing station (the ‘X’ column above)
  • Select: Select a station to modify from the list

Coding each of these behaviors according to your pattern of choice is probably easy enough that I don’t have to explain. Yet, what you’ll end up with is:

  1. no abstract view of the software: you’ll have to look at the code each time a question comes up about the behavior of the application.
  2. implicit contexts: you’ll probably have conditional logic in your save event handler/controller action to determine whether a new train station is being added or an existing train station is modified. Granted, some patterns (and associated frameworks) will have pointed you in the right direction on this one, e.g. the webby ones might have turned these two contexts into two distinct urls. But take a better look at the above screen … that’s one screen, not two (which is the easy way out most people tend to take).
  3. software that is not working correctly: it depends on your skill as a developer to identify all possible ways a user can supply an event (behavior) to your application.

There are other points to consider like the resulting code being object oriented or easy to maintain. To me the first point is about design as a communication tool. The last two points are the most insidious, and here’s why:

When I’m adding a new station or editing an existing one, what happens when I press the “delete” button (X) of a station item in the list or when I press the “new” button or I select another station?

Again, you could disable every other trigger (button/link) on that screen while in “edit” mode just to prove me wrong. We could have a lengthy discussion on whether one is better than the other from a usability point of view. Suffice it to say that I consider disabling triggers to be the easy way out, so just indulge me here :). I’m not going to beat about the bush and just show you one possible resulting statechart for the behavior of this screen:

Statechart - Train Station Administration

Taking the Filter behavior as an example, you’ll get something along these lines (pseudo-code) in a traditional

//Called directly (when the Filter event is triggered)
public void Filter() {
  if(WeAreInEditMode) {
  var stations = QueryStationsUsingFilter();

//Called after save confirmation
public void Reload() { 
  var stations = QueryStationsUsingFilter();

while in a statechart driven approach you’ll get:

//Called both directly and after save confirmation
public FilterGuard Filter() {
  var stations = QueryStationsUsingFilter();
  if(stations.Any()) {
    return FilterGuard.Filled;
  return FilterGuard.Empty;

The main difference is that all the conditional logic in the first approach is inside your controller, while in the latter approach the statechart “runtime” takes care of tracking what is essentially context for you.
The statechart “runtime” protects you from making illegal transitions and is in charge of the flow, alleviating your controllers from using conditional logic to determine what context they are in. Since the controller methods either return void or a guard value, it’s obvious this is not your ASP.NET MVC variety of controller. The statechart “runtime” works best in conjunction with a front controller, POCO controllers and viewmodels that enable changetracking.


This was just an introductionary post. There are a lot more details to discuss/describe. Maybe someday I’ll muscle the enthusiasm to write about them. If you can’t wait to learn more about this technique, then do read Ian Horrocks inspirational book.


8 responses to “Your UI is a statechart

  1. redsquare10RedSquare December 9, 2011 at 10:33

    Nice to see Ian’s book on sale @ Amazon for >£140!

  2. Pingback: Viewmodels like you meant it « The journeylism of @yreynhout

  3. josefB March 6, 2012 at 17:27

    Years ago I was successful in creating a statechart driven web based UI. Since then I’ve read some discussions that are pro and con. What I find interesting, is that even when you don’t explicitly design and use a SM, you are in fact using one. it may be spread all over thousands of XML files and properties, but there is one. Why not just make it explicit?

  4. hoopmastaflex February 7, 2013 at 17:27

    What software was used to create the statechart you have in this article?

  5. yreynhout February 7, 2013 at 17:30

    @hoopmastaflex Good old MS Visio (A3 size) with stencils from Pavel Hruby (

  6. Tim McCoy December 10, 2014 at 00:25

    I’m sitting in a meeting right now where a major global software development company is describing a user interface to 75 people. No state charts – just screens. There are many questions about the implicit behavior. I stood up and asked the engineers if they realized that they should document behavior with state charts. Crickets. Oh Well.

  7. Ian H March 1, 2017 at 23:41

    I wrote the book back in 1998, any thoughts on why the idea is not more widely used?

    • yreynhout March 2, 2017 at 10:59

      The general tendency seems to be growing UIs rather organically, where the word “design” seems to be reserved for fleshing out mockups and navigation maps or crafting a visual language (typography, color scheme, etc.). The behavioral design happens in discussions, as pieces of text written in an issue tracker, incomplete and inaccurate … that is, if we are lucky. The cost of not doing it (properly) becomes a hidden cost, leaving its trail in quality assurance staff complaining about unexpected or undocumented behavior and in production when end users end up in a state we can hardly (if at all) reproduce. It baffles me how “time to market” is often the argument used to wipe this relatively small upfront investment off the table. Ever since I’ve read your book and applied what I’ve learned from it, that is from coding the actual statemachine to just using the notation as a better communication tool, I have been using statecharts (and especially the hierarchical kind) in pretty much any type of work I do. I’d love to see the word spread …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: