Thursday, November 25, 2010

I Know, I Know, It’s Been a Long Time






Wednesday, August 25, 2010

Wave (Again)

I read another article today about the demise of Google Wave. In some ways, I think the author missed the point of Wave—but, at the same time, neither did the author deny that. In fact, it was part of the point of the post: What was Google Wave? What was it supposed to be for?

The author didn’t seem to get what Google Wave was, and believes that Google might have overhyped it; personally, I believe that a lot of the hype was justified—Wave was meant to replace email, and IM, and maybe even documents—but I definitely agree that Google’s message on Wave was muddy, at best. Their press seemed to be saying, “Google Wave is great! It’s amazing! It’s revolutionary! It does… well… some stuff. And it does it really, really well! And you should use it! And if you do… then maybe you’ll figure out what it is that Wave does.” It’s hard to get people excited about something when they don’t know what it is.

The author of this article said something similar:

Not only did Google fail to define Wave, it also promoted it clumsily. I’ve written before about Google’s strange habit of releasing lots of products with overlapping features—Wave, for instance, shared traits with Google Talk, Gmail, Google Docs, and Google Buzz. Wave seems to have lost out in this internal fight for users’ attention. It was Buzz, not Wave, that won a prized place inside Gmail, where it could instantly win lots of attention. Wave, meanwhile, was actively separated from Gmail—if someone wrote you in Wave, you wouldn’t get any notice in Gmail. Google eventually added e-mail notification for Waves, but by that time the ship had sailed. Wave had already been defined as an online ghetto—no one was there, so why should anyone join?
I definitely agree with this. Especially about the integration issues between Gmail, Wave, and Buzz. From the outside looking in, it seems that Buzz might have won some political wars within Google that Wave lost; it probably would have been a bad idea to integrate both Wave and Buzz into Gmail at the same time, but putting Buzz inside Gmail got it a lot of immediate exposure—even though I believe Buzz still isn’t getting used as much as Google would like—whereas Wave, as the author says, has become an online ghetto.

Saturday, August 07, 2010

Google Wave, We Hardly Knew Ye. Literally.

Google has decided to pull the plug on Google Wave, because it hasn’t seen the level of adoption that they would have liked. This is unfortunate, because, as my readers know, I very much buy into the Wave concept. I would prefer to be using Wave over email, prefer to be using it over IM, and in a lot of cases prefer to be using it rather than creating documents. I was also looking forward to using Wave to write my blog posts.

I’d even begun work on creating a Wave gadget, but was hindered by some features that weren’t yet available—such as the ability to dynamically set the width of the gadget—but were being “worked on”. (I now see why they weren’t so quickly developed.) I had some ideas for other gadgets or robots, too; I probably would have ended up implementing all of the plugins I’d written for HTML-Kit as Wave gadgets/robots.

The thing is, despite my excitement about Wave, and my willingness to create a gadget, and the fact that I would prefer to use it, I barely ever do. And I don’t use it for the exact reason that Google is shutting it down: nobody else is using it. Wave is all about communication and collaboration—if you’ve got nobody to communicate with, if you’ve got nobody to collaborate with, then it’s not going to do you any good. The very first adopters of email, back in the day, could only email people with access to the network and email accounts of their own; for everyone else, they had to send actual letters. Same with Wave; I could “wave” with other people on Wave, but for everyone else—which is practically everybody—I have to use email and IM.

I’m not sure if it’s time yet for Google to shut it down; something like this would naturally take a long time to come into its own, and I’m not sure it’s been long enough. (Not that I’m expecting Google to read this blog post, and say, “Hey, serna’s right! We should give Wave a few more years!”) You can’t “get” Wave unless you’re using it, with other people who use it, and since hardly anyone is using it, very few people yet “get” wave or use it for anything useful. It’s not like Google Maps, where you can take one look at it and say, “Hey, that’s useful! Look, you can drag the map around with your mouse, and zoom in and zoom out, and you can search for things nearby your location, and…” It’s something that you’d need to use for a while, and start to realize how it gradually takes over where you used to email, or IM, or write a document, now all you’re using is Wave. Eventually you’d get to a point where there would be a minor level of irritation when you have to communicate with someone who doesn’t use Wave—but the thing is, most of us who buy into Wave have been constantly in that state for a year or two.

