https://news.ycombinator.com/item?id=9879632
http://rauchg.com/2015/pure-ui/
blog-post-pure-ui#what-is-discovery Discovery is about the transformation (usually expansion) of that input. It's the evolution of the design. The uncovering of new states and new ideas throughout the process itself. blog-post-pure-ui#what-is-discovery
blog-post-pure-ui#discovery-in-implementation Another way in which discovery occurs, usually more painstakingly, is in the implementation process itself. blog-post-pure-ui#discovery-in-implementation
blog-post-pure-ui#problem-with-testing-ui-in-app1 In addition, getting to the particular payment form in this example could be the result of more branching. You must first be logged in, maybe under a certain type of user, of a certain role and specific privileges, with some pre-existing data in their profile. blog-post-pure-ui#problem-with-testing-ui-in-app1
blog-post-pure-ui#underestimating-size-of-state-space underestimating the size of the state space is actually very easy blog-post-pure-ui#underestimating-size-of-state-space
There is a story about an engineer who allowed Steve Jobs to change everything in the design of the Mac's calculator with pulldown menus here: blog-post-calculator-construction-set, although it's less about state discovery than aesthetic discovery, it's still a similar concept.
I still have a problem with code like this:
function videoplayer({ title, src } = {}){
if (src) {
return div(
div({ 'class': 'title' }, title),
video({ autoplay: true, loop: true, src })
);
} else {
return div('No video to load');
}
}
I think my problem is that it is not really a logicless-template, which would allow us to reason about UI complexity outside of the DOM elements it creates. For example, how would you write an executable specification for it? Your specification would have to test against actual generated HTML elements as opposed to simple, semantically relevant concepts like should_show_video. The trouble with coding it this way, as things get more complicated, is that you lose the connections to the initial requirement.
I like the blog post's idea of having an easy-to-use fuzzing framework for the process of discovery, however once you have the enumerated the states, simply locking in the name-value pairs of parameters isn't enough to capture the intent (and to ensure that future changes to the code don't cause regressions). The article says "underestimating the size of the state space is actually very easy", which is true. If you actually have 20 different states for the video player, I'd argue that you need to capture the intent of those states because otherwise you will certainly break them because you won't want to revisit all of them each and every time you make a change.