Formally Specifying UIs (2018) | Hacker News Reader

Formally Specifying UIs (2018)

hillelwayne.com

307 pointsmeistro45 comments

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.

Here's an implementation of the calculator in javascript using xstate - https://github.com/mukeshsoni/statechart-calculator

great comments on statecharts previously here https://news.ycombinator.com/item?id=15835005

the top few comments i find compellingly skeptical.

https://news.ycombinator.com/item?id=15835482

https://news.ycombinator.com/item?id=15835666

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

You are right. That is the title :-)

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.

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.

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.

What about updating the specification before updating the UI?

The more work you have to do to change anything in the UI, the more improvements you end up saying "no" to. Great UIs typically get that way via an enormous number of tweaks and improvements (both small and large) at every stage of the design and implementation process.

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.

I understand what you are saying but I don't agree. As I wrote in a parent comment, should you want to change one thing, adjust the specification with the developers, agree with the stakeholders, implement. Done. This is just a spec to follow and reference.

Can you point to a successful commercial product built in this manner?

Not OP, but I’m not really getting what you are asking for?

As in, a commercial software product where a specification is maintained in parallel with the actual product.

Since you say “commercial” software I’m confused. Would that exclude medical software, aerospace software?

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.

I wouldn't exclude anything, but if the only examples of this are those kinds of highly immutable, mission critical software I think that would speak volumes about the practicality of maintaining a spec (the approach OP was pitching).

At least to my eyes, this looks like an incredibly flexible way of creating a formal definition of the state of all UI components and the corresponding flows between the screens/components.

https://sketch.systems/rgraves-aspiration/sketch/e85b70fd4ec...

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.

This article seems to be more about navigation than it is about UI.

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.

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

At some point, the UI should settle down though. It’s not like you’re completely redesigning it every few months; most GUI applications I use don’t even see significant UI changes unless its a major version update (and usually a new fee..)

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

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

React has a built-in useReducer hook now as well: https://reactjs.org/docs/hooks-reference.html#usereducer

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.

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.

Creator of Sketch.systems Kevin Lynagh was interviewed in Future of Coding podcast while ago: https://futureofcoding.org/episodes/025.html

Great podcast overall.

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/

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

It’s often called a sankey chart.

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

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

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.

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?

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.

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

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

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

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.

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.

Basically the whole premise of https://elm-lang.org

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!

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.

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

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.

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

Reply on news.ycombinator.com