Are statecharts the next big UI paradigm?
slideshare.net
slideshare.net
1) Your user interface probably has more edge cases than you or your designer anticipated, and IME the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
2) Many of your state transitions probably share similar helper logic. So you want to break that stuff out into its own non-state-based organization anyway to avoid copypasta, and at that point, similar to the above, representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic. That is to say: I think your "states" should be big and chunky - occasionally one feature's flow will transition you into a different feature, but whenever I've tried to push that model down to the individual screens and buttons level, it's caused self-induced pain.
If I had to reduce it to a soundbite, I'd say: your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
(Where this KISS approach goes wrong in practice is you don't have enough team discipline about organizing your biz logic code, or you try to share the wrong things/too early, and some biz logic ends up in every layer of the UI, and you get lots of big pull requests touching lots of files with hot spot files frequently having merge conflicts.)
Here's the thing. As developers, we write implicit state machines in our UIs all the time, in the form of boolean flags, or enums if we're feeling disciplined, or peppered if-else statements everywhere. Arguably, most (if not all) UIs can be represented as explicitly classifiable states, and actions that can occur that can transition those states into other states.
So I'd argue that having _some_ sort of declarative formalism for describing your app's states and transitions is much more beneficial than having an ad-hoc way of imperatively changing states, which most of us developers are wont to do, since it's "easier" to implement.
Since statecharts are hierarchical graphs, there's also the possibility for automatically analyzing, optimizing, and generating full integration tests for user flows given a statechart spec.
I agree that trying to use statecharts everywhere is fitting a round peg into a square hole, but thinking about the UI in terms of states, and actions in terms of something that is simply emitted instead of something where application logic is stuffed into, will greatly improve how UIs are developed in the future.
Relevant must-read: https://www.amazon.com/Constructing-User-Interface-Statechar...
> the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
A statechart is simply a JSON structure. You still have to write the code for the figuring out what to do given the current state, and also code for triggering events. So it's still up to you to keep them away from anything frameworky.
> representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic.
Again, you'd still write linear code with statechart.
> your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
With statecharts your business logic is anywhere you want it to be. Statecharts add the idea of limiting you of calling only procedures that are allowed by the current state; meaning that if you are in state "Submitting form" and you call a `goToHomePage()` transition, nothing will happen if there's no such outgoing arrow.
This concept of "changing state only if the current state allows it" is quite powerful especially in the construction of UIs.
And when analyzing messy state diagrams, it’s not just the states we’re trying to visualize, but the lines connecting the states (the “edges” connecting the “nodes,” in graph-theory terms). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of states at a time.
It looks great in a slide deck, but it only works in trivial examples where you don't need it; it fails in complex environments where you need it the most.
Take a look at the “unclustering” section of the statecharts paper.
I've tried this approach before: the charts get complex fast, then your designers give up.
Typically you don’t need to refere to these diagrams and outputs very often, but they are useful for: - on boarding new people to the team - deep reasoning when debugging or analysing a problem - putting on the board during a design session
More importantly, statecharts limit your behavior - a specific state can only go into another state if there's an outgoing arrow. This limitation is quite awesome because, given any state, you know that the only thing effecting change are the transitions - nothing else!
Also I want to stress the importance of the unclustering property described in the paper. Your high-level statechart can be a simple diagram. Then you can "zoom in" and see the behavior of other portions of the diagram. This is quite powerful abstraction and I don't see how "just code" can solve this - especially because we're inherently visual creatures.
I also think zoom is a very powerful visual metaphor for context, and I don't mean to discount the value of that. I just think the contents of each node in the zoom-context graph could be higher-fidelity.
> More importantly, statecharts limit your behavior - a specific state can only go into another state if there's an outgoing arrow. This limitation is quite awesome because, given any state, you know that the only thing effecting change are the transitions - nothing else!
This touches on a point that I think is important and would like to expound upon.
One thing that makes code easier to reason about is "locality", being able to see everything that affects what you're looking at.
One way of dealing with poor locality in code is to zoom out until you're only looking at a web of state transitions, and then you can find the state you're in and see where you could have come from (which offers hints as to how you got there) and where you could go (which offers hints as to what might happen next).
Another approach is to write high-locality code, code which describes the incoming arrows so that by design, whatever you're looking at is already revealing its composition, and fractally-organized at that. That can be hard to do in application code with existing tools, although (shameless plug) I wrote libraries to help make it easier in Clojure and Javascript: https://github.com/notduncansmith/factfold
[1] https://en.wikipedia.org/wiki/SCXML [2] https://doc.qt.io/qt-5/qtscxml-overview.html [3] https://doc.qt.io/qtcreator/creator-scxml.html
1) State transitions are essentially "goto". Structured programming offers abstractions that are easier to think about and less fragile to requirement change. But in some situations small state machines can be a win.
2) Statecharts offer "structure" in the form of substates and superstates which are much like inheritance in OOP. In my experience these are fragile to requirement change.
3) Statecharts are advertised as being explicit and therefore easier to check for correctness. They can be, although if there are multiple state machines operating concurrently or even an "outside world" acting on them, the set of possible states is no longer explicit.
Apache Commons has an SCXML package which parses scxml statechart format (standard) and produces dynamic java objects but this couldn't see the daylight and suspended at version 0.9 in 2015.
I had nice experiences with this separation logic though. It is more flexible and extendable than regular finite state machines. There is parallelism and timeouts built-in the standard and as mentioned in the presentation, it solves a lot of if-else kinda structure without a hassle.
It’s honestly a better way to implement GUIs.
[1] http://www.esterel-technologies.com/products/scade-display/
So, a statechart formulation could be an 'emergent' , most simple way to formalize a Xerox Alto-descendant GUI system.
The fact that they start from an existing deep GUI stack is a bit distracting to the disucssion, though...
That said, here's an example from my own recent experience where formal statecharts/state machines became a necessity to even move forward.
My colleague published a finite state machine for swift (https://github.com/softwarenerd/Stately) that grew out of necessity from a project we worked on together.
The project (https://news.microsoft.com/videos/cities-unlocked-a-voyage-o...) was creating a turn by turn navigation system for the blind.
From a workflow perspective (and UI/UX) it was never terribly complex. There are a handful of primary actions, with a handful of intents and a single common workflow with branching outcomes. Over time and iterations, we reduced the workflow complexity quite a bit further as well.
But we kept having more and more functional regressions and exploding bug counts as more and more subsystems and capabilities were integrated into the experience. The issue was that, while workflow and UI were both simple, the number of potential application states exploded.
For a long period we used simple if/then logic, followed by tracking increasingly global variables to detect state conflicts/dependencies during flows. This was messy at best and became an unmanageable nightmare.
Enter the state-chart. We followed nearly the same process as you've outlined, with visual charts first. It gave us the initial frame to build a state machine from, followed soon after by sub-hierarchies. It worked well for us because the majority of our states were not many:many interdependent. Most states had a 1:1 or 1:few correlation with others.
Statecharts likely aren't the next big UI paradigm because most applications are driven by workflow (Line of Business apps) or by state machines that are already well-known (form validation, auth, network graph navigation, CRUD, etc) where those charts are already implicitly well handled by browsers, services or existing frameworks.
I think the magic area for statecharts is in applications with many independents or semi-linear state workflows that don't match up to visual or experiential interaction workflows.
In essence: Flowcharts do not inherently have a concept of waiting for something to happen.
More, this isn't to say these aren't worth looking at again. New and old things are always worth revisiting to see if something is different in the idea or the environment that we are in now.
That said, the UML world had several runs at diagrams that could do this. Activity diagrams being the more complicated ones, but what this is proposing seems to be the standard state machine diagrams.
It was not an unfounded (well, in my opinion) view that UML over complicated things. The problem appears to be that they were too complete in their modeling of the problems. And, these diagrams only really work in a "simple" sense if the viewers and the authors have a lot of shared context between them. The more of that context you put in the diagram, the more you will eventually remake UML's efforts. (Again, you will be in really smart company.)
The low barrier to entry of web apps is so great we can easily put up with the many downsides.