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

31–40 of 47 posts

Re: Formally Specifying UIs (2018)

#31

Post by aaronharnly »

ves wrote: post #23
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.

Yes, 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

Re: Formally Specifying UIs (2018)

#32

Post by henrikeh »

gomox wrote: post #29
henrikeh wrote: post #27

Earlier quoted context omitted.

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.

Re: Formally Specifying UIs (2018)

#33

Post by gomox »

henrikeh wrote: post #32
gomox wrote: post #29

Earlier quoted context omitted.

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

Re: Formally Specifying UIs (2018)

#34

Post by la_fayette »

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

Re: Formally Specifying UIs (2018)

#35

Post by DaiPlusPlus »

la_fayette wrote: post #34

The 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 whe…

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

Re: Formally Specifying UIs (2018)

#38

Post by platz »

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…

great comments on statecharts previously here 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=15835666

Re: Formally Specifying UIs (2018)

#39

Post by DennisP »

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…

Thanks, 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-Statechar...

Re: Formally Specifying UIs (2018)

#40

Post by ken »

arianvanp wrote: post #37
bsaul wrote: post #18

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

Basically the whole premise of https://elm-lang.org

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