Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta

Saturday
Jun162007

Screwturn powered front-end for your mISV

I have just finished to migrate all the web content of Lokad.com into a brand new skinned Screwturn wiki instance. Thanks to the design skills of Sergey Pozhilov, the result does not look bad :-) .

I have been writing about wiki misuses in the past. One of my recommendation of at the time was do not use wikis for public diffusion. I still believe that this recommendation is a good one (even highly popular forums have hard time to get anybody contributing to a wiki). In fact, even if Lokad.com is now hosted in a wiki instance, the accesses have been restricted to the Lokad team. Thus, we are using Screwturn as a CMS and not as a wiki.

This migration was the 3rd step:

1. At first, the Lokad web application and website were mixed. As a result, it was taking as much effort to update the web application or the website. The situation was just painful by design.

2. Web application and website have been separated. The website was now regular static HTML. The update overhead was still significant, FTP being just a pain when it comes to fix typos.

3. We have hired a professional designer to get a decent XHTML skin and then we have migrated the web content into a skinned Screwturn instance. The update overhead is now super-low.

Do not break URLs: When migrating your web pages, it's important to include the proper redirections. I have been using UrlRewritingNet, a nice open-source URL rewriting tool. UrlRewritingNet is very convenient to migrate ASP.NET pages because ISS does not intercept the requests even before they hit the ASP.NET machine.

Benefits of the Screwturn CMS for your mISV

I have been relying on a CMS for 48h to manage Lokad.com, I do not think I am ever going to move backward toward a static HTML again.

• wiki markup is more compact and more readable than HTML. Page editing becomes easier and faster. Ok, most wikipedians have been knowing that for ages, but I would expect the percentage of websites relying on compact markup to be still quite low.

• snippets are really convenient for website templating. The concept is both simple and powerful. After going through 70 web pages, I find snippets way more practical than ASP.NET master pages.

• spell checking is native because Firefox becomes your IDE. Visual Studio should have been supporting spell checking for ages, meantime you can still use CodeSpell.

• native user accesses management simplifies the task of integrating external contributors, typically professional translators, writers or proofreaders...

Scripting tricks for Screwturn

When it comes to skinning an ASP.NET application, the goal is to change the minimal amount of lines of ASP.NET code (optimally zero) during the skinning process. This process ensures that upgrading toward the next version of the ASP.NET application will be painless. Thus, I have been resorting to a couple of client scripts to avoid touching the ASP.NET code.

The search box is using

<a href="javascript:document.location =     'Search.aspx?FullText=1&Categories=&Query='     + encodeURI(document.getElementById('TxtSearchBox').value);">search</a>

The Edit and History links are using

<a href="javascript:document.location = 'Edit.aspx?Page=' + encodeURI(   document.location.pathname.substring(1,document.location.pathname.length - 5));">Edit</a><a href="javascript:document.location = 'History.aspx?Page=' + encodeURI(   document.location.pathname.substring(1,document.location.pathname.length - 5));">History</a>

Finally, the navigation tabs rely on a small script dynamically adjusting the CSS classes.

<script type="text/javascript">   var navItem = document.getElementById('HomeTab');   navItem.className = 'active';</script>
Sunday
Feb042007

WetPaint is far too expensive, migrate or die

WetPaint is a hosted wiki solution. Although Wetpaint still lacks from "professional" wiki features like being able to insert custom HTML or scripts, it's a nice, simple wiki application with a great look&feel. I have triedWetPaint, I did even use it for while for Lokad.com; but looking back, it turned out to be a really BAD move. I have finally manually removed all the content from my wetpaint wiki (because there is no "Remove my wiki" feature available); and I have migrated all the content to community.lokad.com, a wiki powered by ScrewTurn.

It can be argued that moving to ScrewTurn may not be the optimal solution (they are tons of open source wiki software available out there, see the wiki matrix ); but moving away from Wetpaint is the only solution that can be considered if you fall into the WetPaint trap. Yes, to all the people using WetPaints, I strongly suggest to re-consider and start thinking about moving your wiki somewhere else.

