Archive for September, 2008

Today I have re-established the ability to select text from a Wikipedia article when just adding facts to an existing term.

This feature was originally integrated when I created the feature for the Add Term page but then due to refactoring reasons (basically I moved the newly entered facts on the term page onto the sidebar) I had to remove it from the “Add a Fact” section at each term.

Probably you already know how, but still I have attached a picture on how adding facts through Wikipedia works:

Over time I plan to bring more external sources to your fingertip when adding terms or fact. I am open for suggestions on this!

It’s not quite unusual that new ideas can be hard to grasp. People come to our web page and see knowledge presented in an usual form, equipped with checkboxes and the like. We need to be able to tell everyone quickly what Factolex is about and what makes it cool and unique.

We have therefore been working on a feature that we internally call “Tour,” because it just uses one box to explain the most important functionalities of Factolex. Here is a screenshot:

But be aware that this image is only half fun because I integrated some eye-candy scrolling effect ;)

You can check it out on the Factolex Homepage or on almost every other page where we have placed it on top of the side bar.

Among the most difficult decisions we have been facing is the part about user contribution and how this should be linked to user registration.

Most of you probably know that on the big Wikipedia, they don’t force people to register to have them contribute something. This takes away a barrier for people just wanting to change something right away. The other barriers like complicated wiki syntax remain, of course.

One reason that this is possible at Wikipedia, is that if someone vandalizes a page, the next user can revert that change easily and just by himself.

Things are a little different at Factolex. As we rely on people deciding how good or bad a fact is, offending material or spam will take its time until it disappears. For this reason we decided to introduce a registration barrier but tried to ease it at several points.

The common approach: Make people register before you let them edit something

This is also the easiest to code, and most sites do it like that. The problem is that as a new user I have to give my data upfront without knowing if I like how the site does it or not.

It’s a huge amount of trust that your (unknown and not (yet) trustworthy) site asks from the user. So that’s not the way we wanted to go.

Let people enter what they intend to enter and make them register afterwards

First, let the user enter what they were just about to add. This way you don’t distract him in his creative phase.

Only then take him to the register screen.

Note at the bottom of the screenshot: We present the term that had just been entered by the user to prove that we still have it.

As mentioned earlier, this is indeed more difficult to code. It not only takes more time but also makes the code more complex, but I think it’s worth the trouble. But in fact this doesn’t go far enough for me.

Don’t really force the user to register

Now this is what I like on the web! I actually don’t want to register until I am sure that the service is useful to me. And this is also the approach we take. After you have entered a term, you will see it like this:

The grey stripes indicate that the data is not public. This way the user can use the site completely unregistered, seeing all the features in action, before he decides to register.

Even if the user does not decide to register, we reserve the right to have other users publish what has been entered by unregistered users. That way knowledge entered is never lost.