Embracing Chaos

There’s lots of hubbub about Apple’s upcoming tablet device, but the stuff people are talking about I’m not actually all that excited about.  A giant iPhone?  Sure, that’ll be nice.  A color e-reader that can run apps.  Okay, I guess that’s better than kindle.  A super-thin netbook without a real keyboard.  Meh.  Actually, I don’t know that I’d want one at all.  Unless…

Unless Apple has come up with a better way to do soft keyboards, that is.  When I say “soft keyboard” I mean the kind of keyboard that appears on a touch screen and has no physical keys.  I’ve complained about the iPhone’s keyboard for a while.  While it’s true that people do get better at using these, I still don’t think I’ll ever be nearly as fast or accurate (even with smart correction) with a soft keyboard as I was with my blackberry.  I think that’s probably true on average for most people.  The basic reason is the lack of tactile feedback.  With a physical keyboard, if my fingers are slightly off target, they are guided to the right place by feel.

I’ve argued for some time now that the way to solve this is by figuring out how to make a touch-screen display with tactile feedback.  How would such a device work?  Physically I couldn’t tell you.  But what we’d need would be a way to electronically manipulate texture in a clear material.  A plastic with a matrix of cells that could expand or contract under electronic control.  So the software could create bumps where each of the keys are.  This would allow a software-reconfigurable gadget that could be almost as usable as a dedicated-purpose device.

This is very different from what is commonly referred to as “haptic feedback” on some of today’s gadgets like the Nexus One.  Here, the phone’s vibrator pulses a bit when you press a soft key.  This is a kind of feedback which is tactile in that you feel it, and it gives you information about your interaction with the device without having to look at the screen.  It certainly helps.  But it is not going to improve basic typing for a critical reason — it can’t help guide fingers to the right place.  The basic act of positioning fingers on controls is still basically open loop, feed forward, without guidance.  What I’m referring to as tactile feedback helps the fingers find the right spots to press without looking.  Today’s haptic feedback can’t do that.

To be clear, true tactile feedback like this almost certainly doesn’t exist yet.  This kind of pure technological innovation basically always starts in universities or government run labs.  The ROI on pure research into unproven technology is so low that it doesn’t make sense for companies to invest there.  Even if a company proved this was possible (which AFAIK hasn’t been done yet) they’d need to figure out how to manufacture it at scale before they could sell a device with it.  Last time I predicted it would be about 2012 before we saw these.  Even though Jobs almost certainly foresees the value of such a system, Apple’s expertise is not in material science.  Wired speculated about such a keyboard based on Apple’s patent filings, but what they describe seems a bit too sci-fi for me to believe.

If they have come up with something new and cool, it’s going to be a smarter way to use basically existing hardware.  I’m gonna guess it’s probably something like a touch screen which is pressure sensitive, so you can rest your fingers on it without indicating a “button press”, making typing more natural.  You could combine this with fixed, transparent dimples on the screen under the positions where the keys are, and you’d do pretty well.  Restrict the keyboard to only work in landscape mode and you only need one set of dimples.  This would be a huge improvement in usability and the biggest technological breakthrough would be the ability to distinguish a soft push from a hard push on a capacitive touch-screen.  Like by how much surface of your finger is on it.

Regardless of what Apple’s actually managed to achieve, I wish them the best.  They’re really pushing the envelope on human-computer interactions.  If they’ve done anything significant to improve soft keyboards, they will have once again done something that the entire rest of the industry will want to emulate, and I’ll tip my hat to them.

My girlfriend has a kindle that she very much enjoys.  One of the biggest benefits from it she gets is having a large amount of content in a very small device.  She is a scientist who is very much an information worker.  Having access to a great many research papers in searchable form is very useful for her.  (If only the PDF import worked on multi-column papers!)  She also tends to live out of a backpack, so being able to have several interesting things to read at any give time is very appealing.

So she’s often reading her kindle on the bus.  She’s noted one interesting difference between reading her Kindle and reading a regular book while on the bus.  When she’s reading a normal book, people will ask her what booj she’s reading or will look at the cover and just talk to her about the book itself.  With the kindle the question is always "how do you like the gizmo?"  Which gets old after a while.

