Jungledragon Blog

Two weeks ago, I demonstrated how I integrated a number of capabilities into the JungleDragon class system. The basic idea being that if you move up in the food chain, you get more power, for example more influence in voting, or the ability to edit image metadata of others:

In the screenshot above you see that the Mountain Gorilla, one of the highest classes in JungleDragon, has the ability to edit image metadata (such as an image title, description and tags) of images uploaded by other users. The idea behind this concept is that high class users (who have proven to be of great added value) get moderation power and that this improves data quality.

By providing this capability only to high class users, my ideas was that it offloads data moderation to the community itself. JungleDragon should not only be user-generated, it should also be user-moderated. Then came in a comment from a certain Joe:

“I find this to be a very interesting concept. In fact, you will get the same dynamic as in wikipedia. However, be sure to keep versioning of the information changed because someone could change something that was correct. So the author or a super-moderator could always decide to roll-back.”

My initial thought was that this is a good point. However, it would be a lot of work to implement. Plus, I kind of assumed that high class users will make image edits that are good enough to not be rolled back. I gave the idea some thought for a few days and then came to the conclusion that I do need to implement this. The implication of this decision is large, I will explain why later on. First, allow me to demonstrate how I built image versioning and what it looks like.

The scenario

On this screenshot tour I will demonstrate the following scenario:

• User 1, called “fchristant” uploads an image and applies basic metadata
• User 2, called “jungle” edits and enriches the metadata of the image
• User 1 does not like the edit made by User 2 and rolls back the change

Enough talk. Let’s see how. First, “fchristant” has uploaded an image. He has only filled out the image title field, which is the only required field. Here’s what it looks like:

Zooming in a little on the right sidebar, we see the upload timestamp and user:

Now, we log in as user “jungle” and visit the same image page. “Jungle” clicks the “Edit details” button in the image button bar:

The edit screen is presented and user “Jungle” decides to enrich the image data by supplying a description and some tags:

An noteworthy detail is that the “License” field can only be edited by the image owner, therefore it is disabled for editing for user “Jungle”. Anyway, after saving this edit and viewing the sidebar of the image page, we now see this:

Cool. Image data enriched by another user. Jungle (who made the edit) hits the “view history” button to see his change being recorded:

This will present the image history screen:

Perhaps a bit hard to see, but this screen is layed out as follow. On the right is the live image data, the current version that is public. On the left you see a list of image versions, sorted by newest first. We see that there are two versions, the first one being uploaded by “fchristant”, and the edit made by “jungle”. We can even see exactly what was changed (which field) and which version is the live version.

Hopefully, in most scenarios this would be the end of it.  The change is considered an improvement and all is good. However, let’s finish our story. In this case, the original image owner, “fchristant”, does not like the edit made by Jungle. So we’re logging back in as “fchristant” and have a look at the image history screen once more. Here it is, zoomed in on the inital version entry in the list of versions:

Notice how there is now a button called “Restore this version”. It is only visible for the owner of the image. Let’s click it:

The image owner confirms the restore and the original version of the image data is rolled back. When we now look again at the sidebar of the image, we see this:

Now, let’s have a final look at the image history screen:

We can now see that the enrichements made by user “Jungle” are undone. We also see on top of the version list that the restore was made by user “fchristant”, the image owner. This completes our scenario.

Why is this so cool?

Only after actually implementing this feature, I realized its tremendous power. First, I thought it was a nice safety net against unwanted edits, a way to make the community aspect of JungleDragon more robust. Then came the realization that this feature brings much more to the table. This feature means that JungleDragon supports all of the following models:

• No image edits allowed by other users at all (restricted model)
• Image edits allowed by priviliged users only (karma model)
• Image edits allowed by all users (Wiki model)

I can support any of the above models by simply setting a few flags in the configuration. In other words:

JungleDragon just became an image Wiki and with the touch of a button, I can control the “Wiki-ness”.

How cool is that?

Finally, thank you Joe for making the suggestion!