Remember, to design a statechart is to architect an application, and so creating the statechart diagram should be your first step to programming anything serious. And just like with programming, figuring out the proper statechart is a lot of work and you shouldn't expect to get it right on the first try.

While I can't claim to know every technique to creating a proper statechart diagram, I do know at least a few important rules that we should follow. I have already mentioned that it's better to avoid concurrent states if possible because of the extra complexity and a similar idea is to start simple and grow as needed. Statecharts are particularly well suited for capturing the generalized states for the application quickly and then iteratively adding more specific substates later. Therefore, the first version of your statechart may only include a loading, unauthenticated, and authenticated state and you could actually safely code those states in your app using SproutCore right away. Later, you will likely add several substates to the diagram and likewise, these new states will drop into your code without any refactoring. However, if you start with very granular states right off the bat, you may find yourself having to pull them out again later as the code is written.

A more specific rule-of-thumb is that it's important that states don't change their entry and exit actions dependent on external variables. This just means that, for example, we should not have a Ready state that performs the showLogIn pane action on entry if there is no session, but performs the showMainPane action on entry if there is. To do it like that would mean we've actually got two different states being represented by one. Instead, we should have a ReadySession state that will always show the main pane and a ReadyNoSession state that will always show the login pane. Then all we need to do is to go to the proper state depending on the session. In this way the ReadySession and ReadyNoSession states can be unit tested, which means more importantly, that they are self-contained.

Keeping states self-contained is the most important rule that I can impart to you. The independence of a state can make the difference between a rock solid application and one that crashes after heavy use. The reason for this is that bugs are often unavoidable. Even the best of us make mistakes and things can, and at some point likely will go wrong. However, if all of our states are independent, when a state has problems, we can usually recover simply by getting out of the state and back into a safe state.

Thinking in terms of state independence will probably be the best tool you will have for defining states. Another easy indication of what constitutes a state is the appending and removal of a pane. If we know we want to show a pane, for example, the main pane, we will definitely have a state that upon entry will show the pane and upon exit will remove the same pane. In this way, the state initializes itself and also cleans itself up, which are two key goals for defining a state. If a state can totally initialize itself and totally clean itself up independent of all the other states, it will be a strong state in your application.