Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formally Specifying UIs (2018)

hillelwayne.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Formally Specifying UIs (2018)

#11

Post by mukeshsoni »

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…

Here's an implementation of the calculator in javascript using xstate - https://github.com/mukeshsoni/statechart-calculator

Re: Formally Specifying UIs (2018)

#12

Post by panic »

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.

Re: Formally Specifying UIs (2018)

#14

Post by pure-awesome »

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.

What about updating the specification before updating the UI?

Re: Formally Specifying UIs (2018)

#15

Post by Robin_Message »

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

Re: Formally Specifying UIs (2018)

#16

Post by panic »

pure-awesome wrote: post #14
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.

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.

Re: Formally Specifying UIs (2018)

#17

Post by austincheney »

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

Re: Formally Specifying UIs (2018)

#19

Post by deanclatworthy »

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

Re: Formally Specifying UIs (2018)

#20

Post by deanclatworthy »

panic wrote: post #16
pure-awesome wrote: post #14

Earlier quoted context omitted.

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…

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.
Post reply on HN