Boxes and Arrows: Comments by Eric Scheid

Eric Scheid — Wed, 04 Apr 2007 18:18:19 GMT

I’m disliking the reputation points thing for a couple of reasons: it’s bulky on the page, it’s difficult to compare while scanning, and revealing actual numbers usually results in distorted voting behaviour.

Might I suggest some kind of sparkline thing instead? Less visual impact, you can’t read the exact value, easier to compare amongst multiple instances, and (my favourite) you can see a history (are they trending upwards, do they swing up and down, have they been absent/ignored for a long time). Hmmm, the more I think of it, a sparkline inspired by stock market buy/sell graphs would be nice :-)

Eric Scheid — Fri, 06 Apr 2007 17:36:06 GMT

First, decide on what basis you determine your satisfaction level regarding remuneration: is it as compared to others (where if you are getting less than others for doing the same work would make you unhappy), or is it according to the quantity of money it will take to make you fat and happy?

The way I work is I figured out how much time I want to put into working (actually, I first figured out how much free time I wanted), and how much money I wanted available to spend. So, “underpaid” to me means I’m not making enough according to my goals, and I’d be looking for ways to improve that situation.

Eric Scheid — Mon, 24 Sep 2007 14:27:37 GMT

Something else to remember about encouraging the flourishing of disconnected sub-networks is that innovation and evolution is more likely to occur at the edges, in the isolated enclaves, away from the big groups and their pressure to conform. Once a group moves into the “giant component” then subtle forces come into play which eventually results in stagnation and decay … and then the only way the giant component can ever stay alive is by constantly devouring the fresh blood of disconnected sub-networks.

Eric Scheid — Mon, 30 Jan 2012 12:35:39 GMT

“Directing [devs] to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe” ... this part alarms me and is the crux of where things could go wrong.

As contrast: In a recent project we designed over 80 design patterns (and no fluff ones like “Radio Button”). These were only lightweight specced which we then took to devs and did some agile rapid prototyping iterations and refining of the specs before they went off and produced code modules. Importantly, this was a special dev team set aside to produce code libraries which the app devs would go on to use.

Note too that we didn’t just hand over all our wireframes and ask the devs to find patterns to code. We did consistency reviews and peer reviews of our wireframes (a necessary process in any case) and out of that process we identified the design patterns we were using. This process also encouraged us to refine and coalesce the design pattern definitions, removing some idiosyncrasies. If we didnt remove those idiosyncrasies but simply handed the wiredecks to devs to codify the apparent patterns they would of course had to code all those warts in too.

Another outcome of the UX design review and pattern definition process is that we actively participated in some uncomfortable discussions which exposed some differing assumptions about the UX vision we were theoretically hewing to. We refined the UX vision, and captured those findings into the pattern definitions as well.