4 ms·

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

by panic 8y ago

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.

pure-awesome 8y ago
What about updating the specification before updating the UI?
- panic 8y ago
  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.
  - deanclatworthy 8y ago
    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.
    - gomox 8y ago
      Can you point to a successful commercial product built in this manner?
      - henrikeh 8y ago
        Not OP, but I’m not really getting what you are asking for?
        gomox 8y ago
        As in, a commercial software product where a specification is maintained in parallel with the actual product.
        henrikeh 8y ago
        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.
        gomox 8y ago
        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).
deanclatworthy 8y ago
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/e85b70fd4ec153e7a22137b6070f00ef 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.
codeulike 8y ago
This article seems to be more about navigation than it is about UI.
tomgp 8y ago
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.
- johnm 8y ago
  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. :-(
setr 8y ago
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

by panic 8y ago

pure-awesome 8y ago

What about updating the specification before updating the UI?

panic 8y ago
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.
- deanclatworthy 8y ago
  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.
  - gomox 8y ago
    Can you point to a successful commercial product built in this manner?
    - henrikeh 8y ago
      Not OP, but I’m not really getting what you are asking for?
      - gomox 8y ago
        As in, a commercial software product where a specification is maintained in parallel with the actual product.
        henrikeh 8y ago
        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.
        gomox 8y ago
        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).

deanclatworthy 8y ago

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

codeulike 8y ago

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

tomgp 8y ago

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.

johnm 8y ago
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. :-(

setr 8y ago

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