Hacker News Reader

Comment by panic | Hacker News Reader

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.

View on HN

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.

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

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

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

Reply on news.ycombinator.com