I appreciate a well-designed product but I am looking for more. I want a product that I can enhance and make more valuable. I want a product that gives me the ability to make it into what I want. I want to know what the product isn't but can be.
The idea of being able to build on a product is not entirely new. A box of premixed ingredients for a cake is nice but only if you want one of the cakes already packaged. For the most part we do buy finished products. The advent of computers and the ability to use software has changed the rules. We are increasingly able to cook up our own products out of basic ingredients using software as the universal ingredient. We can then share the software and thus others gain the benefit of added value.
I started coding VisiCalc in 1978. My target was the Apple ][. It was, perhaps, fortunate that the machine ran thousands of times slower than today's PCs and had thousands of time less memory, a very small screen and no disk drives. It forced Dan and I to do a very simple program that did little more than display numbers on a grid and do recalculations. We had a tight budget and had to justify each feature we added.
People thought of VisiCalc as a financial planning tool but it wasn't. The term "spreadsheet" is very old and was used for a large sheet of paper (or a blackboard, whiteboards were unusual) with a grid of boxes. It could be used for production planning or any other kind of calculation. Accountants and financial analysts typically used more specialized forms or programs targeted to their specific needs.
In order to do accounting with VisiCalc you had to know accounting!
Twenty years later spreadsheets are far more powerful but they still don't do accounting!
People have done "better" products! In the 1980's HP shipped a hardware product -- the Workslate. A startup, Javelin, did a spreadsheet with emphasis on time series analysis and Lotus did Improv. Improv was very well received and one respected reviewer asked me why Lotus bothered shipping 1-2-3 once Improv was available.
The problem is that these programs were too smart and made it more difficult for those doing financial analysis to explore information outside the programs paradigm. We should not confuse better with more specialized. A product that is very good for one purpose makes other applications more difficult and frustrates discovery. An effective enabling technology facilitates making the product better according to the users need across a range of applications most of which are unanticipated.
This isn't to say that there is no room for programs that do "know" accounting -- the popularity of Quicken demonstrates that there is indeed a market. But it is very hard for the user to add much new value to Quicken. I do use Quicken for some purposes but keep my own database so I can do my own analysis and processing.
Products that do less allow the users to add the value. There are far more users than developers and the users discover new value as they use the product.
The flipside is also true. Products can increase their market size by doing less. That might seem counterintuitive until you realize that the more specialized a product is the more limited is its target market. This may seem like something for nothing -- doing less and getting a more valuable product but knowing what to leave in and what to leave out can be very hard work and there is no certainty you've made the right choices. You also may not gain the benefit of the added value and may find your contribution to be just a low cost commodity.
Hilton advertises that their customers (guests??) "�know how to set alarm clocks from at least eleven different manufacturers". This is absurd. But we cannot and shouldn't try to solve this with a committee of experts. Instead we should encourage manufacturers to provide simple interfaces but they don't all have to be the same. As long as they don't do silly things like rely on an "up/down" command instead of just letting one set the time, we can use software to handle the various cases. Over time some common interface will emerge. Too bad the tendency is to not only wait till the committee designs a solution, it is typically wed to a complicated set of interconnected systems and, in the end, we are stuck with naive decisions that get frozen into hardware. Bluetooth is a classic case of this phenomenon.
If users can add value, then each user might see the product in a different way and this confuses people who think they know what the product is and consider any other point of view wrong.
Marketplaces are repurposing products all the time -- rethinking what products are and remixing and reinventing. It is far safer to repurpose an existing technology is typically far less expensive and thus less risky than creating an entirely new one. Those who have invested in one view of the product often find it difficult to come to terms with the change.
You can often repurpose a product just by thinking of it differently without having to change the device itself. The Internet is a very good example of this. It is a very simple concept -- in fact, it is based on the very idea that customers define products. The end-to-end principle puts all the power of defining the product in the hands of the users.
The effort to keep the definition of telecommunications mired in the 1930's comes at a very high price. Such intransigence would simply be ineffective were it not for the fact that those most vested in the status quo created a legal artifact, the Regulatorium that has made the governments the stakeholders in a very narrow definition. The copper wires and radio signals used to transport the data are defined narrowly in terms of telephony and television and other services which tolerate no added value. We had to fake out the phone network in order to do data communications. It was very inefficient but the value we added by innovating was so great that even this barrier could only slow down the process. In fact, as I point out in recent essay, Have Connectivity, the process is moving forward anyway but we are denied the economic benefits in the meantime.
The consumer electronics industry is facing the same pressures as the telecommunications industry has but without the rigid protection of the governments. Parts of the industry are trying to hold back change rather than coming to terms with it. The furor of "pirating" music is a great example of this -- it is an attempt to keep music locked into static bits rather than letting creativity flourish as the cost of product and distribution has come down. The biggest change will be wrought as we create new music instruments out of the digital technologies we have.
The consumer electronics industry is a complex marketplace in itself. I expect it will start to sort itself out and product building blocks. It's not an entirely new concept -- in the 1950's component systems were the norm. It's no surprise that he industry designs protocols like IEEE-1394 that embody the limited set of product requirements rather than building on the Internet standards but this is starting to change. The increasingly rapid product cycle will help assure this. The miniDV (digital video) cameras have barely caught on when they became obsolete -- my new Panasonic camera doesn't use tape. It stores the full quality images on digital media (SD). Instead of having to deal with 60 minute tapes video can be managed just like snapshots. Unfortunately the software that came with the carrier is narrowly targeted to a particular usage scenario and forces me to work around the favors they are doing to me.
Companies who pride themselves on their marketing skills rather than their engineering skills may find themselves competing with their customers but I expect them to find their own opportunities.
Designers need to be aware of the need to do more than isolated products. The PDA craze is at a crucial juncture because the devices are now very capable but still hostage to their PDA roots. I have a number of devices but rather than easy to connect, I have to synchronize with just one (or at lest one from each family) at a time. This is a perfect example of products limiting their own utility.
As I write this I'm preparing for my panel at the VON. I've been playing with VoIP because it is about more than just cheap phone calls -- we can bring audio in line with instant messaging and email. But I find that much of the effort is focused on what I've been calling faux telephony. The devices and software build in many assumptions. I actually want them to do less -- just let me "call" a device with its IP address.
I understand why products are being designed as they are. As one who builds software I'm very sensitive to proper architecture. This is why I've been so strong in advocating building on encrypted IPV6 rather than working around NATs and firewalls for each application.
It's hard to argue for architecture because I am arguing for what isn't rather than a concrete design. It's easy for people to see what a product is now. Those who see beyond that are often dismissed as visionaries even though we (yes, it's personal) are very pragmatic and have a lot of experience with building on platforms to do so much.
And we can do so much. My big problem now is that software is becoming increasingly easy to write (at least for a given task). I'm particularly excited by Microsoft's .Net framework and I also look forward to efforts like Croquet which offer the opportunity of new kinds of computing environments. It's become too easy to build my own solutions and I don't know which to do first. I don't really want to do it all myself so I gravitate towards using available building blocks. This is not quite the same thing as open source though it is related in that they are ways to share the creative effort and results.
The so-called visions of the future are actually very mundane. The key is to have an architectural view. This is not just architecture as in programming (or building) but also in terms of the marketplace. The Internet gives me connectivity. Instead of worrying how to connect devices I just assume I can and build from there. My now classic example is the Kindergarten camera -- just place the camera in the classroom and parents can watch the kids from their offices. It went very quickly from impossible to too mundane to be worth even mentioning.
In traditional telecommunications I'd have to worry about all the wires. With the Internet I don't think about it all. The reason I can is that we have an agreement. I use the connectivity and others provide it. We have a common meeting point and anything I do with connectivity is fine and anything they do to provide it is fine.
The story isn't perfect. The Kindergarten camera, the Web and VoIP needed to wait till the Internet grew but that's OK because we have a simple metric and can measure progress simply in terms of capacity or maybe price/performance which is essentially the same thing.
In fact, I've been struggling to explain this concept because I want to write about how I use connectivity in my car but I'm going to have to play this game of pretend. I've done enough to know at least some of the applications and how easy they are. But the reality is quite messy. If I told you how I work around each problem you would miss what I'm really trying to say and wouldn't know what needs fixing. So I'll write one story for those who will build on connectivity and another for those who provide it. Actually I'll give both stories to both audiences in hopes of creating users who demand solutions to the impediments and to give motivation to those working to provide connectivity.
Power to the geeks. The idea of separating the user interface (or application or device) from the underlying mechanisms and making the mechanisms available was a basic design principle of the Multics project. Unix was implemented as a poor man's Multics with the focus on using inexpensive hardware. It retained some of this principle but because of resource limits it couldn't make the building blocks readily available. Instead it took advantage of the Multics shell design that allowed the output of one program to be piped into another program. Piping was emphasized in Unix which initially ran with very limited resources and it was difficult to run more than one program at once. Shell programs tend to be more like scripts listing commands than programming so has the advantage of making the capabilities accessible to more users. Both Unix and XP have rich shell programming capabilities.
We are all geeks. When PCs were first introduced one of the big problems was the keyboard -- obviously we couldn't expect people to type. That was a secretarial skill and thus a lot of effort went into dictation so we could translate speech into text. Turns out that everyone could indeed type -- you had to in order to get through school. And people type even when they have a choice--you can work with text in a way you can't with speech. Email is far easier to manage than voice mail. And we all can program albeit inarticulately. As nice as the original Apple Macintosh was one of the big reasons that it remained a niche product was that users didn't have an ability to extend it. They couldn't write simple scripts that put together a few commands. It was very high tech but still manually operated.
Spreadsheet programs are really programming environments but people forget that since they assume programming is an esoteric skill. When I talk about programmability I'm thinking of something simple but people tend to view it as something they can't possibly do. When I introduced VisiCalc in 1979 I compared it with the ability to dial our own phone calls instead of relying on operators. We must start to articulate and explain the concept of programming -- the basic concept that gives us the ability to build our own solutions, to define protocols for cooperation and to create new value. Note I said concept -- there are lots of concepts within programming but the important one is simply recognizing that we can delegate tasks by programming.
The devices and gadgets that are available are fun and exciting but they pale compared to what I and, more important, you can make them into. Don't be blinded by what they we have now, the real value and opportunity lies in what isn't.
