I did a bunch of research on various wiki farms and engines for a consulting client awhile back. As part of that, I investigated JotSpot when it was in beta (an actual beta, not the kind of perenial beta that we see these days) as one example of a sophistcated wiki farm/service. I had some back-and-forth emails with Joe Kraus, CEO and founder of Jot, and the original president of Excite, as well. Their original, proposed pricing model was one based on a per-user (per-seat) charge. I commented to Joe that I thought that was not a great idea, as the value of wikis is established by the number of users. Charging for bandwidth, features or drive space... sure. Those are commodities. But users? Don't put any bars on that. To a degree, they listened and the Jot model ended up with tiered pricing; the cheapest "infinite users" subscription was $70/month. Which was still a heckuvalot less expensive than many of their competitors in the "corporate" or (as Jot calls it) "application" wiki space.
Well... now it's a lot less expensive. Google has bought Jot, and all their current customers will pay... zero. Niente. Nada. Diddly. The usual Google charge for consumer-level services, eh? You can't get a new Jot account until they've "migrated into Google's systems," but... one suspects a free option will be available there, too.
Them's the facts. As always, you now get a heapin' helpin' of my speculation.
Let's start with how last March, Google bought their first wiki... Writely. Now known as "Google Docs and Spreadsheets."
Oops. I'm sorry. Did I say that when they bought Writely, that was a purchase of their first wiki? Oh, dear. I'm sorry. I have to go back now and read the approx. 1,800,000 results on Google for the phrase "google buys writely" and check... Nope. They all say that Writely is a "browser based word processor," or "online word process," or "Web-enabled word processor." There are a couple blog posts and articles that discuss Writely's "collaborative word processor capabilities," and a very few smaller outlets that notice that Writely is, in fact...
A good, Flash-enabled, WYSIWYG-front-end wiki.
If you have a Gmail account, you can use Google Docs and Spreadsheets. Go try it. You can create a doc or spreadsheet and save it to your account. It has a unique URL with a long, weird, Gmail/email lookin' name. But you can assign it a document-looking name inside your account. And you can link from file to file with a nice, easy drop-down. And to outside URLs. And you can share those documents with others for editing.
And those "documents" live on the Web. On Google's servers. You say "document," I say "Web page." Potato, potato.
Folders vs. Pages vs. Users
In the MS-DOS and Windows world, we have folders and sub-folders. In a Web world, we have pages and sub-pages. In a wiki world, we have users, groups and permissions. This is an extremely important difference. It is a difference of focus and use. It may be (I say "may" with a huge grain of salt and much humility) the main difference between Microsoft and Google.
In a Windows/Web/Folder-centric universe, tasks and relationships play 2nd-fiddle to files. You have to put "the thing" somewhere, and then know where it is, be able to get to it, be able to move it, or copy it, or delete it in order to be effective with it. In a wiki-centric universe, yes... stuff still needs an original place to live. But the emphasis is on the connections made to it, the relationships of the people making the connections, and the meta-data related to those people.
Here's a detail to make this (hopefully) a bit clearer. One of the neat things about JotSpot was that every page on their wikis was assigned a "key word," which, when appended to the URL of the page, turned it into an email address. So you could send an email *to* that page of the wiki. The message was then stored like a comment on that page. Even if your user-level didn't give you permission to edit a page of the wiki, the admin could turn on the "email to page" function and allow folks to append comments that way.
So... let's say you've got a project going and you create a wiki page to be the "central repository" for all information related to that project. Project Manager John Jacob creates the page and has full editorial control over it. He gives write/edit access for that page to the members of his team, and allows everyone in the department to view the page and add comments, but anyone outside his department cannot view anything except the page description, with a note to call him if they need "in on it." It's a "porous intranet," so some pages are open to the public; this one isn't at all. Without a login/password, you see nothing. All of the pages created as sub-pages directly from the main project page "inherit" the permission structure John set up (last I checked, Jot doesn't do this, but EditMe does, it's very handy, and, I hope, Jot catches on). But the authors of the sub pages can, if they need to, alter the specific permissions of those pages in order to invite other individuals who aren't included in the original, or keep out those who are. For example, Creative Director Mandy Marr creates a page for all documents that will need to be reviewed by the Legal Department and gives permission for Chief Counsel Cliff Cramer to view/edit that page. He cannot, however, "step upwards" and see/edit stuff in the main page, just because she's added him to the sub-page permissions.
Also... some of the sub-pages that are protected from other departments will have links that go to pages that aren't. No big deal. Or they'll have links to pages with other overlapping permissions. Again... NBD. Each page's permission is defined by what makes sense for that page. A page that has to do with Legal and HR but not marketing will have those permissions, etc. etc.
Now... let's add in a concept like document approval. Tack on an application that adds an "approve attached document" level of permission as well as view/edit, and you've got a work-flow tool. Jot includes a bunch of similar tools at this point. And they've just been bought by Google, which has a built in calendar, email, etc. And Google is also providing "Google Aps" that plug into your web site.
Imagine trying to do this in a network, drive-letter, folder/sub-folder model. It can only happen when the relationships are at the center of the idea, when the creation of new content and links is core, and when the model is based on the similarity of function, not feature creep.
It's free. It's not monetized. And I don't care.
Google is a great search engine, and it makes its money off of billions of tiny ads. All well and good. I suppose. So far. And I like Writely (Google Docs). I've used it, and it works very well. And I like Jot a lot (aside from, when last I checked a few months ago, its upside-down permission structure. If you want to know what I mean, either email me or leave a comment; it's complicated and a side issue; at the moment, EditMe has the best, most granular and intuitive user/group/permission structure I've encountered for wikis).
I think there's a definite benefit that's going to come out of mashing the Writely WYSIWYG front-end (which is considerably slicker) onto Jot's wiki engine (which is considerably deeper). There are applications for combining this with Gmail that might enable a wiki-based email system, for example, that would make spam much harder. You could publish your wiki address instead of an email address and require anyone who wants to email you to register through your homepage, and the system could do some decent anti-spam checking. For systems where you will be receiving automated email, or where you don't want someone to have to register, you simply create and designate a sub-page of the wiki to receive that kind of email. You could have a different page for every email relationship if you want. If a spammer gets ahold of the sub-page, you simply delete it, rather than an entire email account. How do you keep track of your email if its all living on 37 different wiki pages? By RSS feed, of course. Your email reader is another page in the wiki with an RSS feed-reader set up to monitor any page you've designated, some of which would be email tagets. Get a new email from mom on the "family email" page, it lights up on the RSS reader page.
All this is good, right? Free word processing wiki engine email web site creating permission based Google-tastic future-topia. Sure. Again... I suppose. Right now, Google is doing lots of this free stuff as marketing and brand. They provide free services (chiefly search) and fund it via advertising. This other stuff -- the email and videos and word processing and wikis -- is, currently, not monetized. And even if it never is... I don't care. Because it is adding to the brand experience for Google's users. The search box is free. The email is free. The word processing is free. The videos on YouTube (which they just bought) are free. The wiki is free. The blog (they own Blogger, remember?) is free. It's all free. Except for the ads. The ads pay for everything, and that's OK. The ads are very transparent.
What is going to be the difference in brand perception between a user of a Microsoft product (that probably, at this point, still requires payment), and a Google product? Microsoft = pay for it. Google = free. In America, free is one of the most powerful words in the marketing lexicon. On the Web, stuff is supposed to be free. Does this make sense? Is it rational? Can it go on forever? I don't know. But the idea that somebody else's advertising budget is paying for my word processor, blog and wiki... that's pretty powerful. And the idea that I can then use those tools to make content that others might find interesting, and that might drive traffic to that advertiser's product... hmm... it's an economy of content. Go figure.
No comments:
Post a Comment