Immediate Gratification Matters

When your users access your service on the web, how fast do you gratify them?  Do you think about response time, or is your view that so long as it gets there before “too long”, it’s not a problem?

Google has made a business case for slamming down latency.  They invest zillions of dollars and IQ points trying to make their service respond faster when you hit the search button.  Why?  Because they’ve found it matters for the user experience.  Here is a graph of their recent experience with latency:

Fred Wilson recently tried Slideshare.  He liked it, but his primary complaint was that it took 12 hours after he uploaded his .ppt file to convert the slideshow to Flash.  As he puts it, “I went to bed before it finished.”  I had the same reaction to Animoto.  Loved the service, but I made one slideshow and then forgot about it.

The debate on whether startups have any business focusing on scalability rages in the blogosphere in the wake of the Twitter shakeup as we speak.  People like Ted Dziuba say essentially, “Scalability is not your problem, getting people to care is.”  The trouble is, as the two examples above show, getting people to care is at least partially a function of delivering immediate gratification from the software.  Scaling does matter for that.

Immediate Gratification matters most of all when selling.  If prospects can try your application out online, make sure it responds blindingly fast so they can get as far as possible in the evaluation while they are in the mood to look.  If a site doesn’t perform well on the trial version, my expectation is that it will perform poorly in production too.  That’s not what you want. 

Process matters too.  How often have you gone to a site, seen a white paper or demo you wanted to get access to, and had to answer 20 questions before you could get in?  Worse, how often did you answer 20 questions and then get told they’d get back to you?

They’re protecting the ability of their sales staff to control the process and making sure they capture your lead info.  But it’s a mistake because it just kills the momentum of an interested viewer.  What kind of customer wants to be kept waiting before they can give you their money?  It’s one thing to be kept waiting because of overwhelming demand for a private beta, that’s exclusivity.  It’s quite another to do one of these hurry up and wait sales wonders.

Gather the least information you can (name, email, and company?) and then give immediate access.  What are you doing otherwise, preventing competition from seeing your app and sales materials?  Balooney.  They’ve already seen it.  Trust me on this one.  Every customer that winds up choosing them instead of you, every friend of a friend employee that moves on, and a hundred other potential sources has eventually given them access to the 411 on exactly what you have.  If your lead is so fragile that the information you give any qualified process can sink your ship in the competition’s hands, you’d better get going on some radical innovation or you’re not going to make it.

I recently came upon Rally Development’s site.  Rally makes a SaaS tool for Agile teams.  I loved the site because of all the Instant Gratification.  In fact, it may be the best non-consumer startup site I’ve seen in a long time.  They touch every base– traditional product + marketing, education/learning, and community/evangelism –with a well-organized low friction and content rich offering that tells me what I need to know.

In an age of real-time scalability with services like Amazon.com, there’s no good technical reason to keep your customers waiting.  At the very least you should run some tests to see if faster response times improve your sales.  Once the scaling and infrastructure side is handled, the rest of it is in your hands in terms of the processes you force your customers to follow.

Immediate gratification matters!

From TwitPitches to TwitQuiries…

Stowe Boyd is writing about his TwitPitches idea again.  This is his practice of using Twitter for people to send him their elevator pitch.

I didn’t like them coming in his blog RSS feed to me–as I wrote, it isn’t what I expected or wanted from that venue.  But I can see the value.  Stowe wants to get through a blizzard of incoming PR requests to pitch ideas to him quickly.  He doesn’t want to read lengthy PR releases or unneccesary chit chat from people he doesn’t know.  He just wants to evaluate as quickly as possible whether it makes sense to dig any deeper or whether he just wants to hit the delete key.

In many ways this sort of quick inquiry is what I’ve always used messaging systems for.  In one of my jobs my team was spread all over a building.  It was easy to use AOL IM (pre-Twitter days!) to find out if someone was busy or had time to meet if I headed over.  Messaging was faster and easier than the phone and it worked well.

Stowe is on to something here, but why stop at pitches?  And why put it all exclusively through Twitter? 

I’d love to have a “fast lane” for inquiries tied into my email account.  I’d love to have a special Twitter “channel” for these things.  It’d be great if I could be reached by either venue.  Ditto phone calls and voicemail.  The overriding consideration would be to keep it brief (Twitter’s 140 character limit is fine) and to the point.  Better, give some flavors.  a “yes/no” TwitQuiry has a built in Yes/No button.  Bang one and the sender gets their answer.  “Time” would be another goodie.  Works for, “How long until you can take a call from me?”  Or, “When will you be done with that preso you promised me?”

