You Can't Spell DRM without "A-S-S"

The lesson is: Don't ASSume. Don't assume that DRM will be around forever. Don't assume that the computer and telecommunications industries won't throw off the yoke of DRM to achieve more growth. With one modest epistle – not the “tear down this wall” flourish you might expect from Steve Jobs – the future of DRM was thrown into question. Subsequently, EMI tore a hole in the RIAA members' hitherto seamless adherence to DRM, and Apple removed the barriers to using EMI music bought from iTunes on other music players.

Content protection of consumer media products has been around in one form or another since Hollywood got all itchy about consumer videotape machines and started fooling with the signal to prevent tapes from being copied. Macrovision, the most successful developer of tape content protection was founded in 1983, and is still around, protecting digital content from the people who buy it. Other early forms of content protection include market research reports printed on blue paper, with watermarks and serial numbers, to thwart photocopying.

DRM, the digital form of copy-protection, has been a topic of serious research for about the past 20 years. Video games, commercial computer software, data compilations, typefaces, clip art, etc. use, or have used, various forms of content protection to try to slow down use of commercial digitally stored products in ways that contravene the license agreements that sellers of these products use to create an environment in which – in general terms – content belongs to the provider and is rented to customers. DRM is the prevalent form of content protection today because copying digitally stored content is fast and cheap, and this has raised the stakes: Any “leak” of a digitally stored product can be quickly turned into thousands or millions of copies.

The moral and legal basis for contracts licensing the use of intellectual property long predates recorded performances as a consumer product. In the U.S., copyright and patents were created, in the words of the United States Constitution...

To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

That's it. Anything outside that authorization, in U.S. federal law, is illegitimate in that it has no constitutional basis.

There are three distinctive aspects of intellectual property: 1. It is a right created by government. The right to intellectual property is not an inalienable right – it is not one that exists with or without government acknowledgment. 2. It has a stated purpose. No other human right has to justify itself. 3. It expires: You own your property forever, but your copyright or patent expires and your “ownership” or, more correctly, your exclusivity in use, licensing, or publishing, is over, in order to create a greater common holding of knowledge and art.

So how did we get from such a weak, limited, qualified, and overall second tier right as that created by this cautiously crafted clause to today's ponderous, invasive, unbounded, intrusive, over-lawyered, kudzu-like thicket of laws and technologies? Consider, for example, showing the “FBI warning” on a DVD recording, that says you will become a felon by doing something untoward with a DVD of Howard the Duck, to one of the people who drafted the Constitution's intellectual property clause. Ask them “Is this what you meant?” Never mind the DMCA and other sausages of dubious legal content.

The 100 year history of recorded performances has funded a tsunami of lawyers and lobbyists that have succeeded in overwhelming all restraints on turning our intellectual property laws into a travesty of original intent. Starting on the basis of such raucous cognitive dissonance, no wonder the modern pursuit of intellectual property has overshot even the most elastic bounds, and is now starting to snap back.

Steve Jobs's objection is, like any reasonable view of intellectual property, both pro-freedom and pro-commerce. DRM has failed the business of selling music recordings. Two or three out of a thousand songs on iPods are sold from Apple's relatively successful Internet music shop. The rest of the DRM-protected music download business is a miserable failure, just like DRM-protected e-books were a readily predictable irretrievable flop, and for much the same reason: Even the most apathetic consumer sees the value of the ability to transfer, backup, and migrate their music collection. DRM thwarts these basic requirements. The value of buying and selling in a secondary market is also completely extinguished by DRM.

The response of the recorded music industry was to try to eradicate any choice other than DRM'ed music. As if making a content gulag that was so big you could not see the barbed wire perimeter would make it seem like your content was not imprisoned.

Content protection does not always fail. When is the last time you heard someone complain that their Nintendo DS uses content protection? You don't hear such complaints because all the software runs on all and only that hardware. You can buy a DS cartridge, transfer it to another DS, sell it, and buy a different used cartridge exactly as if you were buying and selling books. The product is tangible and your use of it is in practical terms irrevocable. You don't use a DS for private documents. You can chat on it, but it isn't a general-purpose communications device, so there are no privacy concerns. DRM, when it is un-intrusive, and non-essential to any truly important personal matter, does not stand in the way of product success.

People who make DRM systems have no excuse: The examples that work are out there. Failure to realize that anything outside such closed ecosystems is damaged by DRM to the point where customers reject it as defective is entirely the fault of the system designers.

How far will this backlash lash? There is another change in Apple's position on DRM that is also noteworthy: In October 2006, Apple stopped using a Trusted Platform Module (TPM) on its motherboards. Trusted Computing is a delightfully newspeak term. It means you, the computer owner, cannot be trusted, and that certain data and code has to be hidden from you on your own computer. Trusted computing is, of course, antithetical to Personal Computing. If you don't control every bit inside your computer it isn't personal. In fact, it is partially owned and controlled by someone else.

The full exposition on Trusted Computing is a topic for another post. But the summary of the problem is that computers are an all or nothing affair: Once you let that tiny bit of camel's nose under the tent, you will have a tent full of camels in short order, each of them snooping on behalf of some interested party, be it the people who think you might be a terrorist, or the people who think you have evil intent for their music recordings. One could even implement some form of “Information Purification Directives.”

If Apple smells an opportunity in reasserting the Personal part of Personal Computing, especially as Microsoft appears to be turning your PC into a servant of the content publishers, we may see a very interesting phase of the PC business emerge.

The Meaning of iPhone, Part II

.
This is where it get provocative:

1. iPhone uses the mobile network as a backstop. The real action will happen on iChat, over WiFi. The iPhone platform is sure to be used in iPods that don't have a mobile phone radio in them. But those iPods will have WiFi, and they will be communications devices as well as media players. Communication will be an Apple product, but not the way the mobile network operators would prefer. iPhone is turning mobile service into the dial-up modem of the 21st century. The mobile carriers have been quarantined into providing switched circuit voice service in the iPhone, and left out of iPhone's commerce and higher-value communications.
2. iPhone is an embarrassment to 3G. iPhone isn't selling music over 3G. Unless there is some unforeseen disaster in iTunes sales because people can't buy music while driving, iPhone will show up 3G data service as not having found an application. The premier mobile media commerce channel brushes off 3G as unnecessary in a mobile product, and the network operator accedes to this decision. Verizon turned down iPhone, and Cingular snagged a long term of exclusivity, so it's also a missed opportunity for EVDO and MediaFLO.
3. J2ME is a ghetto for low-rent games. Too limited. Too security obsessed. Too much rigmarole to install and manage applications. Too fragmented to support applications that have a lifecycle. What could have been done in J2ME will be done in widgets or Cocoa (or in Symbian-native apps on Nokia handsets, or in .NET Compact Framework on Windows Mobile devices). However, most mobile applications will be AJAX running in full-featured embedded browsers. Java on devices? Make it Java SE on Linux, which is a fine alternative to .NET and Cocoa, is needed for applet support (dirty little secret: some of the best “AJAX” is actually applets), or fuggedaboudit.

