Technical mastery requires social innovation

A number of times, recently, I’ve made an assertion with which nobody has disagreed. The assertion is that if we invented no new information technologies for the next five or ten years, we could nevertheless move the ball significantly forward by consolidating gains that we should have made by now, but haven’t. My argument is that what people don’t know and seemingly cannot learn about computers, software, and information systems represents what Amory Lovins, speaking in terms of energy, calls negawatts, a resource whose value springs not from new production but from the rethinking and improved utilization of existing resources.

As the software pendulum swings back and forth, we alternately hail the simplicity of interfaces that do very little but are easily learned (Google Docs), and the power of interfaces that do much more but are much harder to master (Microsoft Office). Arguments for the former presume that the latter are doomed because most people never learn to use most of their power. That’s true. But does that mean that most people will never be able to make better use of that power? If so, if we assume that people are simply uneducable in this regard, then it’s a problem across the board. Because even the simplest online application can do much more than people know or appreciate.

For example, looks to be bare-bones simple, and in a way it is, but to use it effectively you have to master some strategies that today elude almost everybody. In a comment on that entry, Tessa Lau writes:

In order to accomplish your #1 and #2 above, people need to both realize that they can do that database query, and that they can refer to the results using a stable URL. I’m coming to believe that both those operations are still way beyond the capabilities of mainstream web users.

Here’s a related example from Gmail. Recently, the application’s URLs became more RESTful. A message URL now looks like this: Why? So that you can bookmark it, exchange it, compose it with other things. Almost nobody will, of course. But are these operations truly beyond the capabilities of mainstream web users? Or are they just skills that aren’t easily transmissible in the current environment, but might be in a differently-designed environment?

Tessa Lau’s CoScripter is, of course, a beautiful example of such a differently-designed environment. It enables people to share experiential knowledge about the use of software in a relatively frictionless way. In the realm of screencasting, Jing is another way to reduce the friction of sharing such knowledge.

My point holds no matter where the pendulum happens to be at the moment. Across the spectrum of application styles, software can do a better or worse job of augmenting human capability. Simplification is important and useful, but it’s not all that matters. Mastery of the more complex matters too. And people can handle that.

As Lucas Gonze notes here, reading and writing musical notation was once a much more common skill than it is today. The 19th-century parlour music that he’s recovering and bringing back to life was, Wikipedia says, “intended to be performed in the parlours of middle class homes by amateur singers and pianists.” Were those amateur singers and pianists more capable than their counterparts today? No, they were just embedded in a culture that was attuned to a certain sort of peer production.

The peer production of our era is based increasingly on software applications and online resources. If we aspire only to the common denominator, and assume that no forms of mastery will matter, then we do ourselves a great disservice. People can attain mastery in an environment that encourages it. Creating that environment would in fact be a major innovation, albeit more social than technical.

Posted in .