It probably makes sense to let people create their own Tweetlets (applets for TweetQuiries) that do these things.  I can imagine them being really useful even for certain kinds of business process, for example.  A tiny little bit of structure aimed at streamlining keystrokes will go a long way.  There are lots of tiny interpersonal transactions that could be facilitated in this way.

Could be something to this yet.

LinkedIn Adds Companies as First Class Citizens

LinkedIn is rolling out company profile pages, so now companies are first class objects in the web of relationships that LinkedIn tracks.  That’s a good move.  It will play well for several of the 10 Ideas to Take LinkedIn to the Next Level I published.  For example:

- Do Some Heavy Lifting in the CRM and Marketing World:  It’ll be very helpful to be able to go from company to people (as opposed to just going people to company before the new feature) to build up this kind of functionality.

- Get More Private and Premium White Label Services for Companies:  It is hinted that companies will eventually have Wiki-style control over some aspects of their profiles.  That could make the profile a good home page for internal white label applications.  There’s still a lot of work to be done to enable those services, such as the ability to add fields to the entries for people that are private internal-use only for the companies.  Being able to understand the hiring and promotion scene at a company is great, and a logical next step is to support internal recruiting and mobility within an organization as a private white label service.

-  Web Mentions:  There is talk of news feeds that show “headliners” or people’s mentions in the press.  That’s a good start, but the web is a lot more than press releases.  It should be straightforward to add additional feed sources into the framework that the new initiative creates.

-  Creating a Business Relationship Semantic Web:  I had suggested that LinkedIn could “own” the semantic web for people.  Tying people back to companies and vice versa is classic semantic web activity.   Without the semantic web, search engines have to guess from keyword proximity and pages whether two are related.  LinkedIn has a chance to validate this more fully and be a webwide system of record for who is connected to which companies.  Again, it’s a good start.

It’ll be interesting to watch the future of LinkedIn unfold.

Empathy Bridges the Gap Between UsWare and ThemWare

Jeff Atwood writes of UsWare and ThemWare:

1. MeWare
   The developer creates software. The developer uses it. Nobody else does.
2. ThemWare
   The developer creates software. Other people use it. The developer does not.
3. UsWare
   The developer creates software. Other people use it. The developer uses it too.

These ideas originated with Eric Sink, but the discussion is based on Jakob Nielsen’s First Rule of Usability: Don’t Listen to Users.

The question is not whether to ignore your users, but how to listen to them.  Users are often too literal in what they want.  They want to tell you about the feature or change that you must make to your software, rather than the real problem they need to solve.  This is treating the symptoms and not the disease. 

Often they don’t know the real problem they want to solve.  This is where empathy can bridge the gap.  With UsWare, we don’t need empathy so much, because we developers are the users.  With ThemWare, we run the risk of following the wrong suggestions, or following the right suggestions too literally because we have no compass to guide our decisionmaking about features.  Anyone who has seen software built by the classic Product Management triage and prioritization approach knows it is a recipe doomed to create mediocre software:

- Canvas the user groups for what they want.

- Prioritize according to some metric.  All too often the metric is whatever the Product Manager thinks is cool.  Ideally the metric has some relationship to the business results the Software company hopes to achieve.  It’s very easy to get bogged down in these metrics with Balanced Scorecards and a host of other contrivances that stand in for true understanding and empathy.

- Put it all down on stone tablets called “Product Requirement Documents” and hand those to Engineering with the proviso to implement them precisely as they are written and don’t ask too many questions.

By contrast, Empathy means we have some sort of true understanding of why users want what they do.  This helps us to know things like:

- Which things can and should be safely ignored.

- Which things will really change the user experience for the broadest market.

- Which things will be interesting “almost good enough” features that are demoed often but seldom used.

Empathy is a bit different than Vision.  It’s deeper because it’s rooted in the Domain.  Find someone with Empathy in your Domain and that someone will be completely comfortable conversing with your users about their problems.  They’ll be able to persuade those users they are right, albeit perhaps requiring a prototype or two to get there.  The reason?  They speak the user’s language.  They get it.

