kip/bot/blog

While Apple’s ascendancy to #1 most valuable company in the world is still fresh in our minds (though no longer true, for the moment), a revisiting of the importance of design in that company’s comeback from bankruptcy. It’s often used, but worth remembering how broadly Jobs define design:

“The thing that all of our competitors are missing is that they think [design]’s about fashion, they think it’s about surface appearance,” Jobs complained to me once. “And they couldn’t be further from the truth. The iMac isn’t about candy-colored computers. The iMac is about making a computer that is really quiet, that doesn’t need a fan, that wakes up in fifteen seconds, that has the best sound system in a consumer computer, a superfine display. It’s about a complete computer that expresses it on the outside as well. And [competitors] just see the outside. They say, ‘We’ll slap some color on this piece of junk computer, and we’ll have one, too.’ And they miss the point.” At a later interview, talking about the first iBook, which had a rubbery satchellike clamshell case, he argued that the very inclusion of a built-in handle had been an exercise in style. “Is that design?” he said of the handle. “I think it is. It’s not just about looking good, it’s about the use of the product. Not having a latch, is that design? Yeah, we think it’s design. The rubber on the product, is that design? Yes. It affects how the product looks and how you feel about the product, but it’s also incredibly functional if you happen to set it down too hard.”

Levy, Steven (2006). The Perfect Thing (pp. 131-132). Simon & Schuster. Kindle Edition.

Via @gadgetboy

Below is a @GigaOM tour of Leo Laporte’s TWiT studio, in progress. All sorts of interesting tidbits for how smart digital allows smaller operations to make high quality content. Simple things he did:

Moving beyond the laptop, camera and go formulation, this creates a whole new middle space for studio production.

I’ve never been a Microsoft hater. In fact, given how many needs of how many people MSFT software has had to support, I’ve always rather admired their audacity and even the boldness of their vision. Think about it: they write software that will run on machines built by hundreds of manufacturers, to be used for thousands of purposes, and with a high level of backward compatibility for its operating systems. Apple, whose products I typically use, simplifies their work greatly by: writing software only for hardware they control, forcing users to abandon software written for earlier operating systems (or switch between operating systems to use older programs), and, as a matter of strategy, offer a smaller set of features and openness to their products. Again, I still use Apple products and choose Apple when I have a choice at work, but give it up to MSFT for trying to meet all those needs.

So, today, ReadWriteWeb runs a great story about the persistent popularity of Microsoft Office. With so many alternatives out there — Open Office, Quick Office, Google — enterprises still choose Office. Why?

As easy as it may sometimes be to dislike Office, it’s hard to deny that it has a pretty robust feature set. For as good as Web-based tools like Google Docs are, they only do a portion of what Office does. And while they accomplish the majority of commonly-needed tasks quite well and benefit from being based in the cloud, this is still not enough for many businesses.

Chris Bernard, a User Experience Evangelist for Microsoft gave a great talk several years ago, in which he explained the design problems unique to a company with as large an installed user base as Microsoft. One of the things people criticize Microsoft for is the feature bloat of Office and the pain-in-the-neck menuing system. Fair enough, said Bernard. But, he continued, keep in mind that many of the features that some individuals don’t use are mission critical for a small percentage of other users. For Microsoft, a small percentage represents tens of millions of users — so what are they to do? There’s no simple design solution for a product that is used by hundreds of millions of people for professional as well as personal reasons.

This revelation came to me when I was in grad school in 1998. I was taking a Mathematical Economics course and I was thrilled to discover that Word had a very robust Equation Editor module:


For most users, even for me (once I was done with that class), this feature is a distraction, something you train your eye to ignore if you’re looking for something else. But during that period of time when I needed it . . . it was killer.

It will be interesting to see what happens as Google apps and Apple’s productivity suite has to scale beyond the comparatively small markets they’re currently in. How will they manage the accretion of features to avoid bloat and confusion? I’m not sure it’s all that easy.

As a kid, I wanted to be Woodward and Bernstein (both of them, yes). I could barely tell you what Watergate was about, or where they followed the money to, but I read the book in my tent in the backyard at age 10 and was absorbed – by their investigative intensity, the puzzle-solving, the clever interview techniques, the big journalistic personalities. The movie got me into the book and I recently rented it. What great production design, and how interesting to see all the pre-chip technologies at play (and the use of which advances the story, one of the most amazing things about the movie is the drama they brought to interviews, phone calls, phone book searches). Anyway, some fun screenshots:

a photocopy of a typed phone list(!):

typewriters:

phones that were heavy enough to be murder weapons in other shows but, for this movie, where you screw off the voice piece to listen in instead of hitting mute:

UHF and VHF for close to 15 stations accessed with knobs that turn:

handwriting(!):

if it weren’t for the thumbtacks, and the fact that Robert Redford would never do requirements gathering, I might think this was a card sort:

before people just threw them out, there was a time when there were rooms full of phone books:

and, sadly, one last thing lost to that era: the bad-ass newspaperman who still thrills to a story, cares about the free press, and totally kicks ass:

I love this commercial:

A few days ago, I posted some critical comments about the data visualization techniques used in an iPad app. The designer responded (the links can be found in the post) and it highlighted some larger design issues.

There is no longer a dichotomy of stats-people and civilians. Everyone is surrounded by data and everyone is increasingly using data and, with it, data visualization. The commercial above highlights this amusingly, Steven Johnson writes about it in Everything Bad is Good for You, and newspapers and TV news outlets are building teams to define that new literacy.

All info-graphics and data visualizations have the same standards: to bring meaning to the data or turn that data into a story. While the goal of the content may change and the technical proficiency of the audiences may vary, those two standards apply universally. New info-graphic techniques should improve the meaning or the story-telling ability of earlier techniques. When we replace an efficient, clear, easy-to-scan table with a map containing blobs, there needs to be an improvement in either or both of those criteria.

Tufte is not a statistician’s statistician, he’s more the Orwell of the data-literate age. Having referenced Tufte in my earlier post, I got hit with a lot of comments about ivory tower, academic approaches, and statistical wonkiness. The truth is, Tufte studies a whole range of data visualizations from restaurant menus to ballots to subway maps to train time tables to sun spot charts. Throughout his writing, he rails, like Orwell, against data treatment that obscures meaning, muddles thought, or deliberately distorts. For Tufte, and you see this most clearly in his analysis of the Space Shuttle disaster, there’s an ethical responsibility to be clear and accessible to as broad an audience as possible.

Anyway, I just love that commercial. It shows as clearly as anything that people love richness, complexity, and depth in their content.

Note: The app’s designer, coder, all-around maker, responded in his blog. Some additional comments, responses to this post, in a later post.

I just downloaded the Pennant iPad app. While connected to the internet, this app lets you look at every play of every game of professional baseball going back to 1951. It’s gotten glowing reviews from Wired and other places with praise for its “rich interface” and all the fun they bring to stats. I was stoked to buy it — I like reading about baseball more than watching it, I loves me my data, and I was genuinely happy with the Jazz app, which has a similar visual language and navigation tropes.

Sadly, Pennant is just prettied up data, prettied up so much that it underperforms the highly evolved system of box scores and the recent and insufficiently explored sparklines of Edward Tufte. It’s also loaded with some bad usability posing as visualization.

The first problem comes with the app designers’ attachment to cover flow. I’ve never been a big fan of cover flow, finding it imprecise for task completion, and way too low in information density for exploration of anything larger than 20 items. In Pennant, it’s a real waste of space and a strange distortion of a timeline.

The colors are meaningless and confusing, the covers themselves add nothing to the exploration (might be nice to have the jerseys to differentiate between the different iterations of the Giants, or some basic information about team founding, league, or notable players — anything beyond text to justify a visual treatment). Worse, they don’t even show enough items, requiring extra work to get around. While I dislike it, at least the iTunes version previews information and provides more:

The cover flow fixation obscures the drill-downs in the experience as well. This is a screenshot of the 1981 Pirates season:

The real information is the line across the bottom of the screen, but the cover, which simply confirms the user’s choice and serves as an over-sized title, dominates. The line across the bottom of the screen is also problematic — the individual data points are hard to pinpoint, as an adult fingertip can actually touch three at a time and the finger obscures your sight line. (It’s also a repetition of the cover flow above, but with the added, and admittedly useful though inefficiently executed, depiction of the average.)

This disregard for information and usefulness is pretty much the problem with the whole app. At a brisker pace, some screenshots and critiques:

Maps are possibly the most abused data visualization techniques out there. To make room for the map, you have to shrink the actual data (team names) to pin points. And for what? Spatial relationships? For this particular data set, maps actually create confusion – if you don’t remember that a team moved, or simply want to find the team name in that cluster of points in the northeast, or you don’t really consider the renaming of the Angels as different teams in the same way you think of the Brooklyn Dodger and LA Dodgers as being different.