Here’s a suggestion to Amazon on how to address this social problzem: offer full-color PDFs of the covers of books that you purchase for the Kindle, so people can print out their own covers.  These could slide into a convenient holder on the Kindle’s attractive leather case.  Long-term it’d be great to have a color e-paper cover for the book, but we’re not holding our breath for that one.

I love my Toyota Prius.  I’m very grateful to Google for giving me
a financial incentive to buy a brand new car which does everything I
want.  It’s totally big and practical, it’s very high-tech, it both
supports and projects my values,
etc.  I could sing its virtues for pages.  But for now, I want to share
some non-obvious things about it in a series I’m calling "Stupid Prius
Tricks."  (With a tip of a hat to David Letterman.)  Several of these articles (like this one)
are complaints, but this must be taken in the context that overall I love the car.

The Prius’s High-Tech Safety Features

The Prius has at least a couple of smart traction control systems which use technology
to help maintain control of the car in difficult situations.  Of course
there’s anti-lock brakes (ABS).  In addition to ABS the braking system
does things called Electronic Brake-force Distribution (EBD) and Brake
Assist.  Beyond that, it’s got Traction Control, and in all but the
stripped-down cars something called Vehicle Stability Control (VSC).
What each of these features does, or how they differ from each other I
don’t know and don’t frankly care.  They help the car do what I’d want
it to do under good driving conditions when the road is slick or uneven
or I’m driving too fast or what have you.  All this is great.  But
there’s one subtle and very bad flaw in the implementation of at least
one of these systems.

The Stupid UX for these Features

When the Prius needs to engage one of its TLA control systems, an
orange light appears on the otherwise dark dashboard.  Sometimes a
sound will beep.  This is presumably done to let you know that the
fancy feature that you paid for is working on your behalf.  Call it a
marketing feature if you will, because there’s nothing you can do with
this information, or way to react to it within the vehicle’s controls.
The stupid thing about this feature is that it’s distracting to have
lights flashing and sounds beeping.  When you’re having trouble
controlling the car is the last time you want something distracting
you.  So the engineers at Toyota have done something completely moronic
– a complex system senses when you’re having trouble controlling your
car, and chooses that time to throw more distractions at you.  I’ve
observed the light and beeping  on when driving over bumpy roads, or
down
something very steep that has a rut in it, or when the back-right wheel
accidentally jumps up the curb.  None of these situations I’ve gotten
into have been serious or very dangerous.  But even still, they were a
bit confusing, and the confusion was confounded by having the car meow
at me demanding attention.  When the car is not doing what you expect it to, the last thing you want is additional distractions.  Bad choice, Toyota.  These features should be absolutely silent.

What you can do about it

If anybody knows a cheat code to disable this light or beeping, please
post it in a comment.  Until then, you can help a little bit by putting
a small piece of electrical tape over the orange light with the symbol
for "I think you’re losing control of the car."

Amazon has a history of facilitating disruptive change.  First by selling books online, they demonstrated the advantages of a well-run online store.  Then with music, movies and just about everything else, they have shown that centralizing inventory and customer experience allows for reduced costs and an improved experience over a traditional distributed retail model.  Today, Amazon Web Services is starting to disrupt IT operations similarly by providing a higher quality service at lower cost than most companies can manage themselves.  They achieve these scale economies through centralization.  With Kindle Amazon is attempting another disruptive change, this time in the way people read books.  Lower distribution costs give electronic “e-books” an intrinsic advantage over physical books, hinting that e-books are inevitable.  But will Kindle be able to “cross the chasm” and become a mass-market device?  Amazon’s complementary assets, scale and technology all make it likely that Kindle will succeed.

Several startup companies have sold e-book readers in the past, but none successfully.  Sony is the only other large company to have tried.   Assurance that a risky new technology is backed by a company that won’t disappear is important for mass-market adoption, giving Sony and Amazon an advantage.  This is especially important for devices that consume media, as the device’s utility dwindles without new content.  Amazon is especially well positioned to offer media for Kindle through its complementary assets.

