One illuminating example was a calculator application which had numerous errors and crashes which stemmed from intricacies of the UI implementation. By designing it as a statechart transitions are made visible and relationships are clear. The book provides three more examples.
In addition to the posted blog post, there are two more concepts in statecharts that I think are important: history and concurrency. They are not easy to explain in this comment, but the gist is that “history” allows for a simpler expression of returning to a previous state and “concurrency” formalizes the behavior of having concurrent states.
I’d recommend anyone to take a look at the book and I’d especially recommended to anyone who is a little skeptical of the idea of statecharts. I think the biggest argument against statecharts is that it requires you to specify your actual design, instead of just hacking on the code.
the top few comments i find compellingly skeptical.
1. You are designing a system that is handed off to an unrelated development team (common in agency work).
2. You need a stronger document of record because you lack enough trust in the development that a project plan plus design deliverables are insufficient when it comes to delivery and product quality.
When you go as deep as explicit pseudo code you are essentially building the project twice aside from testing and refactoring for edge cases. That is slow and expensive. If the UI is built using a very deep level of abstraction with lots of scaffolding I can see why the scope creep doesn't matter, because extreme abstraction can easily blow out a project from 2 weeks to four months so why not add an addition 2 months for planning and review.
On the other hand UIs can be formally specified by code if the code when the code is small (not a super deep abstraction) and when the content/behavior are separately defined from the code that builds the UI. Keep it simple and deliver more by intelligently doing less.
An area that I think about a lot is how effective are companies at spreading useful information to the people who can best utilize that information. Internal tools are interfaces to information. Wikis, mailing lists, code repositories, Q&A boards, chat rooms are all different interfaces that I commonly search through for useful bits. A formal spec would help us quantify how effective our company is at spreading information. What information is commonly rewritten, what pages are hard to get to, which internal tool does a page of documentation belong to, etc.
Look at this for example. If you wanted to change the login flow to add signup with a third-party provider (oauth etc.) it'd be trivial to change the markdown.
That said, I'm not wholly against the idea of formally specified UIs and am glad people are putting thought into the area as really this shouldn't be either/or situation.
At which point, formal methods are exactly what you want, as you’re more interested in stability than plasticity at that point.
I’m not even sure UIs should be changed as often as they are (change is by default a negative, and has to overcome that loss, as you lose the many benefits of “getting used to it”) but thats a separate issue
Early prototyping, designers and developers working together directly, continuous builds, frequent feedback from users—all of these things feed into this improvement process and make the end result better. I'd worry that formal specifications would have the opposite effect.
If what you are getting at is that it is not widely used/not used in anything “successful” and thus just a pipe dream, then I understand your concern. But that doesn’t mean it can’t be a useful strategy for some fields nor that it couldn’t produce more reliable systems.
This allows you to do interesting things like generating instances of your UI state that match particular logical constraints (https://medium.com/imandra/constraint-solving-your-uis-8933f...) or formally proving properties about the state machine (https://medium.com/imandra/verifying-reasonreact-component-l...), but working directly with the code of the state machine itself rather than on a separate spec.
Disclaimer: I work for AI developing Imandra working on these tools.
Once that's done, there goes your formal specification. We know what we're doing, how we're going to do it and we can work on the impl.
From my experience having well a documented code base allows you to understand decisions at a later date, especially when key members have left the company.
Great podcast overall.
(Does anyone know what this type of chart is called?)
In relation to this article, it could be useful to watch how many people take paths across the states. Tracking that doesn't necessitate a formal specification, but it helps. Then you could optimize common paths or eliminate unused states or transitions.
A resource like this is useful for when we, or UI designers we work with, are confronted by clients who want something flashy but impractical.
That said, if HSCs aren’t the solution, what is- specifically to the authors problem of having overly many transitions to ‘home’ states?
But I’d propose that a good UI will usually split easily into a hierarchy. I don’t have proof of this, but I’ve worked with both buggy code and confusing UIs caused by multiple inconsistent ways of making essentially the same transition (e.g. in Jira, cards present a slightly different set of controls depending whether you open the URL directly or click on them on a board, and that drives me up the wall). Hierarchical state charts rings true to me as a good approach to fixing this.
Yes, HSMs are very rigid. It's one of the few downsides (which I admit as a Harel state chart fanboy). However, the particular problem you address can be handled by cross-hierarchy events, i.e. one state emits an event, and some other state elsewhere handles it. Plus, of course, not everything is nested; you have orthogonal regions, too.
 One interpretation of this rigidity is that it represents the requirements faithfully and compact (YAGNI), so you don't have a level of abstraction that could be used to soften the blows of further requirement changes.
What I'd like by default:
1) Borders and margins
2) Better colors
3) Decent font
He's 100% right to conceive of interfaces as a finite state machine.