How can the Empire strike back? By being more communications-centric than Apple. Apple can't be overtaken in mobile media, and despite Jobs's silver-tongued oratory about phone calls being the “killer-app,” GSM switched circuit calls are more like the filler app with no new capabilities. The mobile industry needs to turn that around.

The communications part of mobile telephony can be made more valuable and more powerful:

1. Presence is the killer feature of IMS. Presence that is standardized and that interoperates across service providers.
2. The user interface should have presence at the center, not off in a cheesy push-to-talk application written by a 3rd party and with a UI that looks like a programmer drew it with a crayon.
3. Presence is common to mobile and Internet communication. Make something out of that fact that makes users go “oooooooh!”
4. Real-time and messaging are a continuum. Push-to-talk is the bridge.
5. All messaging is the same – to the user. Break down the protocol-based silos.
6. Find applications and lead experiences outside of mobile media: Enterprise integration, social networks, etc. Don't bang your head against iTunes.

By incorporating the above principles into mobile devices, the mobile network operators can bridge the distance between mobile and Internet communication and they can own the bridge by adding value.

The mission for the mobile industry is to add value to communication. That's easy and natural in IP media, and anyone can create a new application. If comparable natural flows among modes of communication are available on mobile devices, users will go with mobile networks for their pervasive coverage. Blending the mobile network's pervasive availability with Internet applications captures the best of both worlds.

IMS both creates opportunities but it presents a potential blind alley, too: IMS makes mobile presence-based applications, like PoC and instant messaging interoperable and standardized, but it also plays the siren song of “service creation” - a blizzard of new services that won't add much value and that will confuse users. Stay away from things that duplicate a Web service using IMS.

Calling All Telecom Bloggers

.
Have you got something original to say about the ways that humans communicate over a distance? Comment this post and let us know about your blog.

The Meaning of iPhone, Part I

iPhone was announced, raised up as a messianic product, suffered a backlash (already, five months before it ships), and is still supplying fresh blogfodder:

First, what everyone knew from 10 seconds into the demo, is that iPhone is not a defensive move. Apple did not merely forestall what has been the oft-repeated and never realized prediction that mobile phone unit volume would inevitably crush iPod under a tide of carrier-subsidized music players. Apple is now the maker of the most desired phone on the planet.

Nobody has ever gone from zero to the very top of the game with their first mobile phone product. Expectations for the iPhone were that it would be a Very Nice Phone inside of an iPod. But only that. Instead Apple has created a new mobile phone OS and UI platform and implemented it to a level of polish above all others. They put this new software into a vessel that is, once again, the nicest package in the business. Only this time in a demanding and mature business to which Apple is a new entrant.

How much better is iPhone? Despite the very competent efforts put into mobile user interface systems like UIQ and Series 60 UI, has anyone ever really been impressed by the results? At best, users of existing products find them adequate. Inoffensive. Nice that they don't often get in the way of an important task, like reading e-mail. Meeting this standard is what Apple was expected to do. Instead they passed it from a standing start and are now in the lead.

The only knock on the iPhone is that it does nothing new, other than provide a visual interface to voicemail. But even that modest advance was a zinger. Handset product managers world-wide are dope-slapping themselves for not pushing that through in the fifteen years since that has been technologically do-able.

But this is Apple: Making the object of desire is just the start. Apple also took the challenging environment for selling a mobile phone into the U.S. Mobile network operators' channel and turned it into a work of art comparable to the iTunes contract negotiations.

By giving a willing network operator the temporary advantage of exclusivity, Apple got at least two critical benefits: Apple set terms that drive a wedge into the garden wall of mobile content sales by keeping iTunes sales off the mobile network. Apple also got the benefit of not having the iPhone subsidized by the network operator. That's correct – the benefit. In both cases one imagines the negotiations to have gone a bit like asking not to be thrown into the brier patch.

By keeping iTunes sales off the mobile network Apple completely hornswoggled Cingular. Cingular is a network operator. So who came off worse: Apple, for having to require that their customers use WiFi to download iTunes purchases? Or Cingular for having failed to sell the use of their network for this purpose? Cingular has ripped a hole in the wall in order to get that big wooden horse inside. Users of Nokia E-series handsets already know the real Web over WiFi is a much nicer experience than the mobile Web. Now millions of Cingular users will be comparing the iTunes over WiFi experience with the typical mobile content shop experience.

Which leads to the next issue: Why would Cingular subsidize an iPod, especially when it isn't using Cingular's network? Turns out they don't have to. Which also frees Apple from the prospect of music-only iPods competing against subsidized iPhones, and from mobile network operators using varying levels of subsidy, resulting in a range of iPhone prices, once the term of exclusivity expires. No subsidy also makes it easier for Apple to sell iPhone in Apple stores.

Keep in mind that MNOs' executives had not seen the iPhone. The only precedent they had to work with was the first iPod, which was hardly a revolutionary looking device. In agreeing to terms that appeared to be solutions to some practical problems when they were negotiated, they gave Apple the levers to move the mobile handset business in directions advantageous to Apple. As in the case of Blackberry subscription revenue, the mobile industry is willing to shift on some fundamental points of the handset vendor relationship if the handset brings with it significant end-user demand. But unlike Blackberry, it wasn't just a matter of revenue sharing.

It took two years for iPod to gain momentum. Analysts project that iPhone will take 1% of the mobile phone market fairly quickly. If sales fall into the range of 5 to 15 million units over 12 months Apple will roughly match their only near-direct competitor: Nokia Nseries, which sold 6 million units last quarter. In about two years Apple will have a product line as broad as Nseries, and could take 5% of the mobile handset business, and a really hefty chunk of the total profits, since Apple won't be selling any low-end handsets.

Are Cingular chumps for agreeing to these terms? Not really. They will look like geniuses for seizing what will be one of the very few opportunities to move a couple million subscribers to their network. The strategic impact of iPhone on the mobile industry will only be felt once the product exists in millions of units, and it will be spread throughout the industry. Apple will be free to set pricing of handsets, and will be free to operate a parallel commerce channel on a parallel network. No other handset maker has ever taken as much away from a negotiation. Even Qualcomm would be jealous of that kind of leverage.

What about the impetus – defending against mobile phones that are also media player? It sure looks like iPhone is a solid defense. But is there really a threat to defend against? Apple will sell more than 100M iPods in 2007. That is about one tenth the number of mobile phones that will be sold. The iPod market is now too big to be “crushed.”

Those engaged in building a mobile phone-based music business will have to contend with a fragmented handset technology and m-commerce landscape. Only Qualcomm and, perhaps, Nokia have control over enough of that landscape to mount a challenge, and to do it comprehensively from e-commerce channel to handset. On top of that, a mobile music challenger will have to use the mobile data network to deliver content of similar quality to that available on iTunes. And on top of that the prices will have to meet iTunes prices. Being able to buy on the go, out of WiFi range, just isn't enough to justify a higher price.

By the time a mobile music challenger really gets going, Apple will have new iPhone models on the market, and will be on the way to taking 5% of the mobile handset business and not just defending itself against the mobile music business, but being the mobile music business.

A Brittle Monopoly, a Fragile Revolution

