Browser-Powered Television

[A longer than usual blog post, summarizing some strategy ideas I’ve been working on.]

In the early 90s at DEC, I had a colleague that worked with the cable industry.  I tried (unsuccessfully) to convince him that TCP/IP would be the winning network infrastructure for the fancy interactive TV services everyone was talking about.  In the end, “adequate general purpose” solutions always win.  Proprietary solutions can’t compete with economies of scale.

Moving up-stack, I’ve been thinking about how TV content delivery is going to play out.  We started with over-the-air broadcast, then shifted to cable (first analog, then digital), and now we’ve suffered through a decade or two of crappy set-top-box user interfaces fed from proprietary cable networks.  Along the way, our TVs have evolved from tiny, fuzzy CRTs to large, crisp 1920 x 1080 color monitors.

As household bandwidths have increased, we’ve got options that end-run cable companies to get content on the screen:  Apple TV, Roku/Hulu, Tivo, network-enabled DVD players, game consoles, etc..  But these are still closed & proprietary:   I can’t deploy my own apps (or even content, in some cases) without a lot of permission from other people.

On the bleeding edge, users are plugging their large-screen TVs into computers (the Mac Mini is a popular option), sometimes installing software like Boxee to provide a “couch-friendly” UI.  I like Boxee, but it’s only an intermediate step and feels like a response to the past.  Users don’t want “set top boxes” (STB) or “media centers” or “electronic program guides”; they want unrestricted access to apps and content.

And a general-purpose delivery mechanism already exists:  Web browsers.  As Apple demonstrated with the iPhone, HTML+JavaScript is an excellent way to get content on-screen, because it leverages a deep existing technology infrastructure.  (And adding Flash makes it even more compelling).

I’m betting the same will happen with TV:  HTML (and related technologies) will become the new “broadcast standard”.  I’m not talking about seeing Firefox’s File/Edit/View menu bar on your TV; I’m saying that content will be rendered by a full-screen browser engine using HTML+JavaScript+Java+Canvas+Flash+Quicktime+etc technologies.   Users will access any app or content they want by navigating to the appropriate URL.  (Innovators will adapt browser navigation to the TV screen & remote control, just like Apple adapted Safari for the iPhone.)

Here’s the test:  how hard is it to write Boxee’s UI or any STB UI as a full-screen JavaScript or Flash app?  Apart from accessing LAN content, it’s relatively easy.

I’m pretty certain this is how things are going to play out.  Now the entrepreneurial question is:  what to do about it?

URL Shorteners, WTF?

I’m sure I’m a minority here, but are URL shorteners (e.g. TinyURL) really a “business”?  Bit.ly raised $2m in funding for this?  What?

On the news that Twitter has switched URL shorteners, why isn’t Twitter doing this themselves?  Either by handling URL shortening directly, or even better, treating URLs properly with respect to contributing to the 140 char tweet limit.

I must be missing something.

Metered/Capped Broadband, Part 2

A few days ago, I wrote about the problems with metered/capped broadband in the US.

Then I read this article, which said:

Basically, the cable internet usage quotas have nothing to do with the internet, they are all about protecting the cable companies TV business. With any quotas in place, it is basically impossible to watch TV in an ‘average’ way over the internet. You can’t even get half of average at barely acceptable quality.

The article goes on to point out that the cap/metering issue is mostly coming from providers with a large, established proprietary TV cable network to protect (e.g. Time-Warner, Comcast) vs phone companies without any substantial TV network (e.g. Verizon).

This is the heart of it.

Metering Moore’s Law?

Since we’re partially dependent on Time-Warner Internet access, I’ve had to pay more attention to bandwidth caps / metered broadband issues.   See some recent discussions in GigaOM, and the Washington Post.

Generally, I’m glad to pay extra for using a resource with (a) real scarcity, and (b) in a truly competitive environment.  But neither of these apply in most broadband cases.

First, bandwidth demand is growing quickly, but Moore’s Law is driving network capacity.  Our first Internet connection was a 64K DDS data circuit costing $400/month in 1992 (about $600 in today’s dollars).  Now, 20mbits is $50/month (and for FiOS, that’s artificially limited from much faster underlying speeds).  With price/performance increases in server and switch capacity, it’s difficult for providers to argue bandwidth is limited and costs are growing.