Amazon’s established relationships with book publishers are extremely valuable to Kindle.  Book publishers control e-book content.  Amazon’s history of selling physical books has earned them the trust of almost every publishing house, ensuring easy access to electronic versions of books. In addition to existing e-books, Amazon’s scale gives them leverage to encourage publishers to release electronic versions of books.

Beyond that, Amazon has rare technology to make electronic versions of books available with far less work on the publishers’ parts.  Amazon has spent years scanning physical books to enable a feature called “Search Inside This Book” on their website.  Along with Google, they have one of the only large archives of scanned physical books in the world.  This enables selling e-books for books that publishers don’t even have original electronic copies of, with rights negotiations as the only remaining barrier.

Innovators have been jibbing together their own e-book readers out of laptops and PDF files for years.  Early-adopters look for concrete advantages like the ability to search books.  Med-students give Kindle rave reviews for this capability.   The easy availability and portability of dozens of books appeal to the small segment of truly voracious readers.  Kindle seems to serve these early segments well.  To cross the chasm into the mass market of the early majority, Kindle must make the experience simple and reliable.  Kindle’s wireless data connection sets it apart from all previous e-book readers.  By leveraging Sprint’s nation-wide 3G cellular data network, Kindle can load content without the operator even owning a computer.  Thus Kindle dodges the inevitable complexity that arises anytime a PC is involved.  This, along with Amazon’s well-established customer service, promise to make Kindle much easier for the early majority to accept.

Kindle seems well positioned for acceptance by the mass market.  If successful, Amazon will need to balance publishers’ need for DRM against consumers’ desire for open content.  The music industry has exposed these issues but certainly not solved them.

[This is another recycled homework assignment.  Something to keep y'all entertained while I'm in New Zealand!]

At long last, the world’s best digital music system has fixed a glaring UI hole.  With today’s release of v2.5 of their software, Sonos controllers (both hardware remotes and PC/Mac based software) can search for music by artist, composer, album, or track.  This feature works within your own local library or within music services such as Rhapsody. 

Up until now if you wanted to listen to an artist in Rhapsody that you hadn’t previously bookmarked, you would need to guess what top-level genre they were categorized under and then scroll through an enormous list to try to find the artist.  How many times have I scratched my head asking questions like "Is Pink Floyd Rock/Pop or Alternative/Punk?"  Much easier was to find a web browser, pull up http://www.rhapsody.com/pinkfloyd and bookmark music into your library.  That human-writable URL scheme is still one of my favorite accomplishments in the last several years.

I started beta testing this release last week.  As always, the update was fast, easy and works flawlessly.  My biggest complaint is that the search is not interactive.  Considering how fast results typically come back, I would much prefer to have a type-ahead style search where results start to appear as you type.  This would be especially useful considering the somewhat painful scroll-wheel-alphabet typing interface they provide.

Sonos is a great company that makes fabulous products.  They continue to advance the state-of-the-art in digital music systems.  By adding Napster support they have taken another step to commoditize Rhapsody’s music subscription product.  They’ve also released a new product called a ZoneBridge which acts as a WiFi range extender which would address one of my biggest complaints about the system.

I see a trend of how we’re approaching Tim O’Reilly’s Web 2.0 ideal in a way that he didn’t really identify.  But I think the trend is important, and growing, although still in its infancy.  The trend is towards richer web APIs
that enable people to build value on top of existing websites.  I’ll
give some history on how we got here, and talk about the current
trend-leaders that I see: Facebook and Google Maps.  I’ll also explain why I think Microsoft is in the best position to build the required enabling technology.

Original Web 1.0

Universal access to massive volumes of data.  Being able to search
through masses of data and find what you want.  Connecting people to
huge databases really well.  Key examples:

• Online telephone books
• Web search
• Huge e-commerce sites

But in all of these applications, the data set is static.  User activity will not change the data for anybody else.

