Open Spaces

Scuttle Bookmarks is another extension to MediaWiki software and provides a key piece of functionality to achieve a single, integrated content repository. It is a twin extension to OMBookmarks, which I have released a couple of weeks earlier. While OM Bookmarks is focused on retrieving and displaying bookmarks from the Open Methodology Bookmarks website (which is part of the MIKE2.0 collaborative environment) in your MediaWiki installation, Scuttle Bookmarks allows you to do the same but from a local installation of Scuttle.

The two extensions also follow two different architectural design patterns. The Scuttle Bookmarks extension is designed to be installed in the same domain (or server) which is hosting both your MediaWiki site and your Scuttle site. The extension uses client side JavaScript calls to query the Scuttle site for relevant bookmarks and then displays the result on the MediaWiki article page.

The OM Bookmarks extension will always be installed in domain different from the Openmethodology.org website which is hosting OM Bookmarks. If it were to follow the same architecture as Scuttle Bookmarks, a user would access his MediaWiki site (e.g. www.mycollaborationsite.com), which would provide a JavaScript that retrieves information from a third party (i.e.openmethodology.org). Sounds like malicious code, doesn’t it? This is called cross-domain scripting and is blocked by default by most modern browsers. Therefore, this extension was implemented with a server side http call which performs all the magic. And the user only sees the final result.

You might ask yourself now why all the fuss about JavaScript when the server side http call could be used for both extensions? Well, the simple answer is that part of us creating and improving the MIKE2.0 collaboration site, is to develop an open source software based solution to deliver enterprise 2.0 collaboration to customers. And JavaScript http and PHP http are just two more guns we now have in our toolkit that we can offer clients.

2 projects, 20 flights and 4 cities later here I am back at the keyboard. Work has been a little crazy over the last couple months. This doesn’t mean, that I haven’t been working on cool stuff for MIKE2.0 with MediaWiki. It’s just that I haven’t had any time yet to tell you guys about it! Over the next couple of weeks I will make time to release some of my work to the open source community again.

One vision with building a standard around MIKE2.0, the open source Information Management standard, is to enable us (BearingPoint) but also the community to hook into the open source standard. Nowadays you would probably call this a “standard mashup”. For MIKE2.0 we termed it “Integrated Content Repository“. Last year, we did about 1,600 projects in Information Management and we are trying hard, to link all of our assets (templates, tools, standards etc.) into the MIKE2.0 standard to prove to ourselves and also to our customers that we can deliver complex IM projects, across many topical areas under one common standard. And that common standard shall be maintained and extended by on open source community. In order for that community to benefit from the standard the same way we do, we need to provide a framework and the tools to link their internal and private efforts into the open standard.

The API Query Extension allows users to query the API of another Mediawiki. In version 1, we focus on retrieving all articles that are part of a certain category and displaying this list within another wiki page. The below screenshot shows how we can include a simple box with a blogroll view of articles within a wiki page. This allows us publish and edit internal, private content on our internal wiki, but at the same time make the user aware that there is open source content (solutions, standards, best practices etc.) available as well.

The parameters of the extension allow you to specify the type of query and to restrict the query with search terms. The Mediawiki API is still in its infancy, but already provides some great opportunities for integrating multiple wikis based on loose coupling (web services or http queries). As the Mediawiki API will grow in functionality, so I hope that the community will help to build out the API Query Extension to provide better and greater results.

The new API Query Extension is the first mosaic stone in the set of tools we need to make this integrated content repository work. More will follow in the near future…hold tight!

Due to popular demand I have split out the category suggestion feature from the SelectCategoryTagCloud extension and created the CategorySuggest extension. This extension fills a major gap in the extension list of Mediawiki. By default users have to add categories by adding wikitext to the article (e.g. if you want to add the category “Information Development” to a page, you need to add [[Category:Information Development]] somewhere on the article page). This clearly has some disadvantages including

• lower usage of categories because users don’t know the syntax
• duplication of similar sounding categories because users don’t know that a category already exists

CategorySuggest provides a Google Suggest like functionality to the edit page of articles. A separate “Categories” input box is added below the article page. When a user starts typing the name of an existing category, the extension retrieves a list of existing categories from the Mediawiki database and suggests matches to the user. The user can either type the name of a new extension or pick from the list of suggested categories. Here is a screenshot of the user inteface:

This is version 1.0 and there are still a lot of features and enhancements that can be added. We hope that by providing this initial release we can encourage other users of Mediawiki to test, use but also to help with the further development of the extension. The extension homepage includes a list of TODO’s which would mean a great enhancement to the base functionality.

It’s here, finally! A Mediawiki extension that combines a tag cloud and Google Suggest like features to categories. It’s called SelectCategoryTagCloud and version 1.0 is available on http://www.mediawiki.org/wiki/Extension:SelectCategoryTagCloud.

Let me explain how and why we did this. A couple of weeks ago Jeremy wrote about how taxonomies and folksonomies are complimentary. In a simplified view of Mediawiki and Enterprise 2.0, categories are as close to a taxonomy as you can get. You can pre-define categories, nest them to create a hierarchy or automatically include them in templates that you force on certain pages (and therefore the page itself becomes a member of the category). However, categories also allow users to create horizontal or lateral views on content that is otherwise stored in a hierarchical or sequential manner. In wikis you create a link from a top page or home page to a sub page to a sub page and so on. You can then link from one sub page to another one, but if you want to see what pages deal with the same topic, you have to navigate through them one by one (either hierarchically or in sequence). Categories allow you to group pages that share a common topic into categories by simply ‘tagging’ the page with a category name. Here is a screenshot of an article with 4 categories applied to it:

If you want to see all pages in that category, you just need to click on the category name and Mediawiki displays all pages that are part of the category. The following screenshot show all pages in the category MIKE2 Activities:

A couple of extensions to Mediawiki exist that have attempted to solve the problem of suggesting categories to users, visualising what categories are popular and applying the style of Web 2.0 applications to categories. But none of them have achieved to provide the usability and simplicity of applying tags to bookmarks as Deli.cio.us and Digg have done.

My first step was to review existing extensions to see how much code reuse is possible. As a professor of mine at university used to tell me, copying code gets you expelled from school, but awards in the corporate world . I found two extensions that were particularly useful (SelectCategory and WikiCategoryTagCloud). Credits to the developers of these extensions, because their code was to become the basis of my new extension which I named ‘SelectCategoryTagCloud’ in their honor.

The first step was to refactor the Wiki Tag cloud to be displayed on the edit page (and then further on the upload file page) of a Mediawiki article. Users are now able to see what categories are popular on the site and what categories are already assigned to the article. Take note of the simple visual marki-up of the existing categories.

The second step was to extend the functionality by adding an input box that would list all categories that are already assigned to the article. So instead of having to type the category command [[Category:CategoryName]] into the regular edit field or having to hunt down where the original user had put the command, users now have one single place where all categories are managed. Users can click on any of the categories in the tag cloud which adds it to the list of categories. Clicking on a category that already exists in the list removes it.

Finally, I needed to solve the problem that a tag cloud can only display so many categories as feasible to show on screen. Wikipedia has something like 150,000 categories, can you imagine how their category tag cloud would look like?! In my extension the number of displayed categories can be limited by setting a minimum count number for articles that are part of the category.

But how about all the other categories that don’t fit into the tag cloud but which we still want to encourage the users to reuse?!! So I added a category suggestion feature, similar to Google Suggest. When the user starts typing the initial characters of existing categories, the extension will display suggestions of existing categories right below the category input box. This not only encourages reuse of existing categories, but also reduces the amount of categories with similar names and typos. Check out this screenshot to see suggestions on the initial characters ‘Bu’:

The user is presented with 3 suggestions (Business Activity Monitoring, Business Intelligence Offering Group, Business Solution Offerings) and can select any of them with a simple mouse click. And because it’s all AJAX based, the lookup and suggest feature is kicked off in the background and doesn’t interfere with the user’s typing.

So what’s the next steps? Well, this is a first stab at applying some of the Web 2.0 features like tag clouds and suggestion to Wikis. Next I would like to apply a more formal approach to social bookmarks to complete the circle of taxonomies and folksonomies. Specifically, I will work on how to apply categories created in Mediawiki to Scuttle, an open source bookmarking software. This great software hasn’t really received any development support over the last year or so, but we have been using it internally and we believe that this will be another piece in our work to glue Web 2.0 technologies together to provide a solid, open source Enterprise 2.0 offering for collaboration.