Make sure someone on your team has this Empathy for your market or you’ll have a very difficult time.

There’s Two Problems With Perfect

Seth Godin writes about The Problem With Perfect:

The only time we notice them is when they screw up.

He’s right, of course.  And he goes on to elaborate:

As the quality of things go up, and competition increases, it’s so easy to sell people on perfect. But perfect rarely leads to great word of mouth, merely because expectations are so hard to meet.

Keep that in mind, BTW, the next time you’re looking at a market leader being acquired.  If the market leader was perfect, is there any more room for them to get better?  Or is it more likely they get worse in the wake of the acquisition making it look like a bad idea?

I’ll add a second problem with perfect that comes in the area of customer service.  The ISO 9000 and Six Sigma camps believe highly in perfection.  Any imperfection that is detected results in an immediate campaign to change the system so that particular kind of imperfection can never happen again.  But here is the problem:  customer service is defined by doing something for the customer.  If the service is perfect, there is no customer service.  In short, the customer never gets to see you exert an inordinate amount of service to make them happy after a comparatively minor failing.  This latter experience is the stuff of which great customer service word of mouth is made. 

Think about it: if you never have an opportunity for customer service to spring into action and impress the customer, all you have is perfect.  That’s not bad, but it’s not going to get you talked about.

In the end, for all kinds of user experiences, it’s important to remember that we are relative-sensing, not absolute-sensing.  We are sensitive to change and rapidly become oblivious to fixed levels even if they’re outstandingly good fixed levels.

Apple, MacWorld, User Experience, and the Multicore Crisis

Looking over the parachute drops of information from MacWorld, I was struck by some underlying themes.  I won’t bore you with a recitation of the huge amount of surface level activity: plenty of better more firsthand places to get that.  But some of those first hand sources excited some patterns I’m familiar with.

First, the multicore crisis bit.  I’ve written about it before, but let me recap.  What is the multicore crisis?  It is a wave of change that is being unleashed by virtue of the fact that microprocessors have stopped getting faster every 18 months.  Instead of gaining a faster clock speed with free benefits for all at scarcely any effort, we get more cores.  That ain’t bad, but it takes considerable effort at the software end to take advantage of the additional cores.  For the most part, we are far from keeping up with the availability of those cores.  For emphasis, here is a graph of Intel clock speeds that vividly shows just how long the curve has been flattened out:

We’ve had another year in 2007 while the curve remained flat.

What does this have to do with Apple and MacWorld?  Well, on a simple vein, it was the multicore crisis checking in that caused Mathew Ingram to write, “Hey, Steve–you broke the Internet.”  He was remarking about how Twitter was virtually unusable for hours.  Twitter has become somewhat of an unwilling canary in the coal mine: if something is hot and getting traffic, Twitter seems bound to go down.  Why?  Because it is a victim of the Multicore Crisis.  The system’s architecture isn’t scaling.  It may be a software problem, i.e. it is not designed to take advantage of enough cpu’s, or an infrastructure problem, i.e. it can only take advantage of the cpus Twitter has physically bought and installed in their data center.  These can both be overcome.  Software can be made to take advantage of lots more processors.  Services like Amazon and others offer let you scale up to many more cpu’s on short notice without having to buy physical hardware.  Failure to provide for both these contingencies is succumbing to the Multicore Crisis.

Twitter was not unique.  Mathew’s blog was very slow to come up when I tried to access the article, having been Techmemed.  He mentions Fake Steve Jobs got creamed and couldn’t make CoverIt Live work (Zoli mentions CoveritLive was CoveritDead).  The Apple store was down at one point too.

Scoble tells a similar story:  Engadget was up but very slow, Qik’s macworld channel was up and down, Mogulus was slow to unreachable.  Live video was hard to come by.  TUAW fairly unreachable.  There were a couple sites that passed muster including TechCrunch (bravo!) and MacRumorsLive.  TechCrunch hammers Twitter for being down.  Again.  If, as its pundits like to think, Twitter will play a signficiant role in reporting events, it needs to work all the time.  It is, after all, a communication channel.  Moreover, it’s a communication channel under constant scrutiny.