Web 2.0.1: Democratizing use of the data

The users of these data make the data better.  They can collectively
organize the data.  (i.e. tags)  They can help filter good data from
junk.  (i.e. voting)  Or they can help you find the data that are most
interesting to you.  (i.e. collaborative filtering).  In other words,
you can interact with the data.

Any "Web 2.0 company" worth their salt has an API that federates out their raw data.  This enables other sites to use the data in new and novel ways.  But the primary problem with this paradigm is that anything built using these API’s is done from the ground up.  Using the gmail POP interface, it’s possible to build a better UI for gmail.  But to do so you need to first build an entire AJAX mail client — no small feat.  Better would be the ability to add features into the gmail UI itself.  But this is really the standard in web 2.0 API’s today.

Web 2.0.2: Democratizing the feature set

The next big trend will be enabling users to make more compelling ways to interact with
the data.  Users can change not just the data, but how other users see
and use the data.  Sometimes this means API’s with UI hooks.  Or other ways to enable new functionality into an existing site.  This kind of platform enables Independent Software Vendors to improve upon the UI’s that the original sites created.

Facebook is doing this by allowing ISV’s to add new communications features to their site.  Google Maps is doing this through maplets that allow developers to create new ways to interact with mapping data from within the fabulous Maps UI.  Right now these are the only two examples of web 2.0.2 platforms that I’m aware of.

Building this kind of API is very challenging.  There are several very different ways to go about doing it.  Here are a couple of ideas:

• Provide a server-server API that includes content generated from the ISV’s servers into the main experience.  Facebook style.
• Allow developers to author XML files that define new algorithms that are interpreted on the primary host’s servers.  Yahoo pipes is a service in this style, but they’re not doing anything to enhance an existing service so it doesn’t really meet my 2.0.2 criteria.
• Allow developers to author javascript plugins to run on the client machine.  Greasemonkey is essentially doing this.  This strategy has the best shot for a lot of applications in the long term, IMHO.  But it comes with some serious problems right now.

Doing this correctly would allow ISV’s to add new features to Gmail.  Think about it — if I wanted to change the way gmail messages were displayed, or how addressing happened, or whatever it was, this kind of platform could provide hooks for making gmail better in a way that a POP interface never would.  And even though a POP-style interface theoretically could do this, there would never be momentum because having a high-level base to build upon means that there are network effects from the extensions.  (Rails achieves a similar advantage over other web frameworks — just having a standard, any standard, means people will build upon that standard rather than argue over which library to use and extend none of them.)

3rd-party javascript

The big problem with this approach is security.  There is none.  You need to completely trust the ISV before you should allow their code to run in the context of your site.  The kind of editorial review required to do this today would completely kill the democratic goal of such a platform.

The world needs a security sandbox to run third-party javascript code inside.  This way primary site hosts could allow ISV’s to run their code on client machines safely.  Here are a few examples of places this kind of tool could be used.

ISV’s could…

• Add UI features to Gmail
• Create alternate ways to share and discuss images on Flickr
• Define new mathematical formulas to run client-side on a web spreadsheet
• Create new playlist selection / shuffling algorithms for Rhapsody

… and much more.  Even better, individual users (not developers) could pick which UI extensions they wanted to use.  Any site which provides such an API has democratized the feature development process in a very important way.  Not only does it provide a distributed mechanism to figure out which features are best, but it allows users to self-segment as to which features work for them.  Without such a mechanism the entire service must have the same features for everybody, which means product designers must play a political game where they’ll never make everybody happy.  Right now I think really only Facebook has solved this problem.

Building a security sandbox is an area that Microsoft could probably do best and fastest.  They are good at code API’s and layered security models,a nd they have a perfect place to do it with Silverlight and the CLR.  They’re trying to position Silverlight as a faster way to run DHTML, which is something else the world desperately needs right now.  But I just can’t imagine them doing anything this innovative or generally valuable.  Doesn’t sell more Office.  Doesn’t sell more Windows.  They don’t even really have many services that could use third party extensions, and they’ve lost touch with the ISV’s who might build such extensions too.  Google Gears could conceivably add such an extension.  There’s precedent there considering the javascript threading extensions they provide.

