I’m super-excited about catching up and going out with everyone, and then getting together and doing some really awesome things to MediaWiki by day. I know from my experiences in Buenos Aires last August and in Paris last November that when you get a bunch of developers in the same place at the same time, you can get all sorts of amazing things done.

I’m hoping that I’ll be able to spend 15–20 minutes showing off LiquidThreads to a wider developer audience, and getting some feedback. It’s also going to be great to see how Chad’s new installer, and Ævar’s mapping stuff is going (to name two projects off the top of my head). We’re also going to talk about some new stuff, like metadata handling, better support for dumps and subscriptions, OpenID/OAuth implementation, and much more.

I’ll also be glad that we’ll be able to talk about some of the boring (but really important) issues facing MediaWiki development, like bug tracking, code maintenance, code review, unit testing and patch submission. It’s always great to get these issues sorted through, and the best way is to lock everybody in a room until we sort it out.

It’s going to be awesome!

With the Foundation’s support, I’ve spent the last few months churning away at LiquidThreads, a new discussion system that is proposed for use on Wikimedia projects.

Essentially, it’s an attempt to marry the radical openness of the wiki paradigm with the usability and practicality of a forum-like system. As the name implies, LiquidThreads is designed to allow any user to easily refactor discussions while maintaining edit history, to edit other users’ comments, and to collaborate on a summary of an ongoing discussion. LiquidThreads also brings many standard communication features lacking from wiki discussion pages, such as watching and protecting individual discussion threads, RSS feeds of comments in a discussion or on a discussion page. In the world of online communication, its approach is entirely unique.

LiquidThreads has been in alpha testing on Wikimedia Labs for several months, and, more recently, it’s been used in a production context on the strategy wiki, where it has been quite well-received. It’s been easy to run these smaller trials, as the extension allows the activation and deactivation of LiquidThreads discussions on individual pages with a simple parser function.

While there are still some issues remaining before wider trials, I believe I can resolve most of them quite quickly (within a few weeks when my vacation finishes at the end of next month), and I’d like to get the ball rolling in proposing small-scale trials on some of the larger wikis, so that a full discussion can be had, and so that adjustments can be made on the basis of ongoing feedback. I’d especially like to see LiquidThreads used on some of the higher-traffic discussion pages on English Wikipedia (such as the technical village pump), and progressive rollout on some of our mid to large sized wikis.

So, I’d like to encourage you to have a play with LiquidThreads, either on the strategy wiki or on the test site (which generally runs a newer version). Tell me what you like about it, and (far more importantly) what improvements you think it needs before we can expand our trials to wider parts of the Wikimedia Universe, and perhaps move towards a full rollout of this very exciting technology.

I should give the following caveats about LiquidThreads as it stands. These are all issues that I intend to address before any trial expansion occurs.

• Presently the system is somewhat vulnerable to abuse. I intend to make changes to the way signatures work, and improve tracking and listing of thread actions by specific users.

• While LiquidThreads allows for thread summaries and discussion headers, the system does not currently have support for collaboratively-edited posts which are unsigned or signed by a group of people. These are a key piece of any decision-making framework, and I intend to make adjustments to make this possible.
• There is no support for embedding LiquidThreads discussion pages on other pages.
• There are plenty of minor interface issues which I intend to clean up.

Feedback is best directed to the dedicated feedback page, or, alternatively, to bugzilla (although before filing a bug, you should check the list of existing LiquidThreads bugs).

Thanks,

Andrew Garrett

I’ve just finished up a week in Beautiful Buenos Aires, Argentina, where Wikimedia held its annual conference, Wikimania. I think the best way to describe it is “Crazy fun”.

Highlights (the sessions)

• Richard Stallman (enough said).
• Finding out some of the stuff Kate and Ævar have been doing on OSM.
• Chatting to Christian about DBpedia, an awesome semantic database produced from the Wikipedia data.
• Finding people unaware of my work on LiquidThreads who have been doing prototyping of their own on discussion improvements.
• Some of the fancy new stuff in the works, as summarised by Brion.
• The awesome work Michael Dale’s been doing on open video at Wikimedia.
• Finding out about the plans the usability folks have for MediaWiki.

Highlights (outside the conference itself)

• The taxi ride from the airport, which was conducted by a driver who (like most drivers here) did not understand the concept of a lane, and found 140 km/h to be a perfectly appropriate speed.
• The Mauseleum at Recoleta, and its colony of feral cats.
• Dancing the Tango with Florence (who described my dancing as “not super elegant”).
• Finishing the closing evening with pizza at 6 am, accompanied by Phoebe, Kat, Mako and others.
• The feeling of inadequacy that comes from being surrounded by people who speak at least 4 languages.
• Deciding with half an hour’s notice to visit Colonia (in Uruguay) with Betsy, Kate and Ævar.
• When out with Ævar, making liberal use of body language to explain the concept of a nightclub to a bemused taxi driver.