Vista will have a broad-based launch soon. Unlike the launch of Windows XP and Windows 95, buyers won't be lining up outside stores to get the first copies. Vista is late, and Vista benefits are uncertain. This uncertainty was not helped by Microsoft's longstanding and widely publicized fascination with DRM – the benefits of which were seen by customers as ranging between dubious and toxic.

The other recent Microsoft product launch – the Zune – did not add to Microsoft's momentum. Zune is a geeky, awkward device that adds DRM to your own rips. It is promoted by an ad campaign with an obscure and awkward strap line that feels like something out of a “your brain on drugs” ad. And then there is the “squirting.” Oh, the squirting.

With all the bad news about Microsoft, you might be shocked to find statistics that say that 90% of the installed base of PCs are running various versions of Windows.

One can argue that the number is flawed. But the numbers that all add up to around 90% come from various sources, with diverse methodologies, such as retail sales and Web-site visitors. So 90% can't be attacked as a static measure, or one that is skewed by showing only one kind of computer user.

Another measure that suggests a near-monoculture of Windows is that viruses and spyware are almost exclusively targeted at Windows. Or, look at a catalog: Even the catalog of a “hobbyist-friendly” outfit like Micro Center has, maybe, 3% of desktop PCs with Linux. The rest run Windows. 0% of laptops come with Linux installed.

All indications are that personal computing still at the very narrow end of the wedge of restoring diversity in end-user operating systems. This is a movement that could be crushed or turned back. It certainly has not become strong enough that it is certain to survive.

However, when change comes, it will be sudden. Either Linux will be banned as too subversive for society, law enforcement, and content publishers to tolerate outside of Web servers and embedded applications, or Windows will precipitously fall from its position of near monopoly in the installed base of client operating systems, driven into retreat by the polish of Apple's MacOS and the freedom and democracy of open source.

The reason that change will be abrupt is that the Windows monopoly is brittle. It is brittle because it is based on hegemony in licensing to manufacturers, and on taking the content publishers' side in promoting DRM even as publishers become more strident, restrictive, rent-seeking, and litigious in their view of how content can be used by consumers.

This isn't the road to general popularity, much less is it the way to keep opinion leaders on your side. Any customer that is smart enough to be aware that their computer is going to rat them out to content publishers (and who knows who else) resents it. While most consumers are unaware or apathetic, opinion leaders are almost uniformly against DRM. Microsoft failed to grasp early opportunities to show DRM could be used to secure users' documents against misuse. That might have shifted the argument to something closer to a balance, but as it is, DRM is purely a source of resentment, without identifiable benefits.

Microsoft also appears to have a tin ear for the resentment against DRM. Apple is praised for pushing DRM mostly out of sight, while Microsoft is in the news for completely embracing DRM to the extent it is fundamentally changing the nature of a personal computer from a machine the user controls completely to one that is outfitted for surveillance and control by publishers (and who knows who else).

But all that does not mean that the Forces of Good will triumph. It does mean that the conflict over free and open software will be sharp and full of rhetoric about how free and open software is the tool of drug kingpins, terrorists, and pornographers. This rhetoric, and laws that make general purpose computing and communication tools contraband, will be used against free and open software. It will be used to hang the threat of liability over computer makers in order to maintain license hegemony.

Is Microsoft's share price stagnation and Microsoft's position for DRM linked? Before answering that, let's also ask if there was a different corporate culture at Microsoft when it was in ascendancy.

Microsoft's success was based on providing an inexpensive, off-the-shelf computing system that was good enough to replace many expensive minicomputer and mainframe systems that held customers hostage to high maintenance fees charged by hardware and software vendors. For those who could not afford minicomputers, Microsoft's software used to be the tool the little guy could use to level the playing field.

When Microsoft was on the way up, they were breaking eggs and making omelets. They were making other companies' products obsolete, and delivering high value, and driving companies like Wang, Digital, and Data General out of business. Now they are in the business of preventing the RIAA and MPAA dinosaurs from shuffling off to the tar pits, preventing corporate computer users from doing anything their IT department does not approve of, and preventing you from knowing everything going on inside your computer. That is, Microsoft has gone from selling creative destruction, to preserving obsolete business models, corporate IT controls, and facilitating content publishers' and others' intrusions into your use of information.

Does this mean Microsoft is doomed? No. Microsoft has thriving businesses in appliance devices like mobile handset software and game consoles where customers do not expect – yet, anyway – to have full control over the device. Microsoft's Office Communications Server is a dagger at the heart of the PBX business, and very much fits the model of the ascendant Microsoft. These parts of Microsoft will grow rapidly in the coming years.

It does mean Microsoft is in a vulnerable position on the consumer desktop. Like GM that can't compete with BMW quality or Hyundai price, Microsoft Windows is becoming a product only for those that don't care about having something better: Apple will be the choice of customers that can afford Apple, and Linux will be choice of those that value a true personal computing experience. Microsoft will be left with the sort of people who still buy Buicks. On top of that, depending on the extent to which DRM becomes visible to end-users of Vista, Windows will also become a product for people who don't care about not having Big Brother Inside. That may sound like an extreme comparison, but there was just recently a time when it seemed like GM could go on selling Buicks forever, too.

To really turn itself around and gain a path to new growth, Microsoft has to say no to the content publishers and say yes to end-users' concerns about privacy and control over computers and content they buy. But I don't expect Microsoft to do that until the message is written in declining market share and further stagnation of the company's value.

Writely or Wrongly, WebOS is Coming

Predating the first Internet bubble, there was the applet craze: It was thought that software would be delivered through the Web, on demand. Java was riding high on this fad, and lost a lot of credibility when the immaturity of Java technology (i.e. the unsuitability of AWT for making big, rich UIs on PC clients), low Internet connection speeds, high bandwidth costs, and Microsoft’s adverse reaction to hosting a potentially undermining technology in the bosom of their desktop OS, worked together to make applets less of the big deal than the pundits made them out to be.

Microsoft was able to contribute to blocking this disruption, but was not able to directly counter it or provide an alternative. .NET, like Java, became one of those dull gray tools of the IT crowd – a means of making multi-tier software systems without the hassle of understanding the complex threading implementations needed to make a middle tier that can serve thousands of users. This, despite the fact that .NET implemented code-behind-HTML and other features that made it quite a good tool for delivering user interface in Web pages.

Web hackers – the sort that don’t program in Real Languages like C# and Java - who never got the memo about server software, kept plugging away at making the Web user experience better.

“Better” means escaping the UI-as-form-filling paradigm that gave the Web a plodding, oppressive feel any time user input was required. The Web was born a hypertext system. Accommodating interaction beyond that required for hypertext is something that should be unsurprising in its difficulty.

Mapping MVC architecture onto multi-tier Web applications is not easy. In Web applications, the model is usually a relational database. The view is projected by middle-tier through a Web browser, which may include client-side code in Javascript. This complexity, and the hypertext heritage of the Web browser keep sucking Web UI back to a series of forms to fill out.

A rich Web user interface has to be debugged across multiple tiers, and, in the case of Javascript, across the client-to-middle-tier network connection. So, most Web UIs fail to grasp how to bring a consistent and highly interactive experience to the user and settle for the equivalent of what passed for UI back in the days of DOS, but with a prettier layout.

