I can't seem to get State Machines off my brain this week, sad isn't it?

I find that I use them so rarely, yet I have a nagging feeling they could be so incredibly useful. I think it's ultimately because they could let me separate concerns.

Take today for example, I was building run-of-the-mill ASP.NET wizard/form with roughly the following steps. This GUI workflow is to implement a simple online survey that people can submit.

I started out without even thinking about state machines. I just had the use-case docs on my desk, and was hacking some ASP.NET page together. It was getting messy fast.

I really wanted to use some implementation of the state pattern. But, one gripe is that implementations of the state pattern tend to take so much plumbing code to express the state transitions. This article demonstrates my point, I just didn't have time to invest in that much "stuff" (not wanting to diss the author, much of it looks fantastic, I just wanted something easier). Even drawing a state diagram takes too much time IMHO.

I was trying to dream up a simpler way of expressing this state machine kind of thing in code, and so far have come up with the following. Note that so far I'm only communicating states and transitions, but it's a start:

Start -> [Introduction || AlreadyDone]        
Introduction -> Terms -> Scores <-> Nomination <-> Confirm -> Thanks 
[Terms, Scores, Nomination] -> Saved for Later

If I could make this into C# I could then express the 15 possible transitions in only 3 lines of code!! I like that a LOT. In case you're wondering what the symbols mean, here's a brief explanation:

• -> for a one way transition
• <-> for a two way transition (essentially 2 separate transitions)
• Grouping similar transitions using [a, b, c]->d

I've just got started thinking and playing with this stuff, and I hope I can take it somewhere useful!