This will be a difficult problem to solve, I have no doubt.  But I hope somebody with the resources to leverage a solution takes it on, because I think it would really make the world a better place.

I access my gmail accounts through POP3 from my phone.  The problem with doing this is that all messages get exposed through POP, even the ones that are filtered out of the inbox.  This means that my phone which has much lower HCI bandwidth gets cluttered with all this list-mail that is less useful to me.  I’ve configured gmail to filter this stuff out to be lower priority I’m using the web interfaces, but when I’m using a POP client, this filtering is lost.  What I’d really like is the ability to configure the POP3 access with a checkbox saying I only want messages in the Inbox to be exposed out through POP3.  I thought gmail used to have this option, but I can find no record of this and have to wonder if I was perhaps imagining this.  The gmail mobile web interface is smart enough to do this — maybe that’s what I was thinking of.

Other alternatives include forwarding list-mail to another list-only account and deleting it, but that is frankly kinda lame.  Or if there was a way to create a filter that runs only on messages left in the inbox after the other rules have run, then I could forward the inbox messages to another account that I read with my phone.  But I don’t think that option is currently available either.

I just got a new MacBook Pro of my very own which is undoubtedly the fastest computer I’ve ever owned.  I hear a lot of people saying things like "I don’t think I’ll ever get another desktop computer again."  But to me there is one very good reason to own and use a desktop computer: Desktop computers can provide greater bandwidth connections between your brain and the net than laptop computers can.   I’ll explain what this means.

We’re quickly approaching a world where we’re always connected to the net in some manner or another.  As we all know, the bandwidth with which we can communicate with the net varies tremendously between locations and situations.  It might be
as slow as AT&T’s EDGE network, or as fast as a dedicated office
line with many Gbps of throughput.  But when we’re in the office, the speed of our pipe to the net isn’t the limiting factor.  Usually it’s the servers on the other end which limit how fast we can get things done.  Even when I’m on my DSL line at home, Gmail is so slow that my pipe isn’t the limiting factor.  Effective bandwidth is limited by the smallest pipe in the series from your brain to the information service.

Sometimes the smallest pipe isn’t a network layer at all.  If you’re using your iPhone on the office’s WiFi network, the network will all run super fast.  But your effective speed will be the iPhone’s virtual keyboard, and there are many small devices which are way harder to use than the iPhone.  There are multiple places the communications pipeline can get clogged:

1. The physical Human-Computer Interface of your device
2. The UI of the software on the device
3. The local processing power of your device
4. The direct connection from your device to the series of high-speed routers and fiber known as "the net"
5. The processing power of the servers running the information service you’re using

Laptops have totally caught up with desktops in terms of #2 and #3, but not #1.  The reason to use a desktop machine is that you can trick out its Human-Computer Interface to be super high bandwidth.  You can get yourself a really nice ergonomic keyboard, multiple high-resolution monitors, and a real mouse.  A friend of mine even built himself a foot-mouse.  Pretty soon your desktop will start to look like Lain’s Navi.  (Pictured above for those not familiar with it — go watch it.  It’s rad.)

You can do some of this with a laptop docking station if
available, or by manually plugging and unplugging things.  Many laptops
support 2 monitors, but generally one of them needs to be the internal
monitor, which won’t match the second one.  A USB port multiplier can
handle all your input devices which is nice.  So if you’re happy with
just two displays, a laptop can probably get enough HCI bandwidth today.

Looking further down the line, someday Apple will extend the iPhone’s multi-touch UI to iMacs and give us the Minority Report interface.  This will offer far more Human-Computer bandwidth than we’ve ever seen before.  This trend will continue towards direct Computer-Brain Interfaces at which point the line between our biological brains and our "exocortex" will get very blurry indeed.  I can hardly wait.