For those who thinks that wetpaint is a "free" wiki, it's not. It's neither free as in "libre" nor free as in "free beer". Wetpaint inserts Google Ads in your wiki without providing a paid subscription plan to remove them. Let's look at the problem this way: if the traffic of your wiki stay low, then any $2/month hosting solution will be sufficient to host your website; but if your web traffic starts to go up, then WetPaint takes 100% of the advertising profits generated by your content. No matter how you look at it, the content of your wiki is worth more than$10/month, the price to get an hosted wiki. As, Jacob Nielsen pointed out long before me, free solutions have terrific costs. If you think that the wiki that you are starting is not even worth \$10/month; then starting a wiki might not be a good idea in the first place.

This is the WetPaint trap; and I have been sufficiently foolish to fall for it for almost two weeks. Actually WetPaint people are smart, thus, as long as they are able to track you (through Cookies), WetPaint don't display any ads. The longer it takes to realize the situation, the more painful the migration. Migrate now or you will soon experiment the true cost of this free application.

Tuesday
Oct102006

Wiki misuses (collaborative tools, part 1)

Great software development requires great tools; but tools do very little in themselves if the craftsman lacks the proper skills. In my (limited) experience, I have noticed that collaborative tools are often extremely useful (i.e. provide strong productivity boosts) while also being quite hard to master.

There are far too many collaborative tools to discuss for a single blog post; I will start with the wikis.

Why do you need a wiki?

There are many other ways to communicate and information within a development team, namely person to person talk, email conversations, source code comments, discussion boards, blogs, instant messengers, phone calls ... and the list goes on. There is no magic in wikis; they won't be a substitute for all that.

Let's start with some wiki misuses, i.e. the kind of things that does not work very well with wikis. I am not saying that it is not possible to use a wiki in the situations listed below (it always "possible"); but I feel that those situations are simply ill-adapted to be handled by wikis.

Wiki-based documentations are poor documentations (probability = high)

A wiki is not a substitute for proper reference documentation. In this domain, two of my poorest user experience while trying to get some reference documentation were the WordPress wiki and the JotSpot wiki although I am quite a fan of those two products. What's the problem here? Well, quite simply there is simply no reason for the consumer to contribute to the reference documentation (I say "consumer" to refer to whoever is consuming the documentation). Therefore, do not expect any interaction at that such level.

As a secondary point, it can also be argued that a reference documentation requires to be highly structured usually following closely the source code design itself); otherwise it's just a pain to navigate through. Wikis do not encourage (nor provide any automated mechanisms) to support such structures. In this respect, one of best software documentation that I have ever encountered is the ZeroC Ice documentation (but I am moving away from the topic of this post).

Wikis aren't that good for open diffusion (probability = high)

I know that Wikipedia is living counter-example of the title of this section. Yet, wikis are on average quite inappropriate for open diffusion. When I say open, I mean referring to a wiki that is not restricted to the development team.

A primary issue with wiki is that they aren't that much appealing in terms of layout and navigation. Yes, it is possible to customize the appearance and the navigation system of a wiki, but by doing so, you're going back to regular website development. The Math.Net open-source project is quite illustrative in this matter. Have a look at the Math.Net project page vs. the Math.Net wiki. Which one of those two pages looks better in your opinion? OK, I know you're not going to look at those pages, so just trust me.

A second issue with wiki is that the information is usually rougher and less structured compared to classic "static" page. This point is not an issue in itself, enabling some kind of fuzzy teamwork is actually one of the main benefits of the wiki. Yet your wiki is likely to act as information pollution for the occasional visitor.

The last issue with open wikis is that they are putting boldness requirements quite high. Indeed, a main challenge with wikis is to get people involved. This point is true for almost every collaborative tool. Self-confidence is one of the strongest hindering factors when it comes to wiki writing. By opening your wiki, you are putting quite a lot of pressure on your potential contributors compared to the internal wiki situation.

More on Good wiki management soon, stay tuned...