Thought this was really neat. I’ve often thought that formal methods would be super handy on the front end, and likewise, I’ve also thought that formal methods folks could also learn a ton from UI folks. Great to see some work done towards bridging the gap!
One of the killer features of the Alloy specification language is that Daniel Jackson deeply cares about UIs. It makes using the IDE way more pleasant than any comparable FM.
I previously submitted this work that applied formal methods to GUI. It’s more complex but integrates with Spin. The visual formalism in this article reminded me of what Tersus looked like years ago when I looked at it. I’m not sure what it looks like now.
This looks awesome! I’m definitely going to try to start using this.
A big workflow problem I’ve noticed when talking to management and designers at my day job is that the mocks/specs that I’m handed are often under-specified. This looks like a great way to collaboratively reason about edge cases in the design and also break down the wall between how the designer sees an interface (as well-defined happy case workflows) and how I end up implementing it (having to make judgment calls about what should happen if something goes awry).
I’ve run into that same issue with designers many times, at different jobs. While being very careful of making generalisations, thinking past the pixels (and the happy-case workflows) seems to be a problem for a lot of UI designers (many of whom have backgrounds in traditional/static design, and who now like to call themselves UX designers, too).
The handful I’ve encountered who can do both the design work and think in terms of workflows and states have been very good to work with.
Thought this was really neat. I’ve often thought that formal methods would be super handy on the front end, and likewise, I’ve also thought that formal methods folks could also learn a ton from UI folks. Great to see some work done towards bridging the gap!
One of the killer features of the Alloy specification language is that Daniel Jackson deeply cares about UIs. It makes using the IDE way more pleasant than any comparable FM.
I previously submitted this work that applied formal methods to GUI. It’s more complex but integrates with Spin. The visual formalism in this article reminded me of what Tersus looked like years ago when I looked at it. I’m not sure what it looks like now.
I got to give alpha feedback on this! Kevin is a great guy.
I might also be working on a longer worked example of using this, which I’m hoping on posting in a couple of weeks.
Very cool! This looks like an very nice interactive tool that makes state charts - we need more things like this in the world!
It would be very cool if it output Formal methods specs that could be run independently.
This looks awesome! I’m definitely going to try to start using this.
A big workflow problem I’ve noticed when talking to management and designers at my day job is that the mocks/specs that I’m handed are often under-specified. This looks like a great way to collaboratively reason about edge cases in the design and also break down the wall between how the designer sees an interface (as well-defined happy case workflows) and how I end up implementing it (having to make judgment calls about what should happen if something goes awry).
I’ve run into that same issue with designers many times, at different jobs. While being very careful of making generalisations, thinking past the pixels (and the happy-case workflows) seems to be a problem for a lot of UI designers (many of whom have backgrounds in traditional/static design, and who now like to call themselves UX designers, too).
The handful I’ve encountered who can do both the design work and think in terms of workflows and states have been very good to work with.
This looks awesome in terms of helping to hammer out specs.