Just this past week, I had a conversation with a colleague. My manager had sent an email, and there were some Reply Alls and some replies sent only to me, and then my colleague IM’ed me to talk about it further. And during the conversation she said, “See, we don’t need google wave, we already act as if its all one communication device.” To which I had to respond, “But if we had Wave, we wouldn’t need this side IM conversation. You could respond right within the Wave, but make it private so that only I’d see it.” Really, there would have been no need for the Reply Alls, there would have been no need for the IM conversation—or multiple conversations, if others were discussing it as well—and if anyone had been away from their desk and came back, they wouldn’t have seen an Inbox full of emails, they would have see one, consolidated wave. My colleague is right, we don’t need Google Wave; we already have email and IM. But then again, we don’t need IM, either; we could just send little emails back and forth all the time for our conversations—so why do we use IM? Because it’s easier. And if we had Wave, the set of conversations mentioned in this instance, spread across emails and IMs, also would have been easier, and nobody would have had to fire up MSN Messenger.

My point being that people still don’t get Wave, and how could they if they’re not using it, and why should they use it—or how could they use it—if nobody else is?

I definitely understand Google’s “release early and release often” philosophy, and I can see why they rolled out Wave the way they did—only to a few hundred developers first, then to a preview audience, and only recently opening it up to the world—but unfortunately, because of that strategy, the main use for Wave over the last year has been a lot of navel gazing. A thousand people talking to each other about how great Wave is, and wishing they could get their friends and colleagues to use it so that they could start using it for real communication.

Friday, July 02, 2010

A Short Post, Pointing to Long Stuff

I’ve been thinking a lot about postmodernism, lately, especially the Christian’s approach to postmodernism, and evangelism in a postmodern world. Here’s why.

It started with a series of talks by D. A. Carson, on Evangelism in the 21st century. It’s a three part series; you can listen to the audio (MP3 format) by clicking here, here, and here. (I got these links from a page devoted to D. A. Carson talks, which can be found here.)

This prompted me to read the book The Gagging of God, also by Carson, which I posted about on the Book Blog.

Finally, I also listened to a sermon by Tim Keller, on giving the Gospel in our times, which you can listen to here or watch here.

See? Much shorter than my usual posts. Of course, going to any of the links I provided will consume a good amount of your time…

Monday, June 21, 2010

Voice Recognition

I read a nice post on Coding Horror today about voice recognition—and the fact that it’s still not here yet. (And may never come.) I’m not sure what I can add to his post, though, other than just saying “me too” over and over.

Atwood mentions the Google app you can get for your iPhone, and its voice recognition feature. My experience has been slightly different than his—I’ve found that it works remarkably well—but at the same time, I think of it more like a novelty, not a real useful thing. It’s fun to pull it out and speak into it, and have it automatically perform a Google search for me, especially if I want to show it off to others, but when I want to actually search for something… I pull up Safari, and type it into the Google search text box. (If I had my dream phone, I’d just do the search right from the phone’s “desktop” and not even pull up the browser until I found a result I needed!) I use Safari instead of the Google app with its voice recognition for a couple of reasons:

  1. It’s faster. Safari loads faster than the Google app on my iPhone, and if I find the result I want, it’s going to end up loading Safari anyway. So it’s much faster to just start with Safari in the first place, and cut out the middle man.
  2. Add to that the times when the voice recognition doesn’t work, and you have to do the search over and over, vs. just typing it in and getting it right the first time.
Plus there’s the whole speaking at your phone thing. Aside from the coolness factor, is there actually any benefit to saying your Google search at your phone, instead of typing it in? Any benefit whatsoever?

I was also right there with Atwood when it comes to dictation. He mentions that someone had had the idea of having him and Joel Spolsky use voice recognition software transcribe their podcast, and I was thinking of when I was looking into doing something similar for our church. We were going to start putting our sermons online, and I was thinking that having a textual version of the sermon would be very handy for things like Google searches, so I was playing around with Microsoft Word’s speech recognition. Which, again, is very good. But… not good enough, it turns out. In fact, I was trying to do some tests, using Microsoft Word, and one word that it could just never get right was “verse”. Imagine trying to transcribe a sermon without using the word “verse”! (To get a feel for why this is important, go back through any of the sermons we’ve got online, and see how often the pastor is referring to this or that verse, as he refers to passage after passage.) It’s possible that the speech recognition might have done a good job, and I’d just have to go through and correct it, but I’m with Atwood on this one, too:
Maybe it’s just me, but the friction of the huge error rate inherent in the machine transcript seems far more intimidating than a blank slate human transcription. The humans may not be particularly efficient, but they all add value along the way—collective human judgment can editorially improve the transcript, by removing all the duplication, repetition, and “ums” of a literal, by-the-book transcription.
I actually approached it very optimistically, but in my testing quickly came away with the idea that it wouldn’t work out well in practice. (What we ended up doing is coupling the pastor’s sermon notes with the audio for the sermon. It’s not the best solution—pastors often end up straying from their notes, so the notes won’t always match up with the actual sermon—but I think it’s a good compromise.)