20 thoughts on “Technical mastery requires social innovation

  1. Social processes are a big part of technological progress. For example, hype bubbles around a technology like tagging, podcasting, p2p, or social networking create a mob of developers that explores the possibilities of the space and develops it into its mature form.

  2. “But are these operations truly beyond the capabilities of mainstream web users? Or are they just skills that aren’t easily transmissible in the current environment, but might be in a differently-designed environment?”

    Absolutely – as technologists, we’ve trained users not to look at the location bar of their browser when they’re using our apps. The skills to really start working with web resources in a compelling way requires mainstream apps that provide some value to users who choose to interact with the object space via URIs. Imagine how much people would learn through a “RESTful Facebook”? (And here I may be showing my ignorance – I have no experience with Facebook).

    I don’t think that users should have to know about database queries – should I have to know about transistors when I tune my car stereo? We’ve built this thing that allows everything to be a resource. A few simple design ideas, broadly applied, would really help to bring this idea to many more people.

  3. “…beyond the capabilities of mainstream web users.” That raises some interesting notions for those of us in faculty development. There are some key words in your title to this posting, but for many mainstream web users, they have to first master personal use before exploring social use. To a degree, I saw this when I had my graduate students use for a class assignment. After 10 weeks, nearly 80% of the class was still using for bookmarking/tagging, but only a handful had more than a few people in their networks. If I was to graphically describe this, I would draw concentric circles with technology in the center, personal use surrounding it, and social use surrounding that. It takes time and effort to move people very far off center.

  4. There are varied capabilities among users, yes. But more importantly there are different needs. I do some minor image editing in iPhoto, it is meets my needs. Why learn Photoshop?

  5. I agree with your core assertion, and see a corroboration story in my own work:

    Front-end Engineers tell browsers what we do. We write the code that is the interface and the interaction of web sites. For us, August 27, 2001 is infamous. That day–more than 2300 of them ago–was the last time we received a new tool we could actually use: Internet Explorer 6 (IE6) was released.

    Since then new browsers have offered important and powerful new capabilities, yet 1 in 2 users still surfs with IE6. Even with strategies that help us move forward in spite of this Sisyphusian condition (such as Graded Browser Support, which I published at Yahoo!), we still can’t use technology newer than 2001 for anything mainstream or substantive!

    And yet the web flourishes. The remarkable “internet speed” of innovation appears, from a distance, powered by technological advances. But up close it is a mirage on an invention vacuum. We’ve increased the speed, capability, responsiveness and detail of sites by spending only negawatts.

    (Clearly the browser is but one part of the web “stack.” But it’s a pretty critical one, and since it’s nearest to the consumer it is a gate keeper.)


  6. “I do some minor image editing in iPhoto, it meets my needs. Why learn Photoshop?”

    In that case, there’s absolutely no reason. Simple tools that do basic things well are fantastic, we need more of them. When needs are being met, nothing more is required. But there’s also a lot of unmet need. A big chunk of that is beyond the reach of any available software. Another big chunk is within reach but unknown and unexploited.

  7. “We’ve increased the speed, capability, responsiveness and detail of sites by spending only negawatts.”

    That’s a great point. On the provider side, the negawatts /are/ being used. But what about on the consumer side? In the case of, none of its benefits require any new browser tech. They only depend on people grasping and applying concepts. The barrier is conceptual, and the negawatt power flows when people surmount it.

  8. You expect ‘the people’ to understand RESTful applications when they can’t even reset their dvd/vcr/digital clock when the power goes off??? I don’t think so.

    UIs for all kind of electronic stuff are non-obvious and difficult to use if you don’t understand the designer’s intent, which is never clear. I’m supposed to see a URL that is constructed one way and understand that it’s somehow different than a ‘regular’ URL? How? What about the thing I’m looking at helps me understand the difference? Should I care? What does it mean for ME? Heck, what is a URL?

    I’m not hopeful that anything is going to change any time soon. Developers are too wrapped up in the gee whizz stuff to help Joe User actually take advantage of truly interesting new stuff.

  9. I thought of a good example of why I think technical mastery for the masses is an issue.

    I was on a developer’s discussion forum about a month back and someone complained about the site’s search functionality – too hard to use, need to know the right syntax for an effective search, yada yada yada.

    I made two suggestions – use the site’s built in ‘advanced’ search builder which lets you do things like ‘search for all words’ or ‘search for exact phrase’ or ‘use fuzzy logic’, etc. As an alternative, just search via google’s ‘ site:. Guess what? This was a total surprise to a lot of folks at the site!

    I’m no Google master but the ‘Site:’ search method is pretty much Google 101 and here was a pile of technically competent individuals who had NO clue it existed.

    I’d suggest that mastery of the arcane world of the web is, in fact, beyond the ken of most users. US specific side note: funds for science, slashed by Congress. Money for adequate education, not really. All children left behind – when will the ever kill this stupid law? More than 1/2 of US citizens don’t think evolution is anything more than a ‘theory’ and they have no clue what the word ‘theory’ actually means. Call me cynical, but I don’t think we’re heading the right direction and there is a constant need to dumb down the systems people use.

  10. “You expect ‘the people’ to understand RESTful applications when they can’t even reset their dvd/vcr/digital clock when the power goes off??? I don’t think so.”

    And yet, I am constantly hearing from librarians who, with my help, figure out the URL pattern required to get their OPAC systems to work with LibraryLookup. As John Willinsky says ( it all comes down to motivation and context.

  11. “Developers are too wrapped up in the gee whizz stuff to help Joe User actually take advantage of truly interesting new stuff.”

    That’s for sure. User-to-user education is how the knowledge can spread. Hence my interest in a variety of ways people can capture and share experiential knowledge about the use of software and information systems. (And about all kinds of other things too.)

  12. Learning and “mastery” are transactions, or more specifically, they are costs to the user. Time and energy is spent to learn a new aspect of the user interface of an application. Whether or not an individual will spend her time learning something new depends entirely on the return on investment. What new value is created? No one simply adds to her inventory of skills without assigning a value to that skill.

    And like any good shopper, the user will require a solid demonstration of value prior to investment. (And a use case is not the same as value.) If value can be demonstrated, users will put up with horrendous interfaces and climb any mountain to attain the desired value. In a sense, this is what games are. The demonstration of value is the “social” part of the equation. In many cases, we must see a peer deriving value before we believe the value to be real.

    I wonder if screencasting, and demonstration methods of that type, have as much persuasive power as seeing a friend reap a benefit in the wild?

    I’m not sure how one could know this, but if every device and application was rated based on the ratio of total number of product features to the average number of features used — it would tell you a lot abou the unused capacity of existing software. It might also tell you something about unwanted capacity. In addition it might provide a list of core features for simplified network/cache based version of the application. The other measurement is the degree to which to product overserves its audience and to what extent it’s vulnerable to the Innovator’s Dilemna.

  13. Jon and Cliff,

    Despite the tone of my post, I totally agree with you both; I have no doubt that it is possible for anyone to understand nearly any complex concept given motivation, time, and a tutor.

    Jon, one tiny quibble with your example – librarians are not exactly ‘Joe User’. The ones I’ve known are, at their core, true knowledge workers. They spend their lives classifying information into logical systems and then use those logical systems to help people find sometimes arcane resources. They come with a built in ‘seeker’ mentality and have always embraced new technology that makes it easier to find and use data. That and rabid first amendment advocates… ;-)

    Cliff, re the ‘feature used/feature requested ratio’ issue; I think you’re dead on with this one. I have the luxury of working with the end user on application development and then living in the same work environment with them after the app is released. Once people understand it’s OK to ask for features (cost of adding and maintaining is low for us), they really start to pile on the requests so it isn’t uncommon for an app to become a bit more complex than required. I can add tracking tools to the apps that help me understand which bits they use and which bits sit moldering in the corner and can then use that information as a basis for follow on design mods. Either the unused functions are poorly implemented and, thus, never used or they aren’t really needed. Over time, the apps tend to converge toward a ‘just right’ set of features. How you do this well when the actual user of an application/site is often anonymous is a much more difficult proposition.

    Thanks for the conversation.

  14. “I wonder if screencasting, and demonstration methods of that type, have as much persuasive power as seeing a friend reap a benefit in the wild?”

    Seeing a friend reap a benefit in the wild is /exactly/ what I have in mind. When the threshold is low enough for your friend to capture a delightful/interesting/useful experience and share it with you, that can happen. Jing is a great example of the necessary threshold-lowering.

  15. “I have the luxury of working with the end user on application development and then living in the same work environment with them after the app is released.”

    Yeah, then it’s a whole different story. I call this the toolsmith pattern — the toolmaker is a member of the user community, working shoulder-to-shoulder with everybody else, but specializing in making/improving the tools. I’ve been in that role a few different times, and loved it.

  16. Thinking of the gmail bookmarkable URI example, a few things:

    1. It’s not very social. You can’t share, so people don’t have as much reason to communicate knowledge and techniques.

    2. It’s not very accessible. Where’s the bookmark this message link? You have to copy the URL out of the address bar.

    3. On a more technical note, the REST implementation seems to conflate resource with representation. For instance, the URI is different for the same message depending on whether you have retrieved it from a search or bookmarked it from your inbox. Do those contexts really represent different resources? I suppose that’s a question that has two answers depending on your perspective. But, that level of confusion is actually part of the problem for widespread adoption.

    4. Finally, once you make it through all of this, the feature is actually quite useful. For instance, I integrate gmail with my mac only planning software simply by copying URLs. It’s brain dead simple compared with trying to hook up with that software. However, it’s so obscure that no one knows what to do.

    I think the answer here is to spread the mantra of addressability. For that, you need big players to implement RESTful interfaces. Google’s moves are encouraging in that regard. The main problem is that they are usability and accessibility zeroes.

  17. If someone aspires to being a great writer, what would you recommend them to do — master Microsoft Word or master writing?

    This whole discussion smacks of solutions in search of problems. Designers have created a whole set of cool tools that are useful and valuable to them or another small subset of people and wonder why everyone doesn’t want them.

    Every second the value of the web increases not because the technology is improving but because people are adding content. This content is mainly words and still photos, to a lesser degree video and other things. The barriers to users doing this are low enough for mass mainstream participation. The quality of these contributions is almost wholly dependent on the ideas of the author, not the degree of technical skill in using the tools to place that content online.

    URLs have some serious conceptual problems which better use of permalinks and perhaps REST may be able to solve. Should a URL refer to a thing or a place where things are found? It’s inconsistent.

    While individual stories on may be permalinked, how do I get to see how the CNN homepage looked last week (or an hour ago)? Yes, we’ve got the Internet Archive but that’s very flawed. The concept should be built in to the sites themselves. If you’re wondering why more people don’t use Delicious or get the most out of it, perhaps the place to start would be with the widely varying styles and usages of URLs.

Leave a Reply to Patrick Bourke Cancel reply