While people are busy writing about what Google is doing or what they might do in the future, I would like to stop for a second and look at what they have not done. Google is pretty strong on collaboration tools: they have email (Gmail), chat (Google Talk), forums (Google Groups), and blogs (Blogger), amongst others. But Google doesn't have any Wiki or Wiki-like tool. Doesn't that get you thinking?
Two conditions have to be satisfied for a Wiki to be an effective collaboration tool:
- The community using the Wiki must work towards a common and specific goal.
- The community using the Wiki must be large enough relative to the number of pages in the Wiki. In other terms, we get into troubles when the page per person ratio gets too high.
If the two conditions are not met, the Wiki quickly become disorganized. Information becomes hard to find. And even worse, it gets harder to know where new information should be posted, which discourages people from posting new things on the Wiki.
So what happens in those cases? Does it mean that collaboration is not possible? No, it just means that a Wiki is not the best tool. The solution is instead to have a document-based approach. Imagine Word and Excel, but with documents entirely created, edited, and shared online. And in fact, you don't need to imagine: Google just did that with Google Spreadsheets and Writely they acquired earlier this year, which they put together under the just released Google Docs and Spreadsheets.
Google Docs and Spreadsheets is a collaboration tool. Some will go as far as saying that it competes head-on with Wikis. I think that instead it complements Wikis, allowing more efficient collaboration in those cases where there is not a strong enough overarching goal or a large enough community to make a Wiki effective (which, in my experience is the case more often than not). Google Docs and Spreadsheets, and more generally the document-based approach, provides a good collaboration solution because:
- Each document might be larger than a Wiki page, but it is much smaller than a whole Wiki. So it is easier to find a common goal amongst people working on the document, and keep the document organized.
- While Wiki pages need to be constantly kept organized, documents are more like emails: you focus on your current emails, those are in your inbox or at the top of the list. Older emails are still there, you can still find them, but they don't get in your way. You don't need to keep them organized. The same is true with documents: older documents and spreadsheets that you haven't even looked at recently will just fall to the bottom of the list.
- Everyone is very familiar with the concept of document: We know we can send them around. We can have each document shared with a different set of people. We can archive them. We can save them in a format that allows us to work on them while we are on a plane...
- And finally, while this might be a implementation deficiency on the part of Wikis, it is an important one: documents are WYSIWYG, Wikis are not. Documents don't have a "view" and an "edit" mode, with the "edit" mode sometimes even using a cryptic syntax. With documents, and in particular Google Docs & Spreadsheets, when you have a document in front of you, you can always modify it right there. It is even more than WYSIWYG: in the case of Google Spreadsheets if you and another person have opened the same spreadsheet on two different computers, as soon as modify the content of a cell and press enter, your modification will show up right away on the other person's computer. The same is true with Google Docs: two or more people can edit the same document at the same time and see with a small delay modifications done by other parties. This is collaboration.
Wikis are used for many different purposes. They are different things to different people, and my comments here are based on my experience. I don't pretend to be in a position to have an overarching conclusion regarding Wikis. Instead, I would be interested to read what you think. Is your experience different? Just leave your comments here :).
I won't respond on the Wiki part, since that's Alex's article ;-) Regarding the blog comments, you are right, logging in is a pain, and probably discourages people to post comments (I constantly have to login on people's blogs when I have to post comments, and you really have to badly want to post a comment to go through that.) I believe that initially we setup the comments to be more open, and closed them a bit after we started getting too much spam. We should check how we can configure WordPress to behave in a more user-friendly manner.
First, I fully agree with your comment about implementing a Captcha instead of requiring a login. This just is one of those thing that seems to never get quite high enough on our priority list.
Technically, Wikis and documents on Google Docs can be quite similar, I agree. You could use Google Docs as a Wiki, always inviting the same set of people to collaborate on every document you create, and adding links between documents, thus creating a whole. However this is not how people are using Google Docs: they create a document, share it with a few other people. Create another document, share it with another set of people. At some point the first document is not relevant anymore, and nobody uses it anymore. It just stays there for reference, just like an other email thread.
Pages on a Wiki are not unlike pages of a book: by design they form a whole. When a new editions of the book comes out, new pages are added, some old pages are removed, but overall all pages are (or should be) updated along the way to keep the whole consistent.
You can see Google Docs as an evolution on the Wikis as they are today. But because the work flow that happens around documents on Google Docs is so different than what happens on Wikis, I like to see those as two different branches, on the same "collaboration tools" tree. And if I had to bet on the one I think will be the most successful, you know which one I would pick. :)
Google Wiki 'R' Us:ReplyDelete
This is a quote from an email from the JotSpot team:
"We're writing to let you know that Google has acquired JotSpot. We believe this is great news for our users. More importantly, we want to reassure you that you'll continue to have uninterrupted access to your account. Both Google and JotSpot are committed to supporting our customers, and we understand that users have invested a lot in our products. In the near-term, we're focused on migrating JotSpot to Google's systems and datacenters. We'll work hard to make that move as seamless as possible so that customers won't be inconvenienced.
Why is Google acquiring JotSpot?
Google shares JotSpot's vision for helping people collaborate, share and work together online. JotSpot's team and technology are a strong fit with existing Google products like Google Docs & Spreadsheets and Google Groups.
What does this mean for JotSpot customers?
We believe that joining Google will accelerate our team's vision of offering users the best collaboration platform on the web. Google shares that vision and presents us with the world's best environment for delivering on it. We'll be taking advantage of Google's world-class systems infrastructure and operations expertise to ensure that access to your JotSpot is fast and reliable. We can't share any of our plans publicly just yet, but we can tell you that we're incredibly excited about the possibilities. We can't think of a better company to have been acquired by.
Will paying customers still be charged?
We will no longer be billing customers for the use of the service. Although you will still have use of the product at your current pricing plan, we won't charge you anymore when your current billing cycle expires.
What about security and privacy?
Your data is yours — that doesn't change at Google. We will continue to work to ensure the privacy and security of your data. Furthermore, Google is as committed to privacy and security as we are. Since the user information you provided to JotSpot will soon be transferred to Google as part of their acquisition of JotSpot, we want to provide you with the opportunity to retrieve your user information and cease usage of the JotSpot service before the transition. If you do not wish to continue using JotSpot, send an email to email@example.com in the next sixty days and we will reply with instructions for retrieving your user information.
Answers to more frequently asked questions are available at http://www.jot.com/. If you have any other questions, please email firstname.lastname@example.org.
In closing, we wanted to offer our sincere gratitude to you — our customers — for believing in us and helping us achieve success. We look forward to continuing that relationship at Google.
The JotSpot Team"
Alex, while reading your response, I have imagined the following separation line between "Google Doc" and Wiki.ReplyDelete
Google Doc : versioning through copy-and-paste for creating new documents
Wiki : versioning in-place (overlapping versioning)
Just to help me to think about "Google Doc" and Wiki.
Once WYSIWYG HTML editors will be included inside wikis, the distance with Google Doc will be shortened. Then, at least one difference remains: the versioning way-of-document-life you mention. OK, there is a difference, but I think wikis can support also the "Google Doc" way. I see it as a plus: wikis have a good potential, even if today's wikis are not so much user-friendly...
The other wiki advantage I see is the API wikis offer. The wiki API enables integration and worflow definition. For example, imagine the following use case: (1) users post questions for a FAQ, using WYSIWYG editors, (2) questions are forwarded to an internal project mailing list, or to an RSS/Atom feed (through integration provided by wiki API), (3) project developers react while defining a response through the same editor.
That's a use case I really like to see implemented as FAQs looks like often quite dead, or too much static. And as a consequence, I think mailing lists are sometimes polluted with some questions that might be also answered through FAQ and then, alleviate the burden of project developers.
It looks like advanced editor/wiki integration has potential.