This brings me to a point I want to make about the Multicore Crisis and The Big Switch (what Nick Carr calls the trend to move to Cloud Computing).  These two megatrends are combining to change what the important core competencies are to succeed.  Once upon a time, it was enough just to be able to lash together all the myriad pieces needed to create a web application with a good user design.  You could count on Moore’s Law to make machines faster and your customer growth was slow enough that scalability could be comfortable pushed out into the future as a high quality problem to deal with if you succeeded.  That’s no longer the case.  The ability for new ideas to catch on has become viral on the web for a variety of reasons, not the least of which is that so many more people are on the web and they’re interconnected in so many more ways than simple e-mail, search, and web browsing.

There is another, more subtle manifestation of all this.  The new MacBook Air personifies this.  In the Multicore era: user experience is the new black for hardware.  Why?  Well, in the old days, everyone wanted to upgrade every two years.  For a while, I bought a new PC every year.  And it was worth it.  The new machines were significantly faster than the old.  In a world where the upgrade cycle is so short, you want to buy cheap hardware.  Result?  Dell wins big.  They’re the best at building their hardware cheap, so you can buy it more often, so you can get that speed.  Dell was driven by the Need for Speed, and the relative ease with which Moore’s Law delivered it.

Times have changed.  In an era when you probably won’t upgrade every two years, let alone every year, it makes sense to look at something other than speed.  I have an idea, how about looking at the User Experience?  Is the machine sexier?  Does it do cool things?  I love the Air’s ability to “borrow” a disk drive via WiFi from a nearby machine as well as its ability to handle iPhone-like gestures on its touch pad.  Combining Apple’s trademark radically uber-cool Industrial Design with genuine usability innovation is a winning formula.  If it gets you to buy a new machine when you otherwise would be happy to stand pat, they win.  The fact that so much of what one does on a computer is via the Internet combined with the rise of very effective virtualization software has radically lowered the barriers to PC/Windows users buying a Mac as well.  The latter is the Big Switch component.

That’s two significant changes brought on by the Multicore Crisis and The Big Switch.  What is your company doing to get ahead of these trends before some competitor uses them to ride right over your business?

Ease of Use and Ease of Learning are Quite Different Things

I was reminded again of something I’ve known for a long time and seen great examples of over a long period by something Reginald Braithwaite wrote in his Raganwald blog.  He muses that, “A programming language cannot be better without being unintuitive.”  Or, as he quotes David MacIver as saying of Scala:

Optimising your notation to not confuse people in the first 10 minutes of seeing it but to hinder readability ever after is a really bad mistake.

Reg never quite gets around to saying it, but the issue being discussed is that Ease of Use and Ease of Learning are two, not neccessarily orthogonal, but distinct dimensions when we talk about what it means for software to be “easy”.  This applies to all software and indeed most things humans interact with.  Perhaps the first vivid example of it I remember is a case from the “old days” of word processing.  A program called Word Perfect was absolutely killing a program called Wordstar.  The reason?  Word Perfect was much easier to learn, while Wordstar was much easier to use (i.e. more productive) once you had learned it.  Word Perfect introduced the notion of templates that went on the keyboard and a logical layout of keys that was easy to make sense of when you were hunting and pecking for your next command.  Wordstar focused on the idea that a good typist never wants their fingers to leave the home position.  Both programs were highly successful, but Word Perfect ultimately triumphed, and during the pre-Windows era, it was the most popular Word Processor in existence.

We see this conflict continue today between the keyboard and the mouse.  If you are a good typist and you’ve used a program that lets your fingers sing, you’ll know what I’m talking about.  The mouse is wonderfully efficient at a lot of things, and easy to learn, but for hard core powering in of text, having to reach for a mouse slows you down.

The web applications are still in their infancy when it comes to this sort of nuance.  It gets Ease of Use right a lot of the time.  If nothing else, pushing everything through the browser and its limited set of UI paradigms helps that out.  However, making web apps truly productive seems to be a dark art.   Such productivity is precisely what Rich Internet Application (RIA) ought to be about, but too often it is more about eye candy.

The next time you’re designing or evaluating a use interface, try to separate Ease of Use from Ease of Learning.  Think about whether there are ways to have both.  When a trade off must be made, be conscious of it:  “We are going to sacrifice some ease of use here in the interests of much better ease of learning.”  Think about your users and use cases:

-  Do your users treat the application as their primary tool, and use it for hours on end?  If so, you may want to make sure Ease of Use is well taken care of, preferably without making the application impossible to learn (remember Wordstar).

