
Formally Specifying UIs (2018) - meistro
https://www.hillelwayne.com/post/formally-specifying-uis/
======
henrikeh
I 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.

~~~
DennisP
Thanks, ordered it. For those having trouble searching like I did, it appears
the correct title is _Constructing_ not _Designing_.

[https://www.amazon.com/Constructing-User-Interface-
Statechar...](https://www.amazon.com/Constructing-User-Interface-Statecharts-
Horrocks/dp/0201342782)

~~~
henrikeh
You are right. That is the title :-)

------
austincheney
I am not a big fan of pseudo code unless:

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.

------
wtroughton
Thinking 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.

------
panic
I'm a fan of formal methods in general, but I'm not sure they're a good fit
for UI specification. Building user interfaces is all about flexibility—you
need to be able to change the UI as you discover what works and what doesn't.
A rigid, pre-specified UI is almost always a bad UI.

~~~
tomgp
I think there's something in this. Reading through the OP the "some of the
mistakes we made" section struck me -- with a suitably plastic UI framework
these would all be trivial to solve (simple paper prototyping would have shown
some of these up right off the bat). The best-guess -> test-with-real-user ->
iterate approach seems likely to be cheaper (in terms of effort) and more
likely yield an interface that users want to use and as such one with which
they are more easily able to achieve their aims.

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.

~~~
johnm
Hahaha! You must be working with folks (pm, dev, qa) that do a lot more than
just hack away. Or perhaps I've just been working too much lately with big
enterprises. :-(

------
actionshrimp
One interesting thing about the various elm-like React reducer
patterns/libraries is that you essentially end up writing a state machine
anyway. ReasonML's react bindings have a reducer component available out of
the box, making it easy to write a 'pure' state machine and then wire it up to
the UI via a React shell.

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...](https://medium.com/imandra/constraint-solving-your-
uis-8933f4cf8927)) or formally proving properties about the state machine
([https://medium.com/imandra/verifying-reasonreact-
component-l...](https://medium.com/imandra/verifying-reasonreact-component-
logic-reasonml-imandra-e350d4812a9f)), 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.

~~~
bluetech
React has a built-in useReducer hook now as well:
[https://reactjs.org/docs/hooks-
reference.html#usereducer](https://reactjs.org/docs/hooks-
reference.html#usereducer)

------
keyle
I 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.

~~~
kumaraman
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.

~~~
lazyasciiart
Or the company switches to a new tracking tool and loses all the old data in
the move.

------
Risord
Creator of Sketch.systems Kevin Lynagh was interviewed in Future of Coding
podcast while ago:
[https://futureofcoding.org/episodes/025.html](https://futureofcoding.org/episodes/025.html)

Great podcast overall.

------
aargh_aargh
A random idea. Yesterday I opened The Gyllenhaal Experimet article on HN and
noticed the chart that displays the tree of options and the number of people
who took each path. It's the first chart here:

[https://pudding.cool/2019/02/gyllenhaal/](https://pudding.cool/2019/02/gyllenhaal/)

(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.

~~~
ves
It’s often called a sankey chart.

~~~
aaronharnly
Yes, what ves said. Read the Wikipedia article to see the first known Sankey
chart (which actually predated Sankey), Minard’s famous diagram of Napoleon’s
campaign in Russia.

[https://en.wikipedia.org/wiki/Sankey_diagram](https://en.wikipedia.org/wiki/Sankey_diagram)

------
la_fayette
The look and feel of a UI is what is basically called a "non-functional"
requirement. Altough this approach seems really helpful in specifying the app
flow i think the small details which customers pay for, cannot be represented
with this approach. Additionally, most customers I worked for might not
understand these charts. Personally, I think tools like screenshots, click
dummys or wireframes are more successful when specifying UIs for a customer.
As a specification for a web designer it is helpful for sure...

~~~
DaiPlusPlus
A wireframe or click-through demo that pleases the client is not necessarily
the best UI. (And the Best Customers are self-aware enough to know the
Customer is not Always Right). Clients would gravitate towards that whichever
impresses them personally - often by prior efforts made by competitors - but
what looks snazzy and impressive often makes for a poor UX - consider the
flashy CIA/FBI/LCARS UIs made for television and Hollywood, for example.

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.

------
dyarosla
Is 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?

~~~
_pmf_
> 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.

~~~
dyarosla
Could you link to some examples of events in HSCs/FSMs?

------
fxfan
Tangential but the good looking page and dot-rendered gv don't quite go
together. Is there any "beautiful" and cleaner by default gv rendering engine
(I know 'cleanness' is an intractable problem for large graphs but this is a
very small one)

What I'd like by default:

1) Borders and margins

2) Better colors

3) Decent font

------
Robin_Message
Just thinking, I bet you could have a top level component (in React say)
implement a state chart. Then the spec is the code, which is always nice. You
might want parameterised states though (i.e. list into detail view) I wonder
if that's a thing.

------
bsaul
A bit of a sidenote but FSM for UI is a reason why algebraic data types
systems like swift with its powerful enum is so valuable.

~~~
arianvanp
Basically the whole premise of [https://elm-lang.org](https://elm-lang.org)

~~~
ken
As a Smug Lisp Weenie myself, I'm glad that users of other languages are
finally getting into the habit of posting "my programming language does that!"
on every thread. That's one Lisp feature I thought might never be copied!

------
tenaciousDaniel
Wow, I'm actually working on something that is eerily similar to this. Worried
about competitors, haha, but glad to see that other people in the industry are
leaning in the same direction.

He's 100% right to conceive of interfaces as a finite state machine.

------
miki123211
+1 for including sources for all graphs. Great for accessibility. Images are
not enough for some people, and it's nice you recognize that.

------
User23
This 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.

------
codeulike
Oh I see, Formal Methods are what we now call 'planning ahead' now that Agile
has made planning ahead unfashionable.

