automating design mocks (part 2)

Ok, so we have a widget that lets us vary the properties of a given mock, either one at a time or all ganged up.

How do we change its parameters without devolving into a crazy ui devoted only to tweaking the parameters of a mock? what do we need to know?

• some parameters are continuous (i.e. font size, position, color) while others are discrete (i.e. enum values)
• some values are just truthy (i.e. dark mode vs light mode).
• some are meta-parameters (configurations)

there’s some good examples, ken ferry’s tunable spec, for example, has some nice mechanisms for the first two. that’s not such a bad starting place. if we do that, but on the web, we end up with something like this

ken ferry, i am totally ripping you off

and that’s not so bad. it’s at least a good start (but i mean, aren’t we really just back at mid 90s dhtml) except with react and native range inputs?

This tunable widget look something like this:

<Tunable>
  <SearchThumb image=”func.png” title=”oh hi” />
</Tunable>

This time i am using React’s children to do this and you could imagine the implementation looking something like the following:

Tunable = React.createClass({
render:function(){
  this.props.children.map(function(child){
    var newProps = this.state.newProps;
    return(
      <div>
        <div>{React.cloneElement(child)}</div>);
        <div>{child.type.propTypes.map(this.renderTunable)}</div>
      </div>
  });
},
renderTunable: function(prop){
  switch(prop){
    case React.PropTypes.Number:
    // something to make a ranged input
    break;
    case React.PropTypes.oneOf....
    // render a select
    break;
  }
}
})

or something along those lines. The implementation isn’t so important as you can sort of imagine all the attendant problems. Instead, what are we missing here that we can’t get from PropTypes?

• numerical ranges! we just have no idea what the acceptable values for a given Number might be, so we need to pass that into Tunable somehow.
• are strings meaningful or decorative? i.e. is this something that our library can populate with lorem ipsum, or is it something that refers to, say, a url (is the url an image? placekitten?).
• which propTypes are actually worth tweaking, which need to be pinned, which can be randomized, and which optional ones should be visible for (or are relevant to) this mock.
• is there some existing configuration for this mock? many components vary their apperance based on props: does that configuration include the variable props or just the baseline state for the component.

<Tunable spec={someSpec}>
  <Component {...widgetConfigAlpha} />
</Tunable>

where widgetConfigAlpha refers to that widget’s baseline configuration (are those the pinned values?) and where someSpec is something like

someSpec = {
  title: {type: React.PropTypes.string, kind: "free"},
  image: {type: React.PropTypes.string, kind: "image"},
  size: {type: React.PropTypes.number, min: 2, max: 20}
}

What can we fix about that earlier gif?

1. we can make the editable menu available via a context click
2. actually, if we’re rendering many children at once (which we should) then this is preferable to taking up screen real estate for scrubbers
3. we can make the editable menu available to all components by default
4. we can make values pinnable
5. we can disable subsequent edits of the mocks

something higher level though:

• why shouldn’t the range parameters be a tunable value itself? for instance: the component is rendering an object (or many objects) with range inputs, is the prototype easier to deal with if you remove min/max but add parameterize min/max through the prototype ui?

someSpec = {
  ...
  size: {type: React.PropTypes.number, kind: "range"}
  ...
}

• if we do have a high level ui for tweaking all individual component properties, this high level ui can include ‘randomize’ buttons for each field.
• in this high level ui, you can imagine instead of a randomize button, two things: an api url and a jq selector for the relevant data you want that makes this field interesting. instead of ‘shuffle’ you might hit ‘sample’ and populate the components from values you find that field.
• if you’re using real data now, you’re going to run into an interesting problem: api values go together. In the beginning truly random parameter fuzzing is ok, but eventually, we want to have a title and an image be related as per an api response, and we want those to be sampled randomly from our dataset/api.

ok, that’s enough for part 2. part 3, i’ll talk about the ui and discoveries from these last high level thoughts.