-  Is your application one that is used infrequently?  Do users tend to relearn it each time they use it?  If so, you should focuse strongly on Ease of Learning.

Don’t forget that the Learning barrier has to be crossed before any effective Use can take place.

MySpace for Sharing and Expression, Facebook for Networking?

It’s been interesting to watch the foot race between MySpace and Facebook, and even more interesting to watch people’s reactions to the two.  Somehow, MySpace got pidgeonholed by the Digerati as a great first try ultimately doomed by the Facebook better mousetrap.  These people complain that MySpace is too ugly and unstructured to be useful.

Andrew Chen points out:

 ”that MySpace is still far ahead on stats. For example:

• MySpace has 2.2X the users of Facebook
• MySpace has 1.4X the pageviews per visitor
• MySpace has 85% more time on site than Facebook
• etc, etc.”

What’s up with this?  Andrew says, “Silicon Valley people aren’t MySpace users,” that they don’t understand the use cases, and he brings up the notion of people who:

 ”insist on every product being “Googley.” What I mean by that is:

• Simple
• Functional
• Easy”

He winds up drawing an analogy between MySpace and scrapbooking, which is good, but it isn’t the whole story.  A callous interpretation of Andrew’s remarks might even lead one to believe he is recommending that MySpace is groups that are “economically challenged.”  The underclass, according to an article Andrew links to.  Trailer Trash and Red Necks of the Jeff Foxworthy persuasion if we gone to be more blunt, and believe me, the article Andrew links to gets extremely blunt.

I think there is a lot more at work here.  Part of it has to do with what people do on these networks, and part of it has to do with my concept of Web 2.0 Learning Styles.  My thesis is that MySpace is about giving the common man a way to express themselves and share that expression.  In that sense, Andrew’s scrapbooking is a good analogy.  Really, any craft or art form is a good analogy, including blogging, because a big part of it is a desire to express one’s self.  Expression is very much an ongoing process.

Facebook seems more goal oriented.  That goal seems to be networking:  How many friends can I notch up?  How influential are they?  Can I get a hot date (for those who subscribe to the idea that Facebook is largely about college dating).  The opportunities for expression on Facebook seem dramatically more limited.  Perhaps it’s a natural outgrowth of the goals.  If Facebook is all about courtship rituals of one kind or another (yes, business networking is definitely a courtship), then expression can be a dangerous thing.  If we express too freely, we may turn off the object of our pursuits.  So instead of putting the expression out there as a reflection of our personal taste and talents, which is risky, the expression is channeled into cutesy, low-risk, multiple choice options.  “You have 1 gift to give.”  My gift today is Thanksgiving leftovers.  This allows Facebook users to be cute, coy, or flirtatious, but without putting much of their real persona on the line.  Personally, I’d rather meet someone’s fuller expression of themselves before I feel like they are a “friend”.

There is another aspect that I think about frequently, and this is my concept of Web 2.0 Learning Styles.  The Myers Briggs test is based on certain personality traits.  It inspired me to come up with a similar approach to web services after I saw the love/hate reactions to things like Twitter and Scoble’s videos versus his blogging.  I could see that there was a place for more than one style, but that people prefer styles, sometimes intensely.  Savvy marketers and designers need to cater to this.  They need to figure out how to help people to self-select the communication style they prefer and then serve up content using that style that accomplishes the goal.  You can clearly see the MySpace/Facebook differences here too.  Here was my original casting of it:

In this case, I show MySpace as a more Free Form and less Structured Facebook.  I almost think I should have categorized Facebook over on the Text side of the line, or perhaps defined that dimension as “Simple Media” and “Multi Media”.  There is definitely a difference in richness of expression, with Facebook being “Googlier” as Andrew Chen says.

Getting back to Andrew’s original remarks, why then does the Valley not like MySpace?  Because engineers and business people are often more into structure, participation, and simplicity.  It’s the visual thinkers and intuitive crowd that will prefer the MySpace (or similar avenues of expression).

Related Articles

faberNovel consulting reaches a very similar conclusion about Facebook and MySpace.  On their quadrant, they position MySpace as being about Public Exposition and Fantasized Identity.  Facebook is about Real Identity and Qualitative Contacts.  I prefer to stick to my view that MySpacers are “expressing themselves” as much as they’re creating “fantasized identities”, but there is truth in both views.