So even though I sometimes find the iPhone’s text input kind of annoying, I’ll still choose it over the Google voice recognition any day. And do—every day.

Tuesday, June 01, 2010

Incentivizing Work

I read an article by Joel Spolsky in which he was talking about gaming incentive plans. If you haven’t read it, go and check it out.

Joel was looking at one side of the incentive problem: If you try and get a result by incenting people, they’ll learn how to get the incentives, regardless of whether they’ve actually produced the result—they learn to game the system. But what about the other side: What if people didn’t game the system? What if they really did try to produce the result you were looking for? And what if you promised them that the quicker you produced it, the higher the reward? That is essentially the free market system in action, right?

Actually, it turns out that doesn’t work anyway. It’s not just that people will game the system and work around the incentive model you’re creating, it’s worse than that: the incentive model doesn’t work in the first place. Hence a talk by a guy named Daniel H. Pink. I found out about him from a post on Coding Horror; if you head on over to that post, you’ll see two videos from Daniel:

  1. The first one is from TED, and is longer, but more informative.
    • As a side note, I just recently heard about TED, and I’ve found a lot of interesting talks on a variety of topics. After you’ve seen one or both of these Daniel H. Pink videos, feel free to browse around the TED website for other talks. I’m sure you’ll find something interesting.
  2. The second is a shortened version, which is sort of a summary of the things said in the first one (but has prettier pictures).

Wednesday, May 19, 2010

Google Wave

Google Wave is now open to everyone; anyone with a Google account can log in, without having to sign up and wait for them to approve you.

And, in honour of them opening it up to the general public, they put out another one of their little “About Wave” videos.

Monday, May 10, 2010

Kathy Sierra at Business of Software 2009

I originally got this link from a post on the Joel on Software blog, and thought I’d share it with you. It’s long—54 minutes—but if you develop software, it’s worth watching.

Thursday, April 29, 2010

Bread crumbs?!?

We walked out of our door yesterday morning to find that someone had put bread crumbs on our front porch.


Why? I have absolutely no idea.

Monday, March 29, 2010

Regular Expressions

I’m sure I’ve mentioned regular expressions (regex) on this blog before. I love ’em. (Note: If you’re not a computer nerd, you don’t need to know what regular expressions are, and can ignore this post. If you are a computer nerd—in any area of computer science—you definitely should know what regular expressions are. But… you can probably still skip this post.) Such a powerful technology, and it’s already built into most programming environments. (Or even the command line, if you use any operating system other than Windowsgrep anyone?)

