www.satn.org

Project MAC, where we met S at MIT A the Software Arts building where we worked together T and the attic N where VisiCalc was written
Other writings on our personal sites:

Bob's
David's
Dans's
RSS Feeds:

SATN

Bob

Dan
Comments from Frankston, Reed, and Friends

Saturday, March 19, 2005

BobF at 9:00 PM [url]:

Gratuitous Complexity for Fun for Profit

I just came back from O'Reilly's Emerging Technologies (eTech) conference. The theme was "remixing" which I interpret at DYI by building upon existing capabilities. It's the kind of thing I've been doing for much of my life.

When I found I would buy the same book each time I saw it, I decide to use a barcode scanner and get a list of all my books. I then wrote a program that scraped information from sites like Amazon, Barnes and Noble and the LOC (Library of Congress) sites so I could get the title and other information from the barcode. Screen scraping can be simple -- you can use a program to control the browser and then look at the text behind the web page. The HTML is typically very simple and you might look for ISBN: 0123132122 and then parse it. Figuring out how to do each of these "remixings" takes time and, more to the point, they each need to be maintained as things change. American Express seems to change their site every few months -- it may look the same but underneath it changes just enough to be a challenge.

Amazon is my friend because there is now a well-defined and supported interface that makes it easy to translate an ISBN code into a description. Of course I will always want more capabilities but I very much appreciate any help I get.

In today's Boston Globe (March 20th, 2005) there's an article about how Verizon and Cingular have agreed on how to exchange photos across carriers for "only" 25� a photo! Today these are typically low resolution pictures that require essentially no network capacity since they can be sent during idle time on the network. The camera itself adds very little cost to the telephone itself. By contrast, my PDA phone can send photos for no cost over the data connection. It doesn't take many photos to justify the cost of the smarter device. Even if you don't buy the data service, making a short connection to send a few bits doesn't add any cost to bucket-o-minutes plans.

If you look at the Open Mobile Alliance specifications you'll find yourself in a warped (wapped?) version of the Internet protocols with references to the RFCs and then their own special versions. The argument for a parallel universe is that the wireless bits are very scarce and expensive. While today's cellular networks do have significantly less capacity than the rest of the Internet, it is not so extreme as to justify WDML in place of HTML. The real problem is that the architecture of the cell phone doesn't make it easy or safe to write independent software applications. The browsers need to be frozen into silicon and can't be fixed short of replacing the phone. In general you cannot simply connect to a phone -- you must connect to a gateway in order to send a message. This gateway translates the message and typically creates another billable event.

Phones that support end-user program reduce the carriers' control. These so-called Smartphones must conform to the standard Internet protocols because they are part of that world. Sending pictures between those phones does not create a separate billable event. There is creates little incentive for the providers to open up the capabilities of the phones themselves. Writing a program to send a photo from such a phone would be easy if the APIs for controlling the camera were readily available. In fact, that would be the least interest application. Once I can control the camera why not use that camera for reading bar codes, or taking a series of pictures and interpolating them for more resolution or ... if I have to give you a list you don't have much of an imagination. At least I can capture the picture to a disk file and then have a program send it. I can, but there are too many other interesting projects to silt up my life with yet another work-around.

It doesn't take much to add just enough complexity to make something not worth doing.

Microsoft now provides an example of how to create your own DVR (Digital Video Recorder) in software. The sample code is relatively simple and the barriers are small but critical. The first is that you must have a special version of Windows -- the Media Center Edition. Unlike competitors like Snapstream, ShowShifter, Myth TV and others, Microsoft's MCE is a version of XP with special capabilities! This in itself is outrageous -- while the product group might argue they need special capabilities they should not be taking advantage of their special position. Instead they should, not must, be required to provide the same platform to others!

The other big "gottcha" is the "broadcast bit" -- this limits how you can use the bits that are on your own machine and is likely to become sufficiently pervasive to moot the DVR capability. The broadcast bit makes it difficult to time shift the movies you've already paid for and thus renders the DVR exercise pointless! Admittedly the business models of the providers are based on the assumption that you will not get more value out of the movies than providers intended but that's like a university charging you based on the IPO value of the company you build after you graduate!

Cellular and broadcast communities are increasingly building on the same computer technology as the rest of us, even if they warp it a little. Ideally this understanding should help people realize how much more they can get and rather than being happy at the opportunity to spend 25� for a sending throw-away snapshot to another phone they would want more capabilities without creating artificial billable units. They would not tolerate a "broadcast bit" or having to use a special version of the operating system in order to manage the video bits.

As with the Stockholm Syndrome in which people identify with their hostage takers, most people get angry when I tell them that they could do more -- they fear losing their TiVos and are thrilled at seeing a fuzzy picture on their cell phone. They know that they can't do it themselves and will wait till the carriers and broadcasters deign to do more.

The good news is that it doesn't take many software developers to get angry and provide more capabilities at the edge after sharing among their own communities. Barriers like the gated community of cell phones and annoyances like the broadcast bit create real barriers.

But we've seen this before -- when you assembled a PC you used to have to run an analog audio wire between your CD player and the other boards on your PC. Microsoft found they couldn't support this and quietly shifted to supporting the digital audio path. People may still install those wires but they are moot. At least for the most part--I find that some video boards still enforce this limitation.

Change requires awareness and then frustration at gratuitous complexity. Too bad our education system and society in more oriented towards teaching about what is and rather how to learn on their own and take advantage of new opportunities. It's like only teaching people how to select from a menu and making them suspicious of those who do their own cooking.

Perhaps no child is to be left behind but the price we pay is that they are all in lock-step. Oops, wrong essay. The question of why so few people demand more is a separate essay.

Instead of I'll close by observing how close we are to building on these capabilities. We are prisoners of myths. One is that cellular bits are very expensive and special because they are wireless (even though 802.11 bits are free). Another is that without the "do-not-copy" broadcast bit we will no longer have movies. This too is despite the lessons of the VCR -- giving people the ability to add value helps us all.

All I want is a little bit of change ... so I can change the bits myself.




For more, see the Archive.

© Copyright 2002-2008 by Daniel Bricklin, Bob Frankston, and David P. Reed
All Rights Reserved.

Comments to: webmaster at satn.org, danb at satn.org, bobf at satn.org, or dpreed at satn.org.

The weblog part of this web site is authored with Blogger.