A Kindle User After My Own Heart

Go read Josh Taylor’s post on how he took a Kindle to the Carribean and why he has fallen into “deep like” for the device after that.  Being able to travel without a suitcase full of books was the first lightbulb that lit for me when I heard about Kindle.  The truth is, I’d seen an eBook a long long time before Kindle.  I can’t even remember whose it was, but we’re talking before Blackberry even existed.  It was a lame device back then, but I would still have bought one but for lack of decent book selection.  Despite O’Reilly not being there yet, I think Amazon has the means to fix the selection problem, and the device is certainly light years ahead of most of what we’ve seen even if many are still unconvinced.

Tidbits from Taylor’s post:

• Taylor loved the Kindle’s screen for reading text, but says graphics, even black and white pictures, are almost hopeless.  I still haven’t personally seen a Kindle, but my friend Song Huang was recently telling me how impressive the eInk display is.  He saw one at a conference somewhere and was convinced they had just stuck a piece of paper behind glass as a mockup.  When the thing updated and showed it wasn’t paper, he was blown away.  I’d love to hear whether line art looks good on a Kindle.  That’s the sort of thing I’d want if reading a technical book, although it’s a shame actual pictures are so poor–it’ll make it hard to see screen shots.

• As to the UI, Taylor loves the navigation but laments you can’t put Kindle away without accidentally flipping a page.  Has no one ever been reading their paperback, nodding off, dropped the book and lost their place entirely?  Must be my age if I’m the only one.  He also had an incident where his wife went to the beach without a proper charge and the Kindle died.  Doh!  Hate when that happens!

I also liked learning that Amazon will let you grab the first chapter of any book free to see if you like it before purchasing.  As I wrote in my original Kindle post, there are lots of ways the buying experience can be enhanced by Kindle.  One of my minor book purchasing peccadilos is an inability to keep track of all the authors and which of their novels I already have.  Every now and then I wind up with two copies of something.  Nothing worse than diving into what you think is a new offering from a favorite author only to discover you’ve already read the book!  I want to be able to get into a book club for my faves whereby I get notified as soon as something new is available and I can get the book with one click.  BTW, Amazon is famous for patenting the one click (I believe the recently lost that patent too).  I would expect them to try to patent a lot of the new stuff behind Kindle.  Patents are not my favorite thing, but they are a fact of life.

Scoble ran an interview on the street with a woman who wanted to see his Kindle while he was giving a talk at Stanford.  I came away from the interview with a slightly different reaction than I think Scoble and others may have.  There is a view that Kindle’s foibles are disasterous, but I’m not at all convinced.  Scoble points out that this woman hit many of his complaints almost immediately:

Notice that she accidentally hits the “next” button. That she tries to use it as a touch screen. That she is bugged by the refresh rate. But, she, like me, is interested enough to want to buy one (she’s the first that I’ve shown it to that has that reaction). Imagine if Amazon had designed it better? Imagine how many more people would want it.

The thing is, if you watch the video, none of that bothered her.  She made an assumption that is common outside Silicon Valley: if the thing didn’t work as she expected it to, it was not a problem, it just meant she needed to learn.  Sometimes I think we get too focused on a particular view of how things have to work in the Valley, and we’re way over the top critical when they don’t.  Many successful products are riddled with inconsistencies, but work so well compared to the alternatives that we ignore them.  I’m typing this in WordPress and let me tell you, it has at least as many UI foibles as Kindle, but it doesn’t matter, and it’s wildly successful.

I do agree with Scoble that if Kindle had been as perfect as iPhone or iPod from the get go, if it had been just as sexy, and just as “right”, Kindle would be a much bigger success.  However, let’s reflect on two thoughts.  First, Josh Taylor remarks that the Kindle must be popular because you can’t get one.  Note that this may not be the whole story.  Amazon may be limiting supply for a variety of reasons.  They want to understand usage patterns better to see if they can make money, or they want to respond to user criticisms without having a ton of inventory, or even they want to make sure it doesn’t damage their lucrative Christmas season.  Second, iPhone and iPod were not first generation devices in their categories.  I suppose we can argue that Kindle isn’t either, but it seems to me the precursors of the Apple products were much closer to success than Kindle’s precursors are.