This is the one that most people praise. It sure looks nifty, and you need code to draw it and do the transition, but why a circle? Usually the stats are listed in proximity and tell a quick story, and are clumped in ways that tell interesting stories. Here, all you have are wedges next to each other, forcing you to spatially assess the relative stats. Worse, they’ve got cumulative stats (number of walks, hits, runs) intermixed with percentage stats (OBP and AVG). Worse than useless, this actually reduces the clarity and usefulness of the data. (The pitching one is a drag too. A standard measure is strike out to walk ratios and you don’t even have the numbers and the shapes that might make for comparison are on opposite sides of the wheel.)

The most difficult thing about the screen is that, at its core, it’s a pie graph. There is a set of wedges indicating some proportional relationship with the other items, further implying that how far out it radiates is an extra dimension. None of these implied relationships, basic knowledge for an adult reader, is delivered on, thus frustrating user expectations.

Quick hit here: the win loss line on the bottom is hard to access (see adult finger stuff above) and the representation makes the Loss look like half of a Win, not the opposite. Compare to a Tuftean style presentation:

Here, the color pops for winning and losing streaks, and you get a sense of home and away performance. And, oh yeah, you have summary data at the end of the line.

I have no idea what they were thinking with this one. And, yes, you can move the bubbles around – and get absolutely nothing out of it.

The most annoying of all. This is the meat of the experience, the play-by-play, the true fan’s recreation of the great moments in baseball. Why a circle? Is there something full-circle about the game? What happens to the already maddening smallness of the lines when you go into extra innings? The metaphor dominates at the expense of the information and the narrative.

It gets weirder when you set it to play:

The weirdness comes in a couple places. First, all of the lines from the earlier screen are made the same length when it turns into a wheel. All you have now is the number of at bats and a preview that the last out is happening. The second is that, by ticking off the plays individually, you actually lose the narrative that would come with the list. In this case, Gary Carter tripled, but there’s no context – how many men on base, how many outs, what’s the score, how long has the pitcher been in? These are the moments that make individual plays dramatic. But, by putting the display at the service of the interface metaphor, the events are reported with no context and no outcome (which a list of plays would have allowed the user to put together, and which newspaper scorecards fill in).
Enough of the hating. A quick note about how good infographics are pleasing to the eye, engage you in conversation and add to the story the data tells.

Tufte shows cleaner, higher-resolution versions in his book, but I chose the larger, jaggier one to highlight the point. This graphic shows the pattern of a teams season, it visualizes, surges and slumps, shows tight races, conveys the hopelessness of being a fan for some teams and it has data.

Pennant is mostly chartjunk. Sad, but maybe there will be other efforts, as the data isn’t exclusive.

I work in the corporate headquarters of a network/holding company. So the offices have a lot of heavy wood and serious meeting rooms. As a matter of course, the boardroom always has blotters, notepads, and cups of pencils (points up so as not to blunt them) perfectly sharpened and identical lengths.

In keeping with that serious, weighty tone, we have these water glasses:

The glass, as you might imagine is heavy, very heavy. It’s so heavy, in fact, that the difference between a full glass of water and an empty glass in the hand is imperceptible. Visually, there’s so much refraction and distraction that you can barely tell that that is in fact a full glass of water. This lack of information — the weight in my hand, and the visual cues of water level — has me regularly putting an empty glass of water to my mouth, trying to sip off the top of what turns out to be an empty glass.

Not such a big deal. I guess one of the hazards of ever having been an interaction designer (which for me was about 4 years ago), is that you never stop noticing that kind of stuff.

As a run-up to the O’Reilly “Tools of Change for Publishing” Conference, an O’Reilly Radar article suggests that Amazon should get back to selling content and let the open source community take a crack at evolving the Kindle.

Imagine how many great new features would be implemented in this model. Rather than being limited by the fixed (and apparently small) number of developers assigned to the internal Kindle apps dev team they’d suddenly have access to as many developers as they could recruit to the open source project. They could create a world class set of apps and quickly distance themselves from the competition.

Interesting contrast to the quotation in my previous post from Tim Cook: “We believe in saying no to thousands of projects so that we can really focus on the few that are truly important and meaningful to us.” Or the Steve Jobs line about focus:

We tend to focus much more. People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.

Open Source tends to do two things well: 1) execute well-defined functionality (mimic stuff that’s already out there with some improvements); and 2) solve well-defined problems (as Eric Raymond puts it: “with enough eyeballs, every problem becomes trivial”). Open sourcing the Kindle will almost certainly lead to the creation of more features and functionality, but it won’t necessarily find the right balance of them and craft them into a clean product.

The New Yorker of December 20 has a profile of Shigero Miyamoto, the creator of the Mario Brothers and Zelda universes and a key player in the creation of the Wii (and Wii Sport and, if I had to guess from the crazy fun play, Wii Resort).

