Formally Specifying UIs (2018) • Hacker News Board

Re: Formally Specifying UIs (2018)

#41

Post by actionshrimp » Thu, Feb 28, 2019, 1:18 PM UTC

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.

Re: Formally Specifying UIs (2018)

#42

Post by henrikeh » Thu, Feb 28, 2019, 1:56 PM UTC

DennisP wrote: post #39

henrikeh wrote: post #6

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…

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

Re: Formally Specifying UIs (2018)

#43

Post by bluetech » Thu, Feb 28, 2019, 1:57 PM UTC

actionshrimp wrote: post #41

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 particu…

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

Re: Formally Specifying UIs (2018)

#44

Post by tenaciousDaniel » Thu, Feb 28, 2019, 5:49 PM UTC

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.

Re: Formally Specifying UIs (2018)

#45

Post by setr » Thu, Feb 28, 2019, 5:55 PM UTC

panic wrote: post #12

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.

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

Re: Formally Specifying UIs (2018)

#46

Post by johnm » Thu, Feb 28, 2019, 6:20 PM UTC

tomgp wrote: post #30

panic wrote: post #12

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.

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 w…

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

Re: Formally Specifying UIs (2018)

#47

Post by dyarosla » Fri, Mar 01, 2019, 2:08 AM UTC

_pmf_ wrote: post #10

dyarosla wrote: post #2

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?

> 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 everyth…

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