For an idea of the size of this problem and the value of simplifying the solution, take a look, on the one hand, at Enterprise Java Beans, even in its much cleaner 3.0 implementation, and, on the other hand, Ruby on Rails, which epitomizes the Web 2.0 ethos of productivity over universality. By focusing on solving exactly the above specific problem, which, while narrow in scope, vexes a large number of application developers, Ruby on Rails struck a very resonant tone, and has made an impression beyond the number of projects that actually use Ruby on Rails.

Ruby on Rails belongs in a spectrum of technologies we can call “Web OS.” Web OS is a system for running and building applications that run on Web servers and are used through the medium of a Web browser. Ruby on Rails is at the “building” end of the spectrum, while application suites like Writely, Gmail and Google Calendar, that have Web services interfaces but no SDK, are at the “running-only” end of the spectrum (although you can be sure Google has an impressive set of tools for their own coders).

We will soon see a lot more Web OS attempts, and, hopefully, some successes. Success, in this context, means making it possible for a large number of coders – not just those with Google's resources for toolsmithing – to create and run rich Web-based applications that truly break free from the “screen A -> screen B -> screen C” model of UI misdesign.

Whatever you may think about having your documents live on a server and editing them with tools that also live on servers, the WebOS future is likely to provide some interesting results: One easy prediction to make is that the mash-up culture will spread to all manner of applications, whereas the component document technologies that were supposed to put a spreadsheet inside your word processing document never really delivered. Maps, communication, auctions, translation, etc. will drop into Web OS documents naturally, because the data and communication that animates these document mash-ups will be available and compatible.

This is what makes Web OS interesting. If it stopped at implementing MVC applications in a particularly challenging implementation environment it would be only a technology curiosity, and probably not enough to motivate investment. But Web OS applications really can be better.

It's a good thing developers of these applications were never told how hard that is to do.

The Model-View-Controller Design Pattern and iPod-like User Interfaces

In my previous blog entry I asked whether the iPod is an example of a new user interface paradigm, and concluded that it is. This time, I try to provide more of the nomenclature for describing user interfaces of this type.

Discussion of desktop user interfaces is much aided by the desktop metaphor conceptual framework, augmented by the MVC (model-view-controller) design pattern. The desktop metaphor describes how overlapping graphics contexts give rise to on-screen windows that mimic the look of overlapping pieces of paper. MVC provides a design framework for (potentially) multiple views of the same data to be present on the screen and to stay in synch as the underlying data changes.

Together, the desktop metaphor and MVC are the foundation of nearly every non-trivial desktop user interface. iPod-like user interfaces discard the desktop metaphor. Overlapping objects are out of place on the iPod. They have no metaphoric meaning, and the screen is too small to give overlapping objects enough visual context.

In the desktop metaphor, each window is a viewport into a two-dimensional document that extends, mostly, above and below the view the viewport provides. In an iPod-like user interface, the whole of the screen is a viewport into a document consisting of a network of nodes. And here is found an interesting connection to the desktop metaphor: Most document data models are networks of nodes: Web browsers’ data models of Web pages, for example. The iPod, therefore, achieves an elegant presentation of a document by being one step closer to the type of data model used to model many documents.

The iPod shows that MVC is not inextricably linked to the desktop metaphor: The iPod has a model, a view, and a controller, although each is simplified: The model doesn’t change until iTunes changes it, the view is a full-screen view of just one set of nodes which all are children of the same parent-node, and the controller provides no means of editing the content of nodes.

Not every element of the desktop metaphor is a success. The desktop metaphor is plagued by an innovation known as the dialog box. The dialog box is familiar to most users, and in its most florid examples brings no less joy than a long session of filling out tax forms. The dialog box was a feature, used sparingly, in early desktop metaphor user interfaces, to put a pressing matter in front of the user, in situations where the user could not proceed without at least acknowledging the matter, e.g. a serious error. Since then, user interfaces have experienced a metastasis of the dialog box as mediocre designers, armed with visual dialog box layout tools, have attached numerous multi-tabbed tumors to software. Pre-AJAX Web user interfaces brought the dialog box to its pinnacle of dominance: If you have ever filled out a multi-page “registration” for some Web site, you know it well.

The iPod does without dialog boxes, not least because text entry on an iPod would be brutally hard, but also because dialog boxes, like other overlapping elements, have no good visual representation on an iPod-sized screen. The lesson embodied in the desktop metaphor’s encrustation of dialog boxes compared with the iPods lack of such goiters is that designing the direct manipulation of the data model is hard, and widgets, dialogs, and menus are easy. The iPod escapes this damage by being an environment that is hostile to the concept and implementation of dialog boxes. The iPod is also a browser, not an editor, and therefore manipulation means viewing, not modification.

Can this simplified MVC user interface survive being extended into providing a first party call control user interface? Or a mobile commerce interface that brings iTunes Music Store into a connected iPod? While these are not small design challenges, there is reason to think this simple and elegant UI paradigm can encompass new functions without losing its qualities: First party call control is not document manipulation. It has its own very severe challenges, but it should not require a fundamental shift away from the iPod user interface. Similarly, shopping can be thought of as a series of database queries followed by the user browsing the results. This, too, should be possible to implement in the iPod paradigm without warping it out of shape. These examples are not randomly chosen: If there is to be a wirelessly networked iPod that includes a PLMN or VOIP telephony subsystem, these are the major components that would have to be added to the iPod user interface.

The iPod can also be categorized as a “one-handed” UI. One-handedness is also linked to the lack of overlapping elements in the iPod UI: If you don’t have a pointing device to access overlapping elements the way you would access papers on a desk, you should not have them in the UI. Failure to heed this distinction between one-handed and two-handed UIs leads to such kludges as “two level focus” and other severe compromises that are inherently incomprehensible and inexplicable to users. For examples, you can look to any mobile handset HTML Web browser that attempts to map the two-handed PC Web browser human interface to a one-handed handset interface. Microsoft still struggles to fully reshape the two-handed Windows CE user interface – which is a fine user interface if you assume the user is holding a stylus – into a friendly one-handed UI for mobile phones. Two handed UIs allow rich and ambitious interfaces, while the iPod’s strict observance of what the user’s thumb is capable of leads to an entirely different result.

The iPod, therefore, can considered to be a full-fledged example of a distinct user interface conceptual framework. It has all the characteristics of the consistent application of such a conceptual framework to an implementation. Graph or network traversal, one-node-at-a-time views, mapping of architectural aspects to the MVC design pattern, and extensibility to other application domains put the iPod UI alongside the desktop metaphor as something that we will likely see more of, in other types of devices, applied to other domains.

A Mobile User Interface Paradigm

The iPod has popularized a user interface style: side scrolling navigation of a hierarchy. But is it more than a style? Does the iPod point to a paradigm for small-screen user interface the way that Macintosh popularized and formalized (through Apple’s fascistic insistence on user interface standards) the desktop metaphor?

The iPod interface is not original, and the USPTO has thus far ruled it isn’t novel. Creative Labs and Microsoft both hold related patents, and a hierarchical user interface is fundamentally unoriginal. But, as with Macintosh, taking a good idea more seriously than one’s competitors has given Apple the leading position in establishing the iPod user interface as the best example of a new paradigm.