Second, most broadband providers are not operating in a truly competitive environment.  Regulatory and licensing hurdles make it difficult for new competitors to enter many markets, allowing  incumbent providers to exploit their positions for better profit margins.  Stated differently, any broadband provider with true competition wouldn’t be talking about bandwidth caps.

Finally, it’s frustrating this issue has gotten so much mind-share, when we need to be heading in the exact opposite direction.   We need policy and investment that brings the US nearer to the top in worldwide broadband penetration.   History will compare our national network  infrastructure to the Interstate Highway System:  strategic investments enabling fundamental advantages in business, production, defense, innovation, and quality of life.

Off the Beaten Transaction Path

For Internet and mobile applications, the transaction path is like the West Wing floor plan around the Oval Office – power is measured by proximity.   The valuable apps are those closest to influencing a transaction decision.  Google is the strongest example:  many purchase events start in the search box, making AdWords an extremely important point of influence.

As you move away from the transaction path, value drops off exponentially, as demonstrated by the very low effective CPMs for many apps and properties (esp. when factoring in un-sold inventory).   This leads to a frustrating realization for many projects:  it’s possible to have significant user volume & activity, while generating very little value.  For examples, consider the challenges IM apps, Twitter, and even Facebook (to some extent) have had builting profitable businesses.

Bottom line:  it’s difficult to build valuable stand-alone businesses with ad-centric revenue models, if the app usage is not near the transaction path.

Twitter Feature Requests

My Twitter feature requests (for the Web interface):

  • First-class support for tweet replies/comments
  • Put the search box right on the page, upper right
  • Let me add “searches to track” on my page, that scroll along in little widgets
  • Provide a subtle visual hint (e.g. highlighting) where the tweet stack was the last time I visited

I’m sure these features exist in the various Twitter clients.  Twitter should be more aggressive about pulling in the best third-party innovations, as Google, Facebook, Amazon, and other platforms do.

(My friends know I can’t help myself from “product managing” others’ products).

Poor Design Drives Me Nuts

Driving home today, the FastLane toll (E-ZPass for the rest of you) flashes “Call FastLane”.

So I call and am prompted for entering my account number “from my statement”.  There’s no option to bypass, but after three failed attempts, it gets through.   Then I’m put on hold for a while, and then eventually it says “we’re closed”.

Unbelievable.

Truly great designs are hard, but rookie design mistakes are usually easy to avoid.  In this case, most FastLane users will learn there’s an account problem when they get a “Call Us” flash at the toll lane.  As such, it’s reasonable to assume that many (if not most) users will be calling from the car, without statements and without account numbers.   Therefore,  an IVR menu that requires an account number is an incredibly poor design.

This stuff drives me nuts.  It’s so avoidable.

Finanical Innovation: Built-in Compensation

I thought Krugman’s Op-Ed about compensation in the financial sector was interesting.  The one-sentence summary:  “I question the value of these financial innovations, and why are they getting paid so much?

Financial innovators have a huge advantage:  they build their compensation right into the innovation itself.  Find a place to take a percent or two (as risk-free as possible), and at scale you’ve got real money.

Compare this to (say) technology innovation:  getting paid is frequently as much work (if not more) than the original innovation.

iPod Touch: Finally Getting Some Respect

Since it’s launch, I thought iPod Touch was underrated and under appreciated.  The iPhone’s got the glory, and it’s easy to dismiss the Touch as a “fancy iPod”.  But it’s a lot of computing in a small and cheap platform:  8-32GB of flash memory, 128Mb of RAM, a great display and a 522 Mhz processor.  It’s got more power than many PCs from 10-12 years ago!

It was interesting to read about the Army’s use of the Touch for solider applications. I think we’ll see the Touch in more cases where the economics of a general-purpose, mass-produced hardware platform enable an app that wouldn’t otherwise work.  Could you imagine the Army making a custom-hardware Arabic translation device?

Also, my prediction:  Apple’s “netbook” competitor will be a large-format Touch with Bluetooth support.  Add Apple’s little wireless keyboard, and you’ve got a fine laptop replacement for many users.

The Writing Process that Works For Me

For writing, here’s the approach I’ve found works best for me, by far:

  • Clearly note the purpose & main points (1 to 5)
  • Write the first draft as quickly as possible
  • [Maybe] do a light editing pass
  • Set aside for an hour/day/week
  • Return, edit into shape, publish

Editing is where the real work happens, and I find it easier (and more enjoyable) than writing the first draft.  I’m a rabid fan of the Strunk and White School of Editing.