However, much as I enjoy the power of regex, there is no doubt that the syntax is a little… opaque. For example, suppose you want to validate that an email address is in a “correct” format. You could write some code that does the following:

  • check for the presence of the @ character (there should be one and only one)
  • see if there are any dots (and whether or not those dots occur before or after the @, because there may or may not be some before, but there has to be at least one after—but a dot can’t be the last character)
  • Check for special characters like the dash, and make sure it doesn’t come right before the @, or right before a dot. (It can exist, it just can’t exist in those special spots. e.g. you can have but you can’t have or
And there are various other rules you might need to check. You’d probably need one or more lines of code to check each of these rules. Or you can just validate the address against a single regular expression, in one fell swoop. One line of code (in most programming environments), and you can do some very complex pattern matching.

For example, in Java, assuming we have a string called emailAddress with the address we want to validate, and a string called EMAIL_REGEX_STRING with our regular expression, we could do the following:
if(!emailAddress.matches(EMAIL_REGEX_STRING)) {
  // handle error
From a coding perspective, this is a lot simpler. With one line of code we can validate that email address, and the validation can be as complex as we want it to be. The regular expression can include all of the rules mentioned above, and more, all in one string.

I bring this up because I was given just such an expression today, to validate an email address. It does, indeed, validate all of the rules mentioned above. Unfortunately, it looks like this:


Wow. Not so readable, eh? Just to understand it, I had to try and break it up, piece by piece, and figure out what’s going on. This is the result, with some pseudo comments in there:

(?i)                                // make the regex case-insensitive
^[a-z0-9`!#\$%&\*\+\/=\?\^\'\-_]+ // string must begin with 1 or more of the characters between the [ and ]
( // next section...
(\.)+ // if there is a dot...
[a-z0-9`!#\$%&\*\+\/=\?\^\'\-_]+ // must be followed by one or more of the characters between the [ and ]
)* // ... section happens 0 or more times
@ // followed by an @ symbol
( // next section...
[a-z0-9]+ // one or more characters of a-z or 0-9
([\-][a-z0-9])* // optionally followed by dashes, followed by a-z and/or 0-9 characters
)+ // ... section happens 1 or more times
( // next section...
[\.] // a dot
( // followed by...
[a-z0-9]+ // 1 or more a-z or 0-9 characters
([\-][a-z0-9])* // optionally followed by dashes followed by a-z and/or 0-9 characters
)+ // ... 1 or more times
$ // must end here

Still pretty bad. It’s no wonder that people take a look at regex syntax and decide they don’t have the time to learn it.

The worst part is, I think there are some mistakes in this expression, but I can’t even be sure! Can you really have a ` character or a dollar sign or an ampersand in an email address?!? Or am I even reading that right?

Saturday, March 27, 2010

Two Videos From Shad

Andrea showed these to me today, and I thought I’d share them with y’all.

Friday, March 26, 2010

Pretty Lattes

For a while, when I was looking for a change, I was using the following display picture in MSN Messenger:


(It may even have been during Roll Up the Rim to Win season.)

When we were in Ottawa this week, for a short mini vacation, we stopped in at a coffee place that actually decorates their lattes like that.

Latte 01
Latte 02
Latte 03
Latte 04

Google Wave and Novel Pulse

I have long been saying—possibly here but definitely in other circles—that one of the key things that will help Wave technologies take off is when other companies/organizations start incorporating the federation protocol into their services. People aren’t going to log onto Google Wave to communicate for business—or at least, not many of them will—but they will log onto their corporate wave servers to do so. The example I keep using is when Microsoft incorporates the technologies into Exchange Server (if that ever happens—obviously it’s early days).

I was pleasantly surprised to see today that Novel has already started in this direction, with their Novel Pulse product. I hadn’t expected it to start happening this early, but I’m glad it is.

Thursday, March 18, 2010

Gnome 3

For the Linux geeks out there, Gnome 3 has been released, and there is talk of making it the default desktop environment for Ubuntu. You can take a tour of it at the Gnome site, or view the Cheat Sheet to see descriptions of a whole bunch of features. (I first read about it on the Works With U blog, complete with screenshots and a screencast.)

It looks like it has the potential to be either:

  1. Very cool, or
  2. Very annoying, or
  3. Both
It would be nice to see a new paradigm for desktop environments, instead of the old taskbar at the bottom (or top) of the screen with buttons for all of the open windows. So I’m hoping that this will be one of those things that people get used to quickly, and wonder how they ever lived without it. But only time will tell.

Monday, March 15, 2010


I haven’t yet become a twit—is that the term for someone who uses Twitter?—so I have avoided saying much on this blog about Twitter. However, Joel mentioned something in the context of a larger post and it made me smile, so I thought I’d share it:


Thursday, March 04, 2010

Joel’s Taking it Offline

I’m not sure if I should actually write this post. Everyone else who reads his blog is probably doing the same thing, and I’ll just be one voice amongst a million. But I’ve already started typing, I might as well finish…

Joel Spolsky has decided to stop blogging at Joel on Software. Which gives me mixed emotions.

On the one hand, it was a great blog, with many great, classic posts on software development. Many of those classic posts became part of the books, Joel on Software and More Joel on Software. I can’t remember how I first came across Joel’s blog, but as soon as I read it, I was hooked.

On the other hand, Joel hasn’t been writing that much on the blog lately anyway. By lately, I mean, oh… a year? Two years? More? The thing is, I started following him too late. However it was that I came across Joel’s blog, it was through some link to one of his classic posts, which I read, and thought, “Ah, now there’s an intelligent post on [whatever it was about].” Then I read his first book, and enjoyed it thoroughly all the way through. So I added his blog to Google Reader, and prepared myself for the brilliance that would inevitably follow. Only to find that he rarely posted, and when he did, it was either a post about Stack Overflow, or a link to his latest column on Inc. Magazine. It turns out that Joel seems to have done most of his great writing before I ever got on the bandwagon. (I did like the articles for Inc., don’t get me wrong.)

So I’m sorry to see him go, and I wish him luck, but at the same time, he’s got good reasons for stopping, and he hasn’t posted as much in recent times so I guess I’m not missing much anyway.

I just wish there was a slew of other bloggers out there for me to read, ready to take his place.

Wednesday, March 03, 2010

Another Wave Concept Video

The last video I posted illustrated how a bot might be put to good use in a wave, along with a clever way that wave technologies could be embedded within a larger business process.

Today I include a video from SAP with a prototype for a system called Gravity, which illustrates a clever way that an extension can be built for Wave for integrating Wave with other systems.

I can easily see Sparx Systems coming up with an extension for Enterprise Architect UML models (or similar extensions for Rational Rose or other UML tools), or extensions for embedding Microsoft Office documents/spreadsheets/presentations, or a million other ways of integrating software with Wave through extensions.

Or, to go back to the previous example, envisioned embedding a wave in their ticketing system, but they could also have gone the other way, and created an extension to embed a trouble ticket into the wave. When you load a wave, the extension could dip into the trouble ticketing system to load the information.

Friday, February 12, 2010

Chromium OS







I’ll let Google explain:



Operating SystemSplash ScreenLogon ScreenAble to Open BrowserReady to SurfTotal Time
Windows XP648105463:25
Ubuntu 95418559
Chromium OSN/A22N/A325

startup time


Operating SystemShutdown Time (seconds)
Windows XP58
Ubuntu 911
Chromium OS16

shutdown time








Monday, February 08, 2010

Google Wave In Use


Monday, February 01, 2010

Skip Intro




Friday, January 29, 2010



Some examples:






Friday, January 15, 2010

Google Web Tools

A while ago I had a post in my Beautiful Code series, on Computer Generated Code. There, I was referring to things like the C pre-processor, which runs through a source code file and generates additional source code, which is finally sent to the compiler. Or, in more extreme cases, using another tool altogether, like awk, to do the same thing, but with potentially a lot more flexibility (with the power of regular expressions at hand). These days Java programmers are doing something similar with Annotations. The article also mentioned code that generates further, optimized code.

Last Fall, I came across a variation on this, in the form of the Google Web Toolkit (GWT), which is a set of tools created by Google for creating rich HTML-based applications, specifically ones that make use of JavaScript and AJAX and JSON to do complex things in the browser.

One of the disadvantages to using a scripting language like JavaScript for development is that it is not a “strongly typed” language, and neither is it compiled, so some development errors will not be discovered until the testing phase. With a compiled, strongly-typed language (such as C++ or Java), some errors can be caught at compile time and fixed quickly, which reduces the number of bugs to be discovered during the testing phase. Another issue is that things often work slightly differently from browser to browser, so often you find yourself building JavaScript code that does things like, “if Firefox do this, but if Internet Explorer version 6, do that, but if IE7 do the other…”

GWT tries to combine the benefits of using a strongly-typed language—in this case Java—with the aforementioned benefits of improved user interface via AJAX. In a GWT application, code is written in Java, and UI is built using a GWT library, very much in the same way that a Java Swing application would be built. Once the application has been built and tested, it is “compiled” into JavaScript, with versions optimized for various browsers. In other words, a version is produced that will be optimized for IE6, and another version for IE7, and another for Google Chrome, and another for Firefox, etc. When the user accesses your application, the GWT JavaScript runtime figures out what browser you’re using, and downloads the correct code (and only the correct code) for your environment.

In addition, any JavaScript which is created is also optimized, whereby extraneous whitespace is removed, comments are elided, and even variable names are shortened; by compacting the JavaScript in this manner, it’s quicker for the browser to download the code, which improves performance even more. For example, a JavaScript function that might normally be written like this

//adds two numbers together, and returns the result
function addTwoNumbers(firstNumber, secondNumber) {
addedNumbers = firstNumber + secondNumber;
return addedNumbers;
Might end up looking like this, instead:
function a(a,b){c=a+b;return c;}
Obviously the first version is easier to read, and therefore easier to maintain. As a developer, I would never write code like the second version. But because JavaScript is a scripting language (meaning that it is not compiled into machine language, it is interpreted by the scripting engine at runtime), it means that every byte from that first version gets sent across the network to the browser, comments and whitespace and all. The second version, however, is much smaller, meaning that it will take less time for the browser to download it over the wire. (In this case, the optimized JavaScript is 32 characters, vs. 177 characters for the more maintainable version—something like 82% smaller. Code with a lot of whitespace and comments, and code with long variable and function names, will end up looking a lot smaller in the optimized version, because there’s more stuff that can be stripped out and reduced.)

With GWT, we get the best of both worlds, because the developer works with easy to read, maintainable Java code, but the GWT “compilation” process spits out the more optimized version in JavaScript, to send across the wire.

A typical GWT development lifecycle will be similar to this:
  1. Developer begins developing in Java, using the Google Web Toolkit (quite probably in Eclipse, using the GWT Eclipse plug-ins)
  2. Developer tests code using the provided runtime; at this point the code is still Java code, allowing the developer to set breakpoints and debug
  3. Once the development is complete, the developer “compiles” the GWT application, to create the JavaScript, HTML, and CSS files
  4. These JavaScript, HTML, and CSS files are included in the larger web application
Of course, as development proceeds, the developer may be repeating steps 2–4.

The GWT compilation process can be controlled using normal Ant built scripts, so the overall build process for Java applications can be modified to include a build of the GWT code, and inclusion into the appropriate location in the larger WAR/EAR. For non-Java projects, you can simply “compile” your GWT code, and include the generated files (HTML and JavaScript and CSS and images) in your application.

It’s similar to what we talked about in the Computer Generated Code post; the code that you maintain, and actually work with as a developer, is strongly-typed, clean Java code, with all the comments and whitespace and readable variable names that you are used to. But the code that is actually produced for use at runtime is highly optimized, unreadable code, intended to be seen only by a machine, not a human.

The limitation will be how good GWT is at turning your Java code into JavaScript code. When I did a Proof of Concept application back in the Fall, for an AJAX application we were intending to build at work, I did two versions, one in “raw” JavaScript, and another using GWT. I found that the performance of the “raw” version was better than the GWT version—but, that being said, because of the nature of the GWT libraries, I ended up having to change how I did some things, so it’s not like the code was the same in both cases. It wasn’t a strict apples-to-apples comparison.

For the real application, we decided to use GWT anyway, though, for two reasons:
  1. Our developers are more familiar with Java than JavaScript, so the benefit of maintaining Java code instead of JavaScript was a big one. Especially since the application is a Java EE application; our Ant scripts could simply be updated to include steps to compile the GWT code, and then copy the resultant output files into the main application’s WAR file.
  2. A lesser reason is that there is a possibility that further optimizations might be introduced to GWT, improving the way it produces its JavaScript code. It’s possible that an updated version of GWT might produce even better JavaScript output. (Although it may also force us to change the way that we write our Java, so we can’t expect it to just magically make our code faster.)
GWT has been used to build numerous products/projects—including Google Wave, I might add—so it’s being used by real people to solve real problems. But there are also people who are skeptical about it, and when I was researching the best AJAX libraries to use for my project, I saw mixed reactions to the GWT way of doing things. However, I think it’s another great example of doing something similar to what we discussed in the Computer Generated Code post. Writing code in a manner that is more developer-friendly, and outputting code that is more machine-friendly (and, in this case, network-friendly).

Saturday, January 09, 2010

Google Wave

It’s been a while since I wrote a fawning post about how great Google technologies are, so it’s time I remedy that, and write a new fawning post about how great Google technologies are. Enter Google Wave. I started reading about it yesterday, and I think—I’m not sure, but I think—that I’m going to be blown away by this technology.

In a nutshell, Wave is a mashup of email, collaborative document writing (a la wikis), and instant messaging. In some ways this is simply incremental change to existing technology, but I think it’s one of those new ways of looking at things that has the potential to be a paradigm shift. To see what I mean, let’s take a very abbreviated look at the history of documents, email, and instant messaging:

  1. In the olden days, before computers were invented, people used to write documents using a pen, or with a typewriter, or using similar technologies. If they wanted to send a copy of that document to someone else, they would bring it to them, or send it by mail. That person, when they’d received the mail, could read the document, and mark it up using a pen or pencil, and mail it back to the original person. S/He could read those changes, and, if s/he so wished, write/print/type up another version of the document, incorporating any of the changes that s/he wanted to incorporate. If the people needed more immediate feedback than mail could provide, they could use a technology called the telephone to talk to each other, over great distances, for immediate feedback.
  2. Computers brought electronic versions of these technologies. Word processors and spreadsheet programs and presentation software replaced paper documents (or, at the very least, made it easier to create them—people still had a habit of printing them out, from time to time). Electronic mail, or email, replaced mail. We developed something called instant messaging for immediate communication, for those times when email was too slow, so that we can have a real-time conversation.
  3. These technologies changed how we communicate; instant messaging is largely replacing phone calls, even as it incorporates phone-like features (like voice chat) and improves on them (like video chat). Email is largely replacing physical mail, and the contempt we have for the speed of physical mail is apparent in its new moniker, “snail mail.” Email also changed the way that we correspond with each other; when you send an email, you can send it to multiple people, and when one replies to an email, the reply usually incorporates a copy of the original email, so that a conversation can be maintained. Email introduced the concept of reply all, which means that everyone can be included in the email conversation, and provide their input (if necessary). Emails can also be forwarded to others, even if they weren’t originally included, or, when replying to an email, you can simply add new people to the reply, if you think they should know about the conversation that’s happening.
  4. These technologies also changed the way that we wrote documents; with the ability to do everything electronically, we now had the ability to email a document to someone else, as an attachment, for them to read electronically, and then send a reply email back, with their comments on the document. Electronic documents made it much easier to incorporate changes, rather than having to write or type out another version of the document by hand.
  5. Soon the people making word processors and spreadsheets and presentation software started incorporating features into their products that made it even easier to do this. Things like track changes and the ability to add comments made it very easy to see what changes others were suggesting, and software got very good at merging different versions of documents together, even tracking who had made what changes.
  6. Looking for a way to keep our documents together in one place, people began creating document repositories. More than just a glorified file folder, these repositories included features like having multiple versions of a document, and workflow capabilities, and the ability to lock a document while editing it, so that nobody else can, until you’re done and you “check in” your changes.
  7. Even with these advances in editing, some people felt it wasn’t enough, and the wiki was born. A wiki was a web site that anyone could edit, and in some ways strove to replace the document. The obvious example is Wikipedia, the online encyclopaedia that anyone can contribute to, but wikis have also been used for things like documentation for software projects. (Rather than having a series of documents that must be kept up to date, the documentation for the project is a [potentially] always up to date web site, that can easily be searched and updated.)
  8. Despite the advent of the wiki, the vast majority of people were still creating documents, and emailing them back and forth as attachments, and using their track changes features to make changes. (Or they were simply replying to the original email, and saying things like, “You spelled a word wrong on page 4, paragraph 6. The diagram on page 9 is incorrect.”) Then Google came along with Google Docs, and gave us technology to put a document online, and let multiple people edit it at once, collaboratively. Google Docs turned documents into mini wikis. Now, instead of emailing a document as an attachment, for the person to edit and send back, forcing you to incorporate the changes, you would simply email (or IM) a link to the document, and the person would edit the document itself.
And this is about where we stand today. Wikis still exist, but aside from Wikipedia, they aren’t that prevalent. Despite the fact that I and others like me think Google Docs are cool, most of us (including myself) are still using applications like Microsoft Office to create our documents, and most of us are still using email to add these documents as attachments, to send to others. Interestingly even when we have a document repository—like Sharepoint, for example—we’re often still sending the documents as attachments; we could just send a link to the document in the repository, but in many cases someone doesn’t have access to the repository, and the document author usually isn’t the repository maintainer, so it’s much quicker to just email a copy of the document than to go through the red tape of getting the person granted access to the section of the repository that they need, to read the document. Email is, by far, the most prevalent means of communication, but instant messaging has also become an indispensable tool, both for work and personal use.

But still, even with the advances in technology we’re down to email (a replacement of snail mail, with some obvious improvements), instant messaging (a replacement of the telephone, with some obvious improvements), and electronic forms of documents (with some obvious improvements in how they’re created, but still, at the end of the day, are very much centred around the end product: the document.) Wikis are on the fringes, as a potential replacement for documents, but they haven’t gained traction as such.

So all of this to say, what is Google Wave? As mentioned, in some ways, it’s incremental technology, combining documents, email, and instant messaging into one technology. That was my first thought, when watching the hour and twenty minute long video where it was introduced. (Just in case that link expires, here’s the direct link to the YouTube video.) You can create a document, and multiple people can collaborate on it—just like Google Docs, you might say. You can receive notifications in your “inbox” when there are changes—just like in email, you might say (with a bit of an improvement). If people are online at the same time, you can see the changes they’re making as they make them, and you can send each other messages—just like instant messaging, you might say. Just like email, you can send someone a message, but when they respond to that message, they’re not limited to the usual message/response format we’re used to for email.

But here’s where the paradigm shift came in for me: email, documents, and instant messaging are all electronic versions of things we already used to do; with Google Wave, we have a potential replacement for email, documents, and instant messaging, creating a new paradigm that’s based on what computers can do, instead of simply trying to do the same old things we always did, with incremental improvements. (See this post on the Google Blog for an expansion on this.) With Google Wave, the line between an email and a document and an instant messaging conversation becomes blurred; what, really, is the difference between an email and a document? For the most part, just the length, and the means by which one can share it.

Today, when I want to communicate with someone, I have a few options:
  • For a quick conversation with a quick answer, I can open my IM client, see if the person is online, and start a conversation. If I want, I can include multiple people in the conversation (although most IM clients will limit this to around a half dozen people or so).
  • For something a bit more detailed, I can write an email, and send it to the person or people I want to communicate with. They can read the email, or, if required or desired, they can respond to it, and add their thoughts or make corrections on my original thoughts.
  • For something that I want to make more permanent and/or official, I can write a document, and email it as an attachment or put it in a document repository. Others can read the document, and, if required or desired, they can send an email back to me, with their thoughts or corrections. If they have permission, maybe they can edit the document itself, in the document repository, and their changes will become part of the document.
Three different ways of communicating my ideas, depending on the nature of those ideas. With Google Wave, all three of these would be something called a wave. I want to communicate something to a person or people, so I create my initial communication, it shows up in their inbox, and they can communicate back in the manner that they see fit; changes to the content, comments off to the side of the content, private messages to some people who are part of the wave but not to others… whatever makes sense. If the conversation becomes detailed/important enough, it will be shared and seen by more and more people, just like a document might in today’s world. If not, it might be a simple short communication between two people, just like an IM conversation might in today’s world.

We currently have three levels of “permanence” for our communications, from the throwaway IM conversations to the slightly more permanent emails—which are still locked in our inboxes, to be seen only by us and people we forward the emails to—to documents, which become artefacts and semi-permanent records of our thoughts or findings on a subject. Waves make these distinctions obsolete, and the only distinction in the wave world is how many people the information is shared with. (One question in my mind, however, is whether waves will have the immediacy of instant messaging; I can easily see that we might no longer need a distinction between email and documents, but when I get an IM, in today’s world, it’s something immediate, that I respond to immediately; will that still be the case, if it’s just one more wave hitting my inbox? I’m not sure.

Email has been around since the beginning of the internet, and, as mentioned, is the most prevalent form of communication on the internet. With Google Wave, we may have a serious contender for a new form of communication, with the potential to replace email. We may also have a new way of doing wiki-like things that will be more popular than wikis ever became.

It should also be mentioned that Google is doing this all open source, and creating generic protocols that can be used; this isn’t just a closed system, where you’d have to sign up with Google to get access. You can create a corporate “wave server,” similar to how we have corporate email servers today. And, just like email today, you’d have the ability to add people to your waves that aren’t on your corporate wave server (just like you can send emails to anyone on the internet), but also not give them access to waves that they shouldn’t have access to.

Unfortunately, Google Wave isn’t yet completely open to the public; you can just sign up, and they’ll let you know when you can join. So I’m going to sign up, and play with it when they let me in. Of course, it won’t really do me any good until I know someone else who uses it.