Eric von Hippel’s book Democratizing Innovation rang all sorts of bells for me back in 2005. I cited it in a couple of InfoWorld columns and continue to cite it in blog posts. Here’s how I originally summarized the book:
MIT’s Eric von Hippel notes that users of products and services — and by users he means both individuals and companies — often innovate on their own rather than relying on manufacturers to do it for them. And not just in the realm of IT; a survey of employees in 74 pipe-hanger installation companies found that 36 percent developed or modified pipe-hanger hardware for their own use.
There’s no mystery why this should be. In general, we all share the same needs, but specific requirements vary in ways that motivate a shift from mass production to mass customization. The question is how to do mass customization economically.
Von Hippel advances the notion of user innovation toolkits. The Apache Web server, with its modular architecture, is an example of such a toolkit. In the hands of skilled programmers, Apache can be, and often is, tailored to specific needs. When such customizations are shared, other users benefit. But so do Apache’s developers, who, by observing what’s done with the toolkit, can more intelligently evolve the core product.
I’m always on the lookout for user innovation toolkits, and what brings me back to the topic today is this analysis of the design of Google’s and Bing’s maps (/via @gnat). It includes a stunning animated gif that flips between the Google and Bing renderings of the northeast U.S.
Justin O’Bierne’s question was: “Why Do Google Maps City Labels Seem Much More “Readable” Than Those of Its Competitors?” It’s a fascinating and, in my non-expert judgement, a very plausible analysis. When I watch the two sample images in rapid alternation, though, I’m struck by the way in which each seems more readable than the other in certain ways. I can imagine a mixing board with knobs for a bunch of textual, graphic, and layout parameters. By twiddling the knobs I could combine what I like best about each of these two samples. Of course I’m not a designer. If you are a designer, you’ll say that I’m being naive, that design isn’t knob-twiddling, it’s a holistic exercise. And you’ll be right. When everyone can twiddle all the knobs, disasters can ensue. I’ve created a few of my own.
Still, if we can democratize the knob-twiddling, we should. User innovation toolkits can’t guarantee good outcomes, but they can open up the design process to experiments that might sometimes work.
In that vein, I want to draw attention to an interesting use of Firebug. If you’re a web developer you know about this excellent tool. If you’re not you probably don’t, but you might want to remember what I’m about to say. It turns out that Firebug can enable an armchair web designer, perhaps with minimal knowledge of HTML and CSS, to prototype in-situ alternate versions of live web pages.
I discovered this because I wanted to be able to show how the elmcity event viewing widget might look as a replacement for the existing widget on the events page of various web sites. I formerly did this kind of thing in two ways. One was to drop an image of the new element onto an image of the existing page. The other was to save the page, edit its HTML and CSS, and snapshot the result. For all sorts of reasons, both of these methods were flawed and, more importantly, inacessible to anybody without a ton of web development experience.
Then I realized that Firebug enables a better way. Clearly I’m late to the party. I’m sure most web developers have known about this technique for a long. But I’ll bet a lot of people who aren’t web developers would want to use it from time to time too, if they knew how. So, here’s the drill.
Let’s say that I want to show the Keene Sentinel how the elmcity widget would appear on the Sentinel’s calendar page. Here’s the existing page:
I position the cursor on the calendar element, and inspect it:
Now I can see that the element I want to replace is <div id="calendar">. So I click its parent, <div id="inside-page">, inspect it, click Firebug’s Edit button, and remove everything inside that tag:
Edit button??!! Who knew? Many of you, I guess, but not me until recently. Anyway, to complete the task I follow the instructions for how to stick an elmcity viewer widget into a page:
Done! Here’s what the Keene Sentinel’s calendar page would look like if it used the elmcity widget:
Firebug isn’t just a great tool for developers. It’s also a user innovation toolkit that can enable anyone to try out an alternate version of a live web page.
You should also check out its css style editing facilities on the right, if they are new to you – after selecting an element, click, say, a font-size rule, and start arrowing up / down to increment / decrement it in steps of 1 [unit], or 0.1, if near 0. The same way, you can add new css styles to it by tabbing forward after the last row and write your own new style rule. You can also toggle rules on and off by clicking to the left of each one. In this fashion, you can custom tweak an item until it looks exactly right in relation to its surroundings, and keep going until the page feels right, in a very rapid fashion.
WebKit and Chrome are rapidly catching up and going beyond what Firebug does, but UI wise, Firebug often still is easier to work with.
Indeed, Firebug is a revolutionary tool and I don’t know how I managed to do things on the web before it. For quick prototyping and more, it’s unbeatable and so much better than mocking things up with pictures of web pages.