The profile talks about how surprised people were at what a success the early Mario games were and, in trying to figure out the unlikely magic, talks about a theme near and dear to me: emergence:

Again, the object was the rescue of a maiden, who has been kidnapped by Bowser, or King Koopa, an evil turtle. Mario, now a plumber, and joined by a lanky brother named Luigi, bounced through the Mushroom Kingdom, dodging or bopping enemies in the form of turtles, beetles, and squid, while seeking out magic mushrooms, coins, and hidden stars. When you set down these elements in ink, they sound ridiculous, but there is something in this scenario that is utterly and peerlessly captivating. There were eight worlds, with four levels each, which meant that you had to pass through thirty-two stages to get to the princess. You travelled through these worlds left to right, on what’s called a side-scrolling screen. It wasn’t the first side-scroll game, but it was the most charming and complex. What’s more, the complexity was subtle. Yokoi, Miyamoto’s mentor, and the inventor of the Game Boy device, had urged him to simplify his approach. The game had just fifteen or twenty dynamics in it—how the mushrooms work, how the blocks react when you hit them—yet they combined in such a way to produce a seemingly limitless array of experiences and moves, and to provide opportunities for an alternative, idiosyncratic style of play, which brings to mind nothing so much as chess. Will Wright cited the theory of emergence—the idea that complex systems arise out of the interaction of several simple things. “The hardware wasn’t much better than Atari’s,” he said. “The polish and the depth of the games were. Super Mario was so approachable, so simple, so addictive, and yet so deep.”

Emergent systems, complex systems from simple things, brings to mind “nothing so much as chess.” Embrace complexity, avoid complications.

Read more

In a couple weeks, I’ll be starting a new job (deets later) and thought it was time to clean the rust off the tools in my toolbox. I’m starting an ugly little blog called “Learn to Code Already (and while you’re at it, learn some data, too)”. During my union organizing days, I wrote code to pay the bills (hopeless political causes are romantic and certainly the good fight, but they are financially suspect). When I became a digital/interactive/game designer, some time in 1996 – 1997, I realized that basic computer knowledge could have a huge impact on the quality and innovation of a design. My computer knowledge was basic:

- databases (I wrote programs in C and Java for Paradox and DBase IV and in Visual Basic for Access)
- command loops
- data variables and structures like arrays, lists, and structs
- conditions (if … then)

The only hard part, conceptually was learning about relational databases once my freelance work required me to move past flat file systems. The rest was pretty straightforward, requiring some rote, some instructive debugging, and excitement at what these things might do. (I learned BASIC on TRS-80 and within a week was hooked, writing D&D character generators, lunar lander games, and even the beginnings of a Zork-style adventure game.)

With this small bit of knowledge, some free time, and youthful arrogance and curiosity, I was able to write database programs for health organizations, artificial intelligence routines for a deer hunting game as well as several classic board games, re-write the timesheets reporting program so I could get better data on my clients at R/GA, create small HTML tools that sped up and improved the accuracy of posting to client review sites . . . to name some highlights.

Today, those skills are rusty and there are new languages and types of languages that make me want back in. As I wrote to a programmer friend of mine:

* I’m frustrated that I no longer have a coding language or tool to play with ideas (I used to have VB and that allowed me to write bulletmaker and a new timesheets program for Nike as well as a deer AI).
* I’m frustrated that it’s so hard to find a place to start
* I want to start a new language
* I want to blog about coding. I bought “learntocodealready.com” and want to make it a group blog for four or five people to record their progress, save resources, share tips, and build the case that code is the cell unit of creativity

He wrote back:

Nice. Just last weekend I realized there were far more powerpoints on my computer than source code files. Not good.

So starting digging in with jquery tutorials.

It’s also worth highlighting Douglas Rushkoff’s Program or Be Programmed argument. Read it yourself, but the short version is: we can master our tools, or let them drag us along by the nose and hope we go somewhere interesting. Or as the good folks at Whole Earth Catalog used to say, “We are as gods and might as well get good at it.”

I’m starting with Python, using Zed Shaw’s Learn Python the Hard Way, a book targeted at absolute beginners and which strives not to teach Python in a hard way, but in a way that has lasting value.

Three goals for the site:

1) convince people that learning to code is valuable, fun, and attainable. Further, that it should be part of our literacy in the digital age, especially if we’re in that business.

2) Collect resources, inspirations, code snippets, and advice that clears the way for people to start learning at a level and in an environment that works for them.

3) Collect little tidbits of information, inspiration and wisdom from my own experience working through some Python books, then getting into HTML 5, then PHP/MySQL.

Ping me if you want to join up: kip dot voytek at gmail dot com.