All this has, um, kindled my desire to have a Kindle.  Still not sure I’ll put it on the Christmas list (you can’t seem to get one anyway), but my birthday is early in the year.  I just hope to see the rumored Apple Tablet device before I have to pull the trigger.  Wouldn’t it be awesome if Amazon takes the Open Road and has an OEM offering for other eBook builders?  Wouldn’t it be even more awesome if the Apple Tablet picked up the backend of the Kindle service and accessed it from their own UI?  Whoa!  Stranger things have happened, but not often…

The Web Leaves Information In Its Place

What is the web?  How has it changed how we think about computing?

I’ve been thinking about a crazy change of perspective.  I wonder if the web isn’t about moving people to information instead of information to people?

Compare and contrast the destkop with the web.  On the desktop, we are obsessed with where the information is.  It consists of files that live in folders.  Conventional desktop thinking does collaboration by shipping this information around.  Originally the shipping was even done via physical media: floppy discs and lately CD’s, DVD’s, or USB keys.  Eventually, we started shipping it via email.

Now take a look at the web and collaboration there.  Is it easier to ship documents around with email, or to build a collaborative wiki?  I think it’s easier to build a collaborative Wiki.  Why?  Because we leave the information in its place and work on it in situ.  Shipping information around is problematic for collaboration because the information is changing.  You have to keep shipping updates and you might miss one.  Or, you might mistake an old copy as being the latest and greatest.  We’ve all had this happen.

Despite the availability of a lot of useful tools like wikis, web collaboration is still in its infancy.  We’re still very much in a position of saying we have achieved collaboration merely because we’re running a web app.  It’s a great first step, but it needs to go further to enhance the potential of the collaborative medium.  How does using a web-based word processor enhance your collaboration versus using your desktop word processor?  So far, it means everyone can access a link to the same data without passing copies around.  That’s a big step, but there’s a lot more possibility there to finish the job.  Let’s stick with the document for a moment so I can illustrate. 

We need to be able to weave the collaborative conversation throughout the document in several ways.  First, we should be able to comment at will.  Pick your favorite UI metaphor of sticky notes or change/revision highlighting, or whatever, but it must be possible to hold a conversation about the document, outside the document (meaning you can view the document without these conversations), but still in the context of the document so comments are next to what’s being commented on.

Next, we need to be able to make changes and have everyone see who is changing what.  So far MS Word’s change/revision markup seems to be the best example, and it isn’t even in a collaborative web product!

Lastly, we need to be able to divide and conquer.  I’ve always like Excel’s notebook tabs (well to be fair, I invented them, LOL) for this.  What if tabs could be assigned out to contributors?  I once told the Microsoft people they needed tabs in MS Word, but they wouldn’t listen.  Wikis can do the same by giving ownership of pages.  Again, choose your favorite UI metaphor, but make it possible to divide ownership.

Put those three together and you have a big step up on collaboration.  The next logical step would be workflows to ensure people are collaborating in structured ways where appropriate.  Putting the data in the cloud makes all of this easier and more natural, but we have a long way to go before we have all these capabilities in a reasonable suite of content creation tools like word processors and spreadsheets.  It’s about time we pick up the pace and get there already.  Past time really.

What else do we get from not having to ship information?  Quite a lot, actually.  Two biggies are machine independence and the ability for others to help us take care of our information. 

Machine independence means you can access your information from any machine because the information is in the cloud, not on your machine.  Given the proliferation of devices (most business people seem to have a work machine, a home machine, and a smart phone, for example), this is important.  To paraphrase Buckaroo Bonzai, “Wherever you go, there you information is.” 

What about this last idea that people can help us take care of our information?  This is the essence of SaaS.  It can be simple things like making sure the information is backed up to a redundant store in multiple physical locations.  Another immediate benefit is someone else keeps your software running smoothly with all the right updates and security patches.  You don’t even need to install anything–just logon with your web browser.  There are a lot of other ways value can be added, let’s touch on a few.  The service can help link you up with others who are working on similar information or who appear to have similar interests.  Communities develop this way and it’s very helpful.  Your desktop need no longer be an island.  Search becomes more powerful.  Despite repeated attempts, I’ve yet to see a desktop search experience that works as well as what I routinely have on the web.

The list goes on, but you begin to see how moving your information to the cloud truly creates a lot of powerful opportunities to add value.  Equally obvious is we’ve hardly begun to deliver on the full vision.