Gmail feels like it is slowing down to me.  Maybe my standards are going up.  Or maybe gmail’s user base has grown to the point where the servers to run it cost real money to Google, and they’ve throttled the computing resources to an "acceptable level of performance."  But it bothers me when I hit the "archive" button and I have to wait half a second for the UI to respond.  Sometimes even a couple of seconds.  Why does it take so long?  Just to get that line off my inbox screen?  The answer lies in computer science.

Gmail is written using a classic MVC pattern — Model, View, Controller.  The View reflects changes in the Model, and the Controller tells them what to do.  Clearly the View is our web page, and in this implementation, the Model is stored on Google’s servers.  What this means is that when you do something like archive a message, you’re not going to see the results until a message is sent to Google’s servers and the response comes back.  Now Google has really fast servers, but networks are slow.  By following this design pattern, Gmail is easy to code new features for and maintain relatively bug-free, but it’s never going to be all that fast.

Gmail engineers could code up optimizations for special cases.  For example, when I’m looking at my inbox and I hit archive on a message, they could detect this case, and just remove it from the page and then tell the server afterwards.  This kind of coding will quickly make the Gmail hard to maintain and result in lots of bugs.  Especially when you consider that multiple clients can connect to a single gmail account at once.  Strictly following MVC makes it easy to resolve conflicts in one place — the server.

A Proposed Solution

There is a solution though.  Google Gears can help.  The Gmail UI could be (and for all I know currently is being) re-architected to use Google Gears as the Model in the MVC pattern.  This means any operation in the UI would be committed very quickly to the SQLite database on your hard drive.  Then another thread would synchronize these changes in the background with the master model on Google’s servers.  Everything works — UI operations are reflected to the user extremely quickly.  We don’t lose all the benefits of storing all our data on the server.  And as an added bonus, we can still work on our e-mail when our computers are offline.  Yet another reason why Google Gears is important.

So when is this coming?  Synchronization and it’s evil twin, conflict resolution, are complex software tasks, so it could take a while.  But if I were placing bets, I’d guess we’ll see this in the first half of 2008.

An obvious trend in this industry is towards more pervasive internet access with bandwidth steadily increasing.  The build-outs of WiMax networks, 3G cellular networks and metropolitan WiFi efforts promise to offer broadband-class connectivity to all major cities in the US within the next couple of years.  Suburbs and extended metorpolitan areas will quickly follow.  Even airplanes should have reasonable net access before too long — Virgin America will have it next year.

In this environment it’s tempting to design products that assume customers will always be well connected.  It is certainly easier to build compelling services to users that have a good pipe to the net on them at all times.  So this begs the question: If customers will soon always have good broadband net access, why do we need a client-side data store like Google Gears?  For example, somebody working on a subscription music service might conclude that it’s a waste of time building portable mp3-players with local storage since soon enough everyone will have broadband access everywhere, so why not just stream the music off the net?

There are several good reasons why client-side storage is still important and will continue to be important into the future:

• Wireless net access sucks down battery.  Always will.  It’s physics.  Local access to data will always cost less battery.  This won’t change no matter how pervasive broadband is.
• Pervasive net access is expensive. Arguably we’re already in a world where some people have pervasive net access.  Verizon EVDO cards do pretty darned well in this country, for $60/month.  But it will be a long time before most people have it.  Higher speeds will always demand a premium.
• Net access is unreliable.  Especially wireless access, but wired too.  Packets collide.  Transmission patterns have nodes.  Routers flap.  Cables get unplugged.  Laptops wake up and can’t figure out where they are for a while.  Something gets misconfigured.  If your software is designed to gracefully degrade when the network is unreliable, your customers will be happier, because it’s going to happen.  Remember what Outlook/Exchange was like when the entire Outlook UI would freeze while waiting for the Exchange server to respond to any request?  Please don’t do that to your users.

Once web applications are fully embracing it, Google Gears will close most of the functionality gap between native-client applications and web applications.  I believe it’s really important, and I’m really glad that there’s industry consensus around Google Gears and that other offline browser storage projects have deferred to it.  I’d hate to see web app developers trying to choose between several different client-store plugins.