Google Wave: What I'd Like To Use It For

This week there's been a lot of chatter about something called Google Wave. The reason the buzz ramped up this week is that Tuesday Google announced that they would be expanding their beta-testing to 100,000 more users (plus their friends and relatives, apparently, because each invite comes with more invites for buddies attached). Wave is not something that is easy to explain in a few words, although the concepts are not hard to understand. It's kind of like email, except with the immediacy of an instant message and the editability of an online document. I know, that doesn't seem to make sense, so you have a couple of options to get you up to speed for this post. You can go to wave.google.com and watch their eighty-minute video... but who in the heck in this Twitterized, cell-phone-infused world has eighty minutes to sit and watch a video online? Instead, I recommend that you take a look at this one. It's a lot of fun to watch, is quite a bit shorter than the ten minutes they mention at the beginning, and it'll help you wrap your head around the basics:



Back? OK, so that kind of explains it. If you're still having trouble or want some more detail, I thought this Lifehacker article was helpful. Go ahead, I'll wait for ya.

...

OK. So Google Wave is looking like the coolest thing to come down the pike in a long time. Basically, it's a platform that a bunch of other things can kind of piggyback on. Now, I've been reading some articles on how people envision that Wave might be helpful in what they do... businessmen, for example, or newspaper writers or even filmmakers. For myself, the first thing I thought of when I saw it was, "That looks MUCH nicer than Facebook!" Indeed, some have speculated as to whether Wave could eventually do in both Facebook and Twitter, and I agree that it may give them (or the bug-riddled Facebook, at least) a run for their money at some point (of course, if they're smart they may actually incorporate the Google Wave technology themselves and then it becomes a question of who has the cooler interface and the most users, but anyway). But the more I thought about the capabilities of this thing, the more my mind started going in another direction.

Where I work we've been on a quest to find an effective trouble-ticket system. Our business is almost completely centered around what we can do with our Web sites, and customized computer coding is what I do all day long. When something is wrong with one of our sites, we get an email or a phone call, or sometimes we get a "drive-by" request (those are pretty common when your office is on the way to the bathroom for a lot of people!). Once upon a time we hired a contractor to build a trouble-ticketing system for us. It worked OK, and it was integrated with our internal systems, but there were still some things about it that were inflexible and caused problems. To a computer programmer, writing a ticketing system (someone logs a problem into the system, it is classified and prioritized, someone works on it and solves the problem, the ticket is closed, end of story) seems like a deceptively simple task, but things get complicated VERY quickly. Who can see the ticket I'm working on? The person who submitted it? What if they called it in on the phone and someone else keyed it in? Can they see my comments? I need to add a comment that is critical for developers but which might be confusing for end-users. What do I do with the screen shot the user emailed to me? What about this pdf they sent in as an example? Trust me, it gets crazy quick. So we abandoned the home-grown system and began shopping.

First we tried out a system called Trac which our I.T. director had used at a previous job. Trac is a combination wiki/ticketing system, and there are some things it does incredibly well... automatically linking text in the format "#123" to trouble ticket #123, for example. We ran into problems, though, when we tried to figure out ways for our customers to see the status of their tickets. There's just no obvious way to show part of what's in the system; it's pretty much an all-or-nothing proposition. So the I.T. director went shopping elsewhere.

Enter Jira. Besides the fact that the name makes me want to say "Gojira! Gojira!", the software is able to do all of the things we need it to... there is a flexible permissions system that allows you to show things to only the people who need to see them, but there are other great bells and whistles (like pasting in a screen shot directly from your Windows clipboard... how cool is THAT?) that impressed us so much that we are likely going to adopt it as our new ticketing system very soon. (It is a commercial product, by the way, but I am receiving no compensation for mentioning them.)

But just for a second, let's think about how Google Wave could be used as a trouble ticketing system. The hypothetical Wave-based ticketing system need not reside on Google's servers; the platform will be open-sourced, so the ticketing service could be a private machine owned by the company using it, or it could even be on a third-party hosting provider. Each new ticket would be a wave (when "wave" is lower-case, it means a particular "message thread" or "document", as opposed to the upper-case "Wave" referring to Google's product as a whole). When a ticket is opened by internal personnel, all of the stakeholders could easily be added to the wave; if the ticket comes from an external source, when the staff became aware of it they could add stakeholders to the wave themselves. As progress is made on the ticket, technicians could update the wave, and even add questions for the client; the client could modify or add information as necessary. I was particularly intrigued when I visited the Wave extensions page and saw the Ribbit extension. Assuming enough storage space is available to store them, the wave could conceivably hold the entire contents of a conference call, recorded for reference back if needed! Tickets could also be submitted via telephone and immediately and automatically added to the appropriate waves. Those audio tickets would be exactly what the client requested, with no intentional or unintentional translating done during data entry. The phone call IS the request.

The possibility of adding robust phone call/teleconference recording capabilities to the wave would be what would make it a killer app for trouble ticketing. One of the most frustrating problems we have with some of the people that we do work for is that a request is placed via telephone and either misunderstood or forgotten, and then it winds up never getting taken care of properly (or messed up, which may or may not be worse!) To be able to go back and follow every part of the ticket wave through its complete development, to have that granularity on the project, would be invaluable. It would be like the difference of getting where you want to go via horse cart, automobile, or jet plane.

Why oh why couldn't I have been one of those first 100,000 to request access? :)