11 ms·
Formally Specifying UIs (2018)
- dyarosla 8y agoIs 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?
- iainmerrick 8y agoIf 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.
- _pmf_ 8y ago> 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 8y agoCould you link to some examples of events in HSCs/FSMs?
- keyle 8y agoI 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 8y agoI 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 8y agoOr the company switches to a new tracking tool and loses all the old data in the move.
- wtroughton 8y agoThinking 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.
- henrikeh 8y agoI 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.
- mukeshsoni 8y agoHere's an implementation of the calculator in javascript using xstate - https://github.com/mukeshsoni/statechart-calculator https://github.com/mukeshsoni/statechart-calculator
- platz 8y agogreat comments on statecharts previously here https://news.ycombinator.com/item?id=15835005 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=15835482 https://news.ycombinator.com/item?id=15835666 https://news.ycombinator.com/item?id=15835666
- DennisP 8y agoThanks, 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-Statecharts-Horrocks/dp/0201342782 https://www.amazon.com/Constructing-User-Interface-Statechar...
- 8y ago
- User23 8y agoThis 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.
- panic 8y agoI'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.
- pure-awesome 8y agoWhat about updating the specification before updating the UI?
- panic 8y agoThe 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.
- deanclatworthy 8y agoI 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.
- Risord 8y agoCreator 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.
- Robin_Message 8y agoJust 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.
- austincheney 8y agoI 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.
- bsaul 8y agoA 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 8y agoBasically the whole premise of https://elm-lang.org https://elm-lang.org
- ken 8y agoAs 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!
- aargh_aargh 8y agoA 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 8y agoIt’s often called a sankey chart.
- aaronharnly 8y agoYes, 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
- fxfan 8y agoTangential 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
- codeulike 8y agoOh I see, Formal Methods are what we now call 'planning ahead' now that Agile has made planning ahead unfashionable.
- deleted 8y ago[deleted]
- la_fayette 8y agoThe 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 8y agoA 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.
- miki123211 8y ago+1 for including sources for all graphs. Great for accessibility. Images are not enough for some people, and it's nice you recognize that.
- actionshrimp 8y agoOne 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-8933f4cf8927 https://medium.com/imandra/constraint-solving-your-uis-8933f...) or formally proving properties about the state machine (https://medium.com/imandra/verifying-reasonreact-component-logic-reasonml-imandra-e350d4812a9f 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.
- bluetech 8y agoReact 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
- tenaciousDaniel 8y agoWow, 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.