There is a new wiki-system called WetPaint that I recently had a chance to preview before its official launch (it then launched on June 19th, 2006). Before I get into this further, I want to point out a couple of things:
- I run the world’s largest wiki next to wikipedia: LyricWiki.org [1, 2], and this has given me quite a bit of experience dealing with and thinking about wikis.
- I have no vested interest in promoting WetPaint. I get pretty complementary in this article, so just remember that they’re not paying me or giving me any incentive. If I say their code is good it’s because… it’s good.
Although I still like the MediaWiki software that I use to run LyricWiki.org – the same software used on Wikipedia – I think it is safe to say that it’s been trumped. WetPaint uses MS-Word-like editing to remove the otherwise-substantial learning curve from contributing to a wiki. It’s sprinkled with AJAX to make the process faster, and it fixes a number of problems that come with MediaWiki and many other popular wiki tools. The way WetPaint works is that they host wikis, and they get revenue from some Google AdWords in the bottom of the right-hand column of the page. In the first two weeks after their launch, over 6,000 sites were created . A couple of these sites (set up during the private beta) appear to have been set up by Wetpaint themselves to show off the system – and presumably because the sites are useful anyway – including wikiCancer and wikiPregnancy.
I noticed several interesting things when poking around Wetpaint. Many of these features I only noticed because they were unfortunately absent in MediaWiki. Anyway, here’s the beef…
- The links to add a new page are very prominent, and it’s really easy to create sub-pages also. When creating a page, it will warn you as you are writing if the page name is a duplicate.
- Wetpaint makes very good use of tags. They’re easy to add, and they have a tag-cloud on the side of the page to make it easy for people to get intrigued and bounce around your site.
- Altough I have no benchmarks and there don’t seem to be any available online yet, Wetpaint seems significantly faster than the bloated MediaWiki. This is partially because Wetpaint uses AJAX so that only parts of the page need to be sent back and forth, and partially because MediaWiki is significantly slower than it should be – but I digress.
- The site is fairly cross-browser compatible. It supports Firefox 1.0.7 and higher (PC & Mac) and IE 6.0 for PCs . That’s not phenomenal for a wiki, but it’s really good as far as most AJAX sites go. The much-lauded ajaxWrite receives all sorts of attention even though it requires Firefox which abandons the vast majority of web users.
- Editing is intuitive and intentionally similar to Microsoft Word, effectively eliminating the learning curve for most users. As a person who runs a wiki (or four), I can’t emphasize enough how important this is. Not only have I spent countless hours correcting the pages created by people who don’t know how to deal with the proprietary wikitext-markup of each system, but I’ve also had to waste hours of coding-time making forms to make data-entry more intuitive.
- The comment system they made has the potential to be very viral. This may have existed in some wiki engines before – since there are so many of them – but I sure haven’t seen it. The only potential drawback I see with it is that visitors might get lost amongst the flame-wars and forget to come back to the content.
- There is an
auto-generated site map. This is good for search engines and for lost visitors. On the flipside, I checked it out a larger sitemap though, and it appears that it doesn’t scale itself yet. Therefore, if you have a humongous wiki (50,000 pages or so), this page may get to be a bit ridiculous.
==How Wetpaint can become the dominant wiki design==
Wetpaint is one sweet pile of code. There is no reason that a system as well-created as Wetpaint can’t become the dominant wiki design. Since I’ve had some good luck in the wiki-industry, I’ll wax-prophetic for a moment on how Wetpaint can make sure they become the dominant design.
- Develop importing from other wikis. This decreases switching costs allowing many of the other well-established wikis to abandon their former engines. WordPress did this with a very high level of success in blogging-software.
- Make a developer network! This is important. If they make a SOAP webservice and encourage developers to make plugins, skins, and utilize their API for other programs and mashups, there is a great deal of potential for really cool things to be created. Things that would further Wetpaint’s grasp on the market. In addition to the basics, they should have a very strong platform for letting wiki-owners easily create bots. Wikis with bots are far more effective than those without bots. Since wikis have one structure and many different types of sites are crammed into them, normal maintenance through the database is hard. In the case of Wetpaint it would actually be impossible since it is a hosting solution (it just wouldn’t be safe). If a wiki-admin can create a powerful bot, they can keep their site from becoming messy.
- They need a wiki about their own site.
- Get Business 2.0 and their blog to worship Wetpaint (as they should)
- Think about alternate business models (sell a CD with an archive in a specially browseable format, possibly publish books from the content). The only reason I can think of that the majority of wikis aren’t going to jump onto Wetpaint like geese on June bugs (that was lame) is that they are only a hosted solution. See below for more on this.
- Bonus: Some sort of anti-spam solution. Spamming is one of the biggest problems with wikis today. If they could think of a way to combat it, they would have a strong competitive advantage.
==Hosted versus installed==
Right now, Wetpaint has joined the ranks of JotSpot, pbwiki, Wikia, and Atlassian as a hosted-wiki provider. I have full confidence that they can dispatch of those companies fairly well. It will take some time though, because they all seem to have some Bubble 2.0 cash to burn through.If they are happy enough with this, then so be it. But if they want to be the only standard for wikis, they have to figure out a way to compete with installed wiki software. When companies have their own servers, they are often more than happy to use installed wikis even for their enterprise wikis which eats at Wetpaint’s potential market. The reason I run MediaWiki instead of switching over to Wetpaint is that by installing an open source package, you have full control. If LyricWiki does decide to put Google AdWords on the side of my page, LyricWiki will get the money. In addition, I have the option (which I have exercised quite a bit) to change the code around to make it better suit my needs. Of course, I have to concede to the hosted-sites that upgrading MediaWiki is a pain, especially when you have modified some of the code in a way other than an official extension.
Wetpaint is awesome, there is no doubting that. The code is top-notch and the management seem to know what they’re doing. This site is going one direction… up! In times when the 2.0 bubble is spawning countless new businesses based solely on buzzwords, it’s nice to see a company do it right and use the new tools available to build a solid, easy-to-use product. Good job guys.
1: WikiStats by S23 – List of largest Wikis http://s23.org/wikistats/wikis_html.php
2: List of Largest wikis http://meta.wikimedia.org/wiki/List_of_largest_wikis
3: Email-conversation with Chris Kollas of WetPaint.
4: About Wetpaint Sites – Frequently Asked Questions http://faq.wetpaint.com/page/1.%20About%20Wetpaint%20Sites
* More browser statistics http://www.w3schools.com/browsers/browsers_stats.asp
* List of the top 100 wikis on Wetpaint http://www.wetpaint.com/more