Comments about the conference (directed mostly at the organisers)

• The communal areas were great. It was especially good to hang out in our techie basement, although we were a bit separated from everybody else.
• It sucked that the staff hotel was so far from everybody else and was much nicer. It felt hierarchical, which is not how Wikimedia is supposed to work.
• The organisers did a good job of trying to stem the flow of stolen stuff.
• The party was a lot of fun, and very well-organised.
• The hotel was a pretty good choice, the lack of wifi in the rooms was a mixed blessing, drawing everybody out into the lobby to hang out.
• The internet in various parts was a bit flaky, which is a bit weird for a tech conference

See you all in Gdansk next year! And in Sydney the year after!

Here’s an overview of the new interface

Overview of the new LiquidThreads interface

The new interface relies on paging, rather than archiving. Instead of artificially removing a discussion from a talk page when it’s done, the discussion page is paged. Only ten discussions will be shown at a time, and anything beyond that can be accessed simply by hitting ‘Next’. Old discussions will naturally fall ‘off the bottom’ of the discussion page, as they do in forums, comment threads, and most other discussion systems in the world.

I’ve also redesigned the thread display. Instead of having a footer with the pertinent information, and using indentation to show threading, I’ve put the information at the top of an enclosing box, which includes all of the replies. It makes it much easier to see who’s replied to what, and when. It’s also much more consistent with other systems of threaded discussion.

Finally, I’ve streamlined the interface for ‘actions’ you can take with a post, like editing it, watching it for replies, checking its history, or deleting it if you’re an administrator. By putting these into a drop-down, the actions are within easy reach, but stay out of your way if you just want to read the posts.

Over the next few weeks, I’m going to be working on making the comment workflow AJAXy, making all comments searchable, and other miscellanea.

What do you think of the new interface? How can it be improved? Let me know in the comments.

This kind of sucks. Really, we should be working on a system where discussion is managed like every other discussion on the internet since discussions have been done with web interfaces. We need threads and posts, we need replies and quotes, and we need automatic signatures, automatic archiving and paging, and all that jazz.

So my current assignment from Wikimedia is cleaning up an awesome extension for discussion threading called ‘LiquidThreads‘ with a view for deploying it on Wikimedia projects. Originally written by David McCabe, it gives us the regular forum-like interface, with a distinctively ‘wiki’ approach to discussion. I’ve put together a test setup, which I frequently update to the latest bleeding-edge version, for testing the latest and greatest improvements to the extension. Please try it out and give feedback!

Overview of the LiquidThreads interface

It differs from ordinary forum discussions in a number of significant and important ways:

• All posts are editable by anyone. To avoid abuse and confusion, we have “edited by author” and “edited by others” flags, to clearly show whose words are whose. And like any good wiki, each post has its own history page, so unwanted edits can be reverted.
• Once a thread has finished, wiki users collaborate on a “summary” of that thread, which explains what was discussed, what each side had to say, and what the result was. Once this summary is written, the thread is archived.
  

  The LiquidThreads system can require a summary be entered for each thread prior to archiving

• Users can freely move threads from page to page without losing the associated history of the threads. While this would be restricted to ‘moderators’ in a traditional forum, there’s no reason not to make it easy for any user to move threads from page to page in a wiki environment.

Some of the advantages this has over regular ‘wiki-style’ discussion are:

• Archival is handled by the software. No clumsy bot implementations required.
• The enforced summarising will help with keeping track of all the discussions that have been had, and in managing the huge archive systems we use at the moment.
• The history of discussions will be far more manageable, being separated out into a different history page for each post and thread.
• Moving threads from page to page will be painless, and will move the full history of each thread along with it.
• It’s much prettier, and much easier to use than our existing system.
  

  The LiquidThreads interface clearly shows which posts are in reply to which

• There’s much more scope for quoted, point-by-point replies (and this is part of my future direction for this extension).
• You can watch individual threads, which may give you email notifications for replies on pages or threads you care about. You can even just receive notification for replies to your posts.

Of course, the extension is still not quite there. Here are some future directions I’m hoping to take with LiquidThreads (subject, of course, to what the Foundation’s plans are for LiquidThreads):

• Adding some sort of capacity for quoted, point by point replies to other posts. These are a critical feature of any sensible structured discussion, keeping people on-track. It’s a shame we’ve waited so long to see them on Wikimedia.
• Allowing limited customisation of the signatures shown in the footer for each post, much as signatures are presently customisable in MediaWiki.
• General bugfixes, UI cleanliness, and other cleanup necessary for a full deployment on Wikimedia sites.

What do you think of the new discussion system? Have you tried it?
Let me know in the comments!

At this party, I stayed with Daniel Kinzler (Duesentrieb) of Toolserver and Wikimedia DE fame. Daniel and I had lengthy conversations about plans for implementing some sort of system for bringing Wikimedia to the semantic web.

Here are some of the things we talked about:

• The “identity crisis” of semantic data. When we add an “author” tag to a page about a book, are we talking about the article itself, or are we talking about the subject of the article. For example, should the tag on http://en.wikipedia.org/wiki/Mein_Kampf be “Wikimedia Community”, or should it be “Adolf Hitler”? While an interesting challenge, Daniel and I figured that all that needs to happen is that this needs to be well-defined, and then it is dealt with.
• The need for integration with existing article wikitext. It is no good to implement a brand new system that requires automatic (or even manual) conversion of millions of existing articles. A good way to do this would be to modify the underlying infobox templates, so that they participate in the experiment.
• The need to balance flexibility with performance in the query infrastructure.
• The storage location for semantic data. We pretty much agreed that the canonical version should be stored in the wikitext itself for versioning purposes, and that a searchable, normalised store of the current version of the data should be stored elsewhere in the database (or in a different database), much as category, page and template links are stored.
• The relationship between infobox usability and the entry of semantic data. I’ll discuss this below.

So I do have a sort of an idea as to how we could implement this really well. Like most good suggestions, it is integrated with the infobox infrastructure. I think this is necessary, because unless the data is user-visible, it will not be maintained very much. Infoboxes make the information user-visible in a very obvious and simple way, and coupled with a client-side infobox editor, it could become very easy and rewarding to edit and maintain semantic data. Infoboxes also tie in neatly with the Wikipedia Usability Initiative. The usability initiative plans (as far as I am aware) to clean up the interface for editing infoboxes, so that it doesn’t involve dealing with horrible template syntax.

So here’s my crazy idea for killing both birds with one stone:

Step 1: Create an Infobox generator/editor

This would involve:

1. Defining the different “templates” (i.e. “person”, “US Government Agency”, “1980s singer’s dog” (Daniel’s suggestion) ). Each template would include the fields expected for that kind of subject, and what data types they were.
2. Selecting the template to use when creating each article. This could be done with a nice AJAX-y search interface. In turn, you are given a simple interface for entering the data. Adding the data type gives lots of niceties, for example if the data type is a page or image name, you get pretty AJAX search and preview. Daniel noted that we’d need an extra field for auxilliary commentary and sources on this data, population being the classic example (what is the data’s currency and source?).
3. Somehow exporting this data to wikitext. This could be done as a template, or (my preferred solution) a parser function or tag extension. I’ll discuss this in the next section.

Step 2: Generate infoboxes from semantic data at a software level

The templates we currently use for infoboxes are terrible hacks produced because nobody stepped up and provided a better way of generating them. My proposal is to replace infobox templates with wrappers around a tag and/or parser-function-based solution.

This makes things much cooler. The semantic data would all be stored in a normalised way in the database (generated from the wikitext), and the infoboxes would be just one front-end interface to this data (albeit the most used and user-friendly). Another interface could be an RDF (or similar machine-readable format) output format.

Step 3: Store normalised data in the database for queries

I’ve touched on this before, but not addressed it rigorously. A huge part of the utility of storing semantic data in the database is that you can emulate many of the ad-hoc, manually maintained categories with very simple normalised storage and retrieval of the semantic data.

So, the most sensible storage system seems to be the tried and tested semantic triplet – subject, relation, object. The subject is, of course, the article (for storage purposes, this isn’t related to the “identity crisis” issue discussed above). That leaves the relation and object as the metadata key and value respectively.

The raison d’être of this storage is the query interface. I won’t dwell on it, because it’s not a particularly original idea.

Advantages

The main advantages of this system are practical. There isn’t that much extra software to be implemented, except the infobox editor. The infobox editor, of course, is planned to be implemented by the Usability Initiative anyway! What remains isn’t too difficult to throw together in a few weeks, and could very quickly change the nature of Wikipedia’s reuse.

Please give me your thoughts on these musings and this proposal!

Since it’s mostly done, I’ve activated a test setup of it over at my test wiki. Improvements include about ten bug fixes, see the tracking bug for full details (click on the links under “Blocks:”)

So if there’s anything you’ve ever wanted in the Wikipedia preferences system, but were afraid to ask for, now is the time to let me know!