Formally Specifying UIs (2018)
hillelwayne.com
Formally Specifying UIs (2018)
1–10 of 47 posts
Re: Formally Specifying UIs (2018)
#2Is it just me or did the mention of nesting FSMs immediately raise red flags? All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies? Everything still gets complex.
That said, if HSCs aren’t the solution, what is- specifically to the authors problem of having overly many transitions to ‘home’ states?
Re: Formally Specifying UIs (2018)
#3I don't know, this doesn't make much sense to me. Usually you go from a set of specifications provided by a business analyst and then presuming you have a style guide and a 'widget library', the UX designer then 'formally' implements a prototype which can then be tested asap, tweaked ad-nauseam.
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.
Re: Formally Specifying UIs (2018)
#4I don't know, this doesn't make much sense to me. Usually you go from a set of specifications provided by a business analyst and then presuming you have a style guide and a 'widget library', the UX designer then 'formally' implements a prototype which can then be tested asap, tweaked ad-nauseam. 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…
I assume the "set of specifications" is normally provided via some sort of project tracking software like Jira. A problem with this is these specifications get lost in history, not to mention become outdated as the features evolve.
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.
Re: Formally Specifying UIs (2018)
#5Thinking of interfaces as state machines can be valuable.
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.
Re: Formally Specifying UIs (2018)
#6I recently read through “Designing the user interface with statecharts” by Horrocks. The arguments for are quite compelling, not just in terms of specifying, but also in terms of “designing”.
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.
Re: Formally Specifying UIs (2018)
#7This is a great article. I wish the author had mentioned the outsize importance of pleasantness to UI however. An absolutely terrible unusable UI can still be formally correct.
Re: Formally Specifying UIs (2018)
#8Is it just me or did the mention of nesting FSMs immediately raise red flags? All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies? Everything still gets complex. That said, if HSCs aren’t the solution, what is- specifically to the authors problem of having overly many transitions to ‘home’ states?
If your transitions don’t fit neatly into a hierarchy, you don’t have to use one -- just have a single complex state machine as per the author’s first example.
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.
Re: Formally Specifying UIs (2018)
#9I don't know, this doesn't make much sense to me. Usually you go from a set of specifications provided by a business analyst and then presuming you have a style guide and a 'widget library', the UX designer then 'formally' implements a prototype which can then be tested asap, tweaked ad-nauseam. 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…
I assume the "set of specifications" is normally provided via some sort of project tracking software like Jira. A problem with this is these specifications get lost in history, not to mention become outdated as the features evolve. 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.
Or the company switches to a new tracking tool and loses all the old data in the move.
Re: Formally Specifying UIs (2018)
#10Is it just me or did the mention of nesting FSMs immediately raise red flags? All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies? Everything still gets complex. That said, if HSCs aren’t the solution, what is- specifically to the authors problem of having overly many transitions to ‘home’ states?
> All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies
Yes, HSMs are very rigid. It's one of the few downsides (which I admit as a Harel state chart fanboy)[0]. 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.
[0] 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.