That new paradigm can be summed up as “node by node visualization of taxonomy browsing.” Evidently I won’t go down in history as coining a new moniker as succinct as “desktop metaphor,” but the concept of taxonomy browsing on a small screen deserves almost as much exposition as the desktop metaphor in order to explore what it can do for small-device user interface.

On the iPod, the taxonomy is composed by iTunes and downloaded into the iPod. The iPod user browses the taxonomy node by node. That is, only one node of one taxonomy is viewable at any one time. That sounds rather unattractive, for a couple reasons: First, it comes off as limiting. Who would not want to see more information if they could? Second, “hierarchy” has become a bad word. Search-based file browsers on PCs are happily burying one of the worst user interface ideas ever created in computing – the file hierarchy.

And yet, the iPod is clearly a brilliant user interface. How does Apple turn limitations and what seems to be an out-of-style idea like hierarchy into user interface gold? With two broad approaches: First, accept limitations. Do not strain to deny them. Second, work to create the best user interface within the limitations. Much the same could be said about the difference between Lisa and Macintosh. Lisa did not accept limitations. Consequently, it was slow, and it highlighted the limitations of the Lisa platform. Macintosh accepted tighter hardware limitations than Lisa, and did what was needed to provide an excellent user experience within those limitations. Apple, in the person of Steve Jobs, and institutionally, clearly remembers those lessons.

In the iPod, limitations are ameliorated by the perfect interplay of the physical user interface and the “trail of crumbs” browsing interface. It enables the user to access one branch of a taxonomy so easily that the one-node-at-a-time limitation of the view into the taxonomy is no burden. In fact, compared to more-conventional taxonomy browsing interface of iTunes, it is a model of clarity.

Is this really a paradigm? Is it applicable to domains outside of music taxonomies? With specific examples thin on the ground one has to drill into the paradigm to come up with an answer. Here, I will state that answer in the form of how iPod-like taxonomy browsing fits the model-view-controller architecture for user interfaces: If the model is static, or nearly so, and if the model can be created from some interaction outside the hierarchical view system, such as the iTunes database, or some other database query, and if the results of that query form one or more taxonomies of categories, with nodes of manageable size, then taxonomy browsing iPod-style is a valid paradigm. Speculating on what kinds of applications fit this description, one can think of social networks, heterarchies like semantic networks (such as the CNet semantic network of news stories), and even first party call control interfaces, which I have seen implemented as a menu hierarchy attached to a tray icon.

I think this is enough to define a taxonomy browsing user interface paradigm, and test that node-by-node visualization and trail-of-crumbs forward/backward linking are a good visualization of that paradigm. I did not delve into physical UI and controller design, and it may be that the iPod wheel is key, but I will assert it is not, and that the mobile handset dpad is sufficient (perhaps this will emerge as a single-button versus multi-button mouse theosophical topic).

Now how about some iPod phone rumors!

Why Mobile Java Has Not Converged on Compatibility

The number of mobile handset users has surpassed 2 billion. About 650 million new mobile phones will be sold in 2005. With the rate of Java-capable phones as a percentage of new phone sales climbing toward 70%, far more mobile Java platforms are sold each year than PCs . Yet the state of non-game mobile applications is primitive, sparse, impoverished in user interface, and lacking in broad handset compatibility.

Mobile games are flourishing. Mobile games are modified – ported – dozens of times in order to run on dozens of handsets. That’s no way to make enterprise software, and the mobile game industry can support this practice only because most mobile games have no life cycle – they are not maintained or updated once they are released for a specific handset. If every time an update was released for a product the porting process would start all over, such products would never be economical or manageable.

It isn’t for lack of effort: Current J2ME standards show considerable progress over the MIDP 1.0 API standards. MIDP 2.0 provides easy standardized access to multimedia capabilities, an elegant and consistent connectivity model that spans connection-based networking, HTTP, and store-and-forward connectivity, and a form-based user interface system that enables custom UI widgets within a framework that abstracts display and input method differences.

Still, the mobile application environment has nothing like the application compatibility provided by PCs.

There are two main reasons for this:

1. The J2ME standards are correct without being right. They are lawyerly in their concision. They can be defended as providing all the necessary definition – the contract the implementers must fulfill – and, yet, demonstrably they do not deliver a consistent target environment in practice.
2. There is no body of applications to help identify slovenly interpretations of the MIDP 2.0 spec. The makers of compatible PCs had to show practical compatibility. The makers of J2ME implementations only have to smuggle their cruddy TextField and CustomItem implementations past a validation suite that cares nothing about the quality of presentation to the user.

Perversely, the lack of a practical compatibility test prevents the growth of a corpus of applications that would form that test. IBM’s PC attracted hundreds of applications that were being expanded and updated with an expectation of compatibility across IBM’s PC product line and new models before the first compatible clone appeared. These applications formed the basis of a practical test for compatibility. Mobile application compatibility has neither chicken nor egg.

Mobile search is one of the first areas where a mass-market application has to overcome the compatibility limitations of J2ME. Mobile search client applications will have a lifecycle. They will be updated. They will be released into a environment where it will be impossible to exhaustively test on every new handset. In short, they have to make the leap from the J2ME environment that is barely tenable for games, all the way to making it work for a mass-market product.

This won’t be easy, and many mobile search developers have concluded that J2ME is not ready to support such an ambitious application. They have stayed with presenting a user interface through the WAP browser, or they have started with smartphone platforms like Symbian and Windows Mobile as a basis for mobile search applications.

One problem with the latter approach is that Symbian and Windows Mobile phones constitute a narrow sliver of the market. There is also no great support among network operators and manufacturers to push smartphones. There is no distribution channel for large smartphone applications that must be installed from a memory card. Customers don’t know what benefit smartphones bring, and all the popular features like cameras, video, and mp3 music are available on inexpensive phones that do not tout themselves as “smart.”

The opportunity is in the billion or so Java-enabled phones that will be in the installed base by 2008 – within the next two or three product cycles for application development. If any mainstream phone will be “smart” by current standards, it will be mainly due to the price of hardware declining to the point where, for example, Nokia Series 60 phones become cheap enough they can come free of charge with a postpaid contract of a year or two.

So, can you just hang back and wait for the mobile application situation to fix itself? Only if it is satisfactory to see a billion people running around for several years not using your software. With numbers as big as they are, you have to try. So, what can you do?

You can:

• Use the available tools. As imperfect as the MIDP 2.0 UI tools are, they are better than rolling your own, which cuts you off from platform-specific input methods, like voice input, that are accessible only through the built-in UI widgets. MIDP 2.0 forms enable custom UI widgets with convenient interfaces to keypad and stylus inputs, focus management, and repaint management. Add custom widgets to your application to create powerful and distinctive user interfaces within the MIDP UI framework.
• Build tools where appropriate: While CLDC and MIDP 2.0 handle UI adequately well, and networking and multimedia quite well, they fail to address many practical issues in creating serious applications. Script-driven testing, logging, and update management are areas where you are on your own. Take the time to design these capabilities in harmony with the basic capabilities of J2ME.
• Write once, test everywhere, fix portability issues as if they are bugs – which they are. Don’t “port.” Compatibility is within reach, although it may not seem that way when first you begin to test an application across multiple KVMs. The numerous issues you will discover will make you want to give up the pursuit of compatibility and adopt the game publishers’ approach of creating a “port” for every handset. If you persevere past your first handful of handsets, compatibility on subsequent platforms will come easy, and by the time you are done with testing on 15-20 handsets, you will have achieved compatibility on dozens of handsets.
• Test everywhere, and use the update tools you built to keep your handset compatibility footprint growing. You will perpetually find new issues. But if you successfully fit the solutions to these issues into a single widely compatible build, you will have the ability to update your applications quickly and with minimal pain. This is the payoff: When you achieve wide compatibility, your next major application rev will ship with accessibility to the most customers, with the least support burden, and it will ship more quickly than your competitors’ applications. If you succumb to the port-per-handset approach, your rev 2 launch will suffocate under the load of porting, testing, and release management.

There is a reward for the first developers to cross the compatibility threshold in mobile Java applications. First-mover advantage in complex mobile Java applications is available, but hidden behind layers of challenges. If it was easy, everyone would be doing it.

Why Everyone Won’t Succeed

Most people in the daily drive to get the job done focus on what it take to succeed. So I was caught off guard when I was recently asked “Why will some efforts at mobile search fail?” Of course, most such efforts will fail. And they will fail despite being funded by VCs that hate to fail and that put a lot of effort into picking a high quality team that hates to fail. That team, in turn, will work very hard to succeed.

There are general answers: there isn’t room in the market for all the ventures that enter it to succeed; some will be undercapitalized, some will fail due to project risk. But those are unsatisfyingly unspecific answers. To provide a really good answer to why most attempts at mobile search will fail, the answer must, at least, carve out a slice of the problem space, and it must say how this kind of answer applies to mobile search, and how it does not apply to startups in general, or search in general. I find that there is a fairly clear and informative answer to why some people – and I aim to make sure this means “other people” will fail: Mobile search is a classic case of interdisciplinary development.

Unified messaging, the focus of a company I started many years ago, was also a case where mastery of two very different disciplines was required. Then, as now, however, the difficulty of integrating across two disciplines where you will seldom find experts in both is hard to measure, and is often not taken into account in measuring the ability of a venture to capture and defend a position in the market. That is, this is both a hidden danger and an underappreciated quality.

It is, of course, easy to enumerate the features of voice mail, and of email, but, as evidenced by the implementations, most attempts failed to integrate the two correctly. Successful implementation of the idea of unified messaging required insight into the direction – not just the current position – of voice processing and messaging systems, mainly in the area of emerging APIs and standard interfaces, and it required integrating this knowledge right through to the business model and business development strategies. Even Active Voice, which is widely regarded as the exemplary case in unified messaging for having the best integration to messaging standards, did not until fairly recently, when media gateway nodes displaced voice processing cards as the interface point, fully abstract hardware from the unified messaging system.

In hindsight is it fairly clear: unless you see where messaging and voice processing are going, you can’t position yourself correctly among your technology providers and channels. There is no obvious choke-point here – no way to deny a competitor who has figured this out access to the same partners and channels, so this isn’t widely seen as a differentiator. But the fact that so few entrants to the unified messaging field got this right means that interdisciplinary integration probably is a significant advantage that some ventures will wield with strong effect against their competitors. Not all ventures share this attribute, so there is probably something to be learned about building a venture where interdisciplinary integration is a requirement for success.

Mobile search is, if anything, a more difficult problem than unified messaging. At least three major distinctive areas of competency have to be integrated into a successful system: Mobile applications development; search; and IN (intelligent network) application development. These areas cannot integrate simply by gathering competent people in each. In fact, you will be hard-pressed to find compatible minds that have deep experience in each area, and that know how to reshape their own areas of expertise to fit with the others and extract the highest potential from the combination.

By “compatible minds” I mean people that can flex to fit the requirements of interdisciplinary innovation. Failure to flex means failure of the whole enterprise: mobile game coders will often fail to find the discipline to create an ambitious mobile application that works reliably. Symbian coders will fail to see that J2ME is an adequate platform, and that broad platform reach can be available through J2ME. Those steeped in search might fail to adapt to the limitations and opportunities of small-format presentation. And IN-experienced engineers can be too much in the telco mindset to integrate with anyone else with a more entrepreneurial world view. If the executive leadership of such an enterprise cannot encompass all that enough to evaluate if it is coming together or not, chances for success are diminished. If the participants reach only a minimal level of compatibility and fail to reach for ambitious goals in every distinct area of competency, the result will be easily matched and exceeded by competitors.

It can all be boiled down to four points:

• Only a small subset of ventures require innovation and audacity across multiple disciplines, so it isn’t a familiar problem.
• Apart from recognizing that some of these ventures are execution plays, VCs find the value of interdisciplinary innovation hard to measure.
• The participants in these ventures have to be inquisitive about each other’s domains of knowledge, and be able to seek innovation near those boundaries. The more dimensions to the problem, the less likely it is this will happen.
• The leadership, at the stages of founding, funding, and operating the enterprise have to be cognizant of their situation and act to make an interdisciplinary venture work.

But even simplified to this degree, interdisciplinary ventures are more complicated, and therefore more risky, than simpler plays. They are all the rarer in that, even when they are recognized it may only be to avoid them.

Interfaces Again

Early in my career, I wrote a book on Macintosh programming. Having worked on LISP workstations, I had used, and coded, graphical user interface programs, on one of the earliest systems to put a lot of effort into providing the tools to create a visual user interface. I was drawn to the Mac by the fact that a $3,000 computer could do what a $100,000 workstation did, and provide a much nicer look and feel. It was the first instance where I had seen, in depth, the benefits of balancing the effort that went into a GUI toward providing a pleasing user experience. The Mac was also a marvel of design compromise and implementation expediency – if it hadn’t been, it would have cost like a LISP workstation. Few now remember that the Mac was Apple’s second try. The Lisa, uglier and costlier, came first.

“A ‘pleasing’ user experience? And compared to what?” At the time, those were novel questions. The desktop metaphor design pattern and underlying architecture of multiple graphical contexts were solidly in place by then, but Steve Jobs was the first to get it right. The Mac had an interface that was up to standards that could be analogized to professional print layout design, while retaining all the structure of the desktop metaphor and windowing graphics system.

Since that time, the desktop metaphor got deconstructed into something more like the rock and roll magazine metaphor, as Web hypertext interfaces became the dominant area of interface design activity (desktop productivity having been pretty much done to death). Meanwhile, Sun tried to turn Java into a multi-platform GUI system, and, as if to illustrate the difficulty, is only now getting to a satisfactory result with the latest version of Swing, which still has no substantial library of applications.

Today, we are replaying this phase of user interface evolution in miniature. The memory and processor resources of mass-market mobile phones are about the same as the early Mac systems. A cut-down version of Java has evolved, in its MIDP 2.0 form, a usable user interface system for the small-screen medium – something short of a windowing GUI system, but good enough if one takes a more free-form approach to UI presentation.

The commercial and design contexts of mobile user interface creation are very different from the coherent drive to a desktop metaphor productivity suite that propelled early desktop GUI efforts. Mobile handsets have terrible user interfaces. Many mass-market phones don’t even try to have a good UI. Nokia’s Series 60 and Symbian UIQ are in danger of becoming obsolete before they fully evolve, having developed on too-limited platforms, and lacking a modern garbage-collecting implementation language. Windows Mobile is a very credible effort, with a long life ahead of it, but it suffers from Microsoft’s failure to develop momentum for Windows Mobile and of the curious and persistent incompleteness of the .NET Compact Framework to encapsulate all the platform APIs and become the unequivocal choice for UI implementation on the Windows CE platform. BREW, like Symbian-platform UIs, is stuck with C++ and an API that is inferior to the mobile version of Java, but BREW, at least, has been explicitly targeted at providing a customized user experience in Qualcomm’s new UIOne initiative.

Any serious effort to create a widely used GUI on mobile handsets has to encompass Java, BREW, and Symbian, and it has to provide a road map to cover Windows Mobile, Palm, RIM, and Linux-based 3G and VoIP handsets. It has to be designed in the context of present realities in handset hardware content, likely new applications like mobile video, and one-handed operation where the thumb – the least dexterous digit – is made to do all the work.

The Web has influenced UI design again. This time it isn’t by deconstructing the UI into an interactive hypertext Web, but by being the place where user interface has evolved toward search being the starting point of interaction.

So this is the environment into which my current effort at creating an ambitious non-game mobile application is launched. Compared with desktop GUI applications, the evolutionary stage of mobile platforms makes things more challenging: more variation in the platform. More technologies to understand. A necessarily multi-platform implementation. Fewer design rules, and certainly no Steve Jobs and his salutary UI fascism, but in a world with a lot more interactive design sophistication.

Success requires remembering this evolutionary context and using the analogies it provides to navigate the new challenges. Those new challenges, and the solutions, will write a new chapter in UI design.

After Games

I am no longer working at a mobile game company. Not because I became disillusioned with mobile games – I’m still advising people and companies in the mobile games arena. But the mobile games train has left the station. The time for startups in mobile games – at least until some fundamental shift occurs – has passed, and acquisitions and consolidation are a big part of mobile game news these days. I look forward to Kayak more-fully realizing the potential of the products the Chasma team created.

Mobile games transformed my view of a new vehicle for applications delivery. And, while mobile games are now a battlefield for larger companies, new areas of non-game mobile applications are opening up. The same low-friction channels and staggering numbers of mobile customers will do for mobile search and rich forms of mobile media what they did for mobile games. In many ways, the landscape is like that of mobile games three years ago: the technologies and delivery vehicles are there, waiting to be adroitly exploited.

Even more exciting than the mobile games business, where m-commerce and billing-on-behalf-of were the keys to making large piles of money from simple products, the business model for new fields like mobile search is still malleable. Stunning breakthroughs is business strategy will unfold alongside what are likely to be the most sophisticated mobile applications ever created.

Mobile search holds the key to a shift in the mobile telephony user’s usage patterns that is far more powerful than features like push-to-talk that, up to now, form the basis for differentiation among mobile service offerings. It is an exciting time in mobile applications that will reverberate through the whole structure of the mobile network.

To take but one example: Mobile video will be used in ways fundamentally different from the way people consume broadcast video. Substantially all of mobile video will be an on-demand, time-shifted, TiVO-like experience. So the grid-like schedule table that is a staple of cable TV user interface will be inadequate for navigating mobile video. In an on-demand world with an infinite content library, search is likely to be the first step every user takes on the way to the video they want to see.

Google’s brilliantly simple user interface has conditioned people to the belief that search is simple, because it is simple to use and delivers the right results so reliably. This is, of course, a misconstruction of what is, in reality, a subtle, deep, and complex system that happens to work very well. Even more than Web search, mobile search will tie together information sources from the mobile network, the Web, and numerous structured, specialized feeds into a product that appears simple, but represents a new level of sophistication in search, as well as breaking new ground in mobile applications.

This is going to be interesting!

Content Networking by the Numbers

Google has indexed, as of the moment I write this, 8,058,044,651 pages. Google also indexes about 1 billion images and about 1 billion netnews postings. In a masterful piece of S-1 filing divination, Tristan Louis estimated the size of Google’s computer infrastructure: 719 racks; 63,272 machines; 126,544 CPUs; 253,088 Ghz of processing power; 126,544 Gb of RAM; 5,062 Tb of hard drive space. You can find his research on the topic here: http://www.tnl.net/blog/entry/How_many_Google_machines.

Pretty impressive. Google users evidently think that Google finds what they are looking for. So, not only is Google large, it has successfully found what most users want to find. Google has made meta-search an anachronism. Few now have the resources to catch Google.

Any flaws? Some people complain that Google can be gamed. Others complain that Google censors. But the real issue is that Google indexes only a tiny fraction of the Web. This analysis - http://www.brightplanet.com/technology/deepweb.asp - claims that fraction is somewhere between 1/120^th and 1/620^th.

An interesting aside in Bright Planet’s analysis is that original deep Web content now outstrips printed content. Yes, the Web is now bigger than the printed word.

Bright Planet’s analysis excludes images from the size measurement of the un-spidered “deep Web.” So where do we look to get a handle on the size of multimedia content in the Internet? In this case, we can look to measures of Internet traffic – specifically P2P traffic.

The numbers are stunning: CacheLogic, a maker of traffic management and network intelligence (deep packet inspection) gear, found that P2P traffic ranges from 55% to 80% of the bits traversing the Internet (http://www.cachelogic.com/research/slide12.php). The Web, which is 120 to 620 times larger than Google has indexed, is only 5% to 20% of Internet traffic. A single movie or TV show can significantly drive traffic levels in an ISP’s network. Boggling, but what does it all mean? Here we can turn to the Eight Fallacies.

Topically, the Eight Fallacies were formulated by Bill Joy, Dave Lyon, Peter Deutsch, and James Gosling – some of the brightest of Sun’s luminaries – as Sun was formulating its approach to the mobile computing market. If you don’t pay attention to the numbers, you can fall into one or more of the Eight Fallacies:

• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
• There's a single administrator
• The topology won't change
• Transport cost is zero
• The network is homogeneous

It could take a book chapter to fully elucidate the meaning of each of the Eight Fallacies in the context of content networking. But the main point is that content is so big that the Internet will be designed around moving content. The Web is just the literate scum floating on top of an Internet that is rapidly evolving toward the post-literate masses. Never thought you anyone need those monster petabit routers? Think again. Asymmetrical last mile OK? Maybe not. Many other apple carts will be overturned.

What category of application will drive the next big shift in Internet traffic? Content networking will probably be a big part of that next killer app.

Not Exactly TV

DVB-H and MediaFLO are the two leading technologies used in digital mobile TV. Before we delve into these technologies, we will first address the fact that “Mobile TV” is an idea that spawns many questions. The more skeptical are quick to ask “Why would anyone want it?” A reasonable question, especially for the next few years. Ordinary broadcast television works in cars and on inexpensive handheld LCD TVs. Mobile digital TV starts by offering a replacement for something that is free to access with cheap devices, and for which there seems to be no consumer clamor for improvement.

Further increasing the challenge, mobile devices using DVB-H and MediaFLO will have to compete with the relatively high quality and low cost of portable and car-mounted DVD players. Owning a movie on DVD is simple, and DVD prices are reasonable – especially compared with recorded music on CDs. So both the product and the sales model are up against existing models that work well and where, again, there appears to be no popular revolt against the status quo.

Delving some way into the technology, there are further challenges: Both DVB-H and MediaFLO are “forward link only” technologies, hence the “FLO.” The return channel for control, m-commerce, interactive content, etc. is provided by mobile Internet capability in mobile handsets. This is a relatively complex arrangement compared with IP networks without such triangular paths. Augmenting the Internet by broadcasting content has never succeeded in other implementations, and mobile digital TV is, in both systems, relatively complex compared to other data broadcasting systems.

By now you may be ready to join the skeptics and ask “What are they thinking?!” Mobile digital broadcasting does solve some problems: For one, there isn’t enough bandwidth in 2.5G systems to deliver content to mobile handsets if, in fact, they become the primary device for accessing music and small-screen video.

There is also reason to think that datacasting will become part of the Internet, this time, for sure (well, likely, anyway): All of digital video broadcasting looks to become IP datacasting, and, as the name implies, DVB-H is a subset of the overall DVB standard, which has versions for terrestrial and satellite broadcasting. DVB-H could succeed by being an east-to-implement add-on to terrestrial digital TV broadcasting.

Then there is the fact that Qualcomm has taken the lessons learned from BREW and applied them to MediaFLO: MediaFLO will be sold as a turn-key solution for content delivery to mobile handsets. With BREW, Qualcomm learned that mobile network operators can succeed in spite of their often lumbering pace if a new value driver is handed to them on a silver platter. For CDMA technology users, Qualcomm controls the technology of MediaFLO end-to-end: from the transmitters to the chips to the software to the m-commerce environment (BREW, by the way). All that Sprint or Verizon need do is make the decision, and Qualcomm will control the pace of implementation.

The technology differences between DVB-H and MediaFLO are interesting, but unlikely to be conclusive in determining success. Qualcomm has also taken full advantage of end-to-end control in product formulation: MediaFLO is built with a bias toward providing the right solution, which is the delivery of media for time-shifted use. MediaFLO-enabled handsets will be equipped with enough storage to make time-shifted media use the norm. DVB-H, like most telecom standards, is oriented around providing all the abstraction layers and interfaces the members of the standards body desire. Product formulation is up to the implementers, and the implementers may be spread across multiple elements of the value chain.

So we have two technologies that can be the means to pour large amounts of mostly passive media content into mobile handsets. We also have a common motivation across all mobile network operators: to become an economic gatekeeper – to stand astride more transactions, and passive media consumption is a potentially large source of transactions that are paid for and consumed through the MNOs networks. These factors are up against the inertia of current approaches to consuming passive content that are accepted by apparently content consumers.

Why go to all this trouble? The problem for the telecom industry is that subscription voice service is an economic giant that makes media industries look small by comparison. To make data a significant part of the mobile telecom economy, MNOs and their technology providers will have to eat photography, games, music, a bug hunk of TV, and other media types for it all to add up to even 25% of the revenue from voice calls.

What if mobile media flops? What if consumers resist subscriptions for passive content, and resist DRM, and what if ownership of content on tangible media remains the preferred means of consuming? It could happen. All of mobile games and other mobile media are just an appetizer on the way to the main course: MNOs want all transactions. Media and games are attractive because they can be both paid for and delivered on MNOs’ networks, which enables the transaction fee to be larger. If it comes to it, MNOs will skip the appetizer and take their cutlery directly to the target: the credit card companies.

Mobile Entertainment: the Current Landscape

Some entertainment media are cast in stone: Cinema, television, game consoles, CDs, are all standardized media. Most of these media have no element of person to person communication. “P2P” is almost an epithet among content publishers. Viewed in this light, mobile handsets are clearly different: They are created to enable person to person communication, which is sold as a subscription service.

It is tempting, based on JAMDAT’s success, to view mobile games as games for little Game Boy screens, and to focus on the advantages 24/7 mobile commerce availability, OTA delivery, a staggeringly large market, and billing-on-behalf-of (BOBO – one of my favorite acronyms) confer on mobile games.

These are the simpler concepts, and the impact of m-commerce and BOBO is hard to exaggerate. However, leaving connectedness, the unique architecture of the mobile Internet, and the desires and motives of the mobile customer off the table is to ignore that mobile games are games for a communications device.

An overwhelming desire to communicate is what made the mobile network. IMTS, the immediate predecessor of cellular telephony, accommodated about 550 customers in New York City in 1976. A few thousand were on the waiting list for IMTS mobile radio telephones. The business plan for cellular telephony called for clearing out the backlog of orders and some upside beyond that. Nobody envisioned anything as grand as making the mobile handset something every human on the planet who can afford one will have.

The desire to communicate is the driver in mobile telephony that turned it into a business that benefited from hundreds of billions of dollars of investment in mobile telecom infrastructure, propelling it a thousand-fold past expectations. Forgetting to harness that force in mobile entertainment misses the essence of the mobile handset, and misses the core of customer motivation.

These are the elements of the current landscape:

• Mobile commerce systems that enable all mobile customers, creditworthy or not (i.e. postpaid and prepaid), to easily buy and pay for entertainment products at the push of a button. While the effectiveness of m-commerce user interfaces varies widely, they are in place in every developed and most emerging economies on Earth, and no mobile entertainment provider need worry that the lack of m-commerce stands in their way.

• Handset hardware platforms that are less capable than most handheld game consoles in graphics, processor power, and storage, but universally capable in anytime/anyplace Internet connectivity.

• Handset software platforms that have stabilized around two platform types: BREW and J2ME – three if you count Symbian – a manageable number, but that are still wildly fragmented into variants with different displays, memory, and audio, plus a variety of m-commerce APIs.

• Hundreds of millions of customers accessible through a relatively small number of channels. Some, like Vodafone and Verizon, have achieved Wal-Mart-like domination of m-commerce in their territories. But, overall, the advantage is with content providers. The terms for mobile commerce are most favorable in the most mature markets.

• Hundreds of millions of new handsets each year that both expand the number of customers and upgrade older customers into a mobile networkthat includes mobile commerce and entertainment platforms.

• An Internet that is at once populous and fast-growing, and limited in speed and capacity, and one with unique nodes for charging, routing, and delivering the last mile.

It is also worth mentioning something this landscape excludes: Entertainment servers. Ericsson does not sell game servers. They are not an infrastructure node. There will be no 3GPP standard for game servers. To the extent that mobile game technology differs form Internet game technology, it is due to the unique nodes, the unique architecture, the unique capabilities and limitations of handsets, and the unique user preferences of the mobile environment. Mobile game technology is different: One need only consider that the mobile Internet experience is not centered around the Web browser to see that the difference is very large. But mobile game technology is not telecom technology. Mobile game technology belongs to game publishers, not the MNOs, and it comes wrapped in products, not exposed through APIs.

Now that we see the landscape, the next step is to find sources of value.

This blog is about mobile entertainment and other mobile media.