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

21–30 of 47 posts

Re: Formally Specifying UIs (2018)

#21

Post by gomox »

deanclatworthy wrote: post #20
panic wrote: post #16

Earlier quoted context omitted.

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.

Can you point to a successful commercial product built in this manner?

Re: Formally Specifying UIs (2018)

#22

Post by aargh_aargh »

A 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/

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

Re: Formally Specifying UIs (2018)

#23

Post by ves »

aargh_aargh wrote: post #22

A 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/ (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…

It’s often called a sankey chart.

Re: Formally Specifying UIs (2018)

#24

Post by fxfan »

Tangential 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

Re: Formally Specifying UIs (2018)

#26

Post by codeulike »

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.

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

Re: Formally Specifying UIs (2018)

#27

Post by henrikeh »

gomox wrote: post #21
deanclatworthy wrote: post #20

Earlier quoted context omitted.

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?

Re: Formally Specifying UIs (2018)

#29

Post by gomox »

henrikeh wrote: post #27
gomox wrote: post #21

Earlier quoted context omitted.

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.

Re: Formally Specifying UIs (2018)

#30

Post by tomgp »

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.

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.

Post reply on HN