For my bachelor’s thesis at the University of Groningen I investigated ways of improving this experience of editing Wikipedia. Why doesn’t it already use a visual editor such as Google Docs? This has everything to do with wikitext, this language you see when editing a page. Wikitext is the language in which pages on several wikis, including Wikipedia, are stored and edited. Once you save a page, this wikitext gets translated into HTML, the language used by web browsers to show a page.

Wikipedia was founded in 2001, just after the internet bubble, but before people were speaking of a Web 2.0. Back then it made sense to use such a language as wikitext. Microsoft Word already existed, but an online variant simply wasn’t there yet. The techniques and standards for such an interface on the web were not developed yet, and only some early experimental designs were being tested. It was possible to use simple text boxes in web browsers, though, so initially this was used to edit pages. To be able to apply some markup to pages, some codes were introduced, such as '''bold''', ''italic”, [[link]], and == heading ==. These codes were translated into HTML by means of substitution: first occurrences of ''' were replaced by <b> and </b>, the HTML tags denoting bold tags. Similarly the other codes were replaced by their harder to read HTML equivalents.

Because Wikipedia was growing rapidly, it became necessary to extend this list of codes to make common tasks easier, such as maintaining lists of references, including info boxes placed at the top right of pages, and so on. These additions were essential to Wikipedia’s volunteers, but at the same time the wikitext language became ever more convoluted.

Now, however, people are expecting something better than a huge text box. To make it easier for potential volunteers to contribute, it is necessary to offer an interface that is widely known, such as a visual editor. On the other hand, it isn’t desirable to get rid of wikitext completely, as this would alienate tens of thousands currently active contributors, who are used to this language. A better solution would be to still store the pages in wikitext, but to offer both ways of editing: visual editor for new users, and traditional wikitext editing for existing users.

However, building a visual editor on top of wikitext is easier said than done. This is because of the way wikitext is transformed to HTML, with a number of subsequent substitutions. A common way of building a visual editor on top of a language, is by using an intermediate representation of the text, called a document tree or syntax tree. Such a tree represents the page in a hierarchical way. A page contains paragraphs, paragraphs contain sentences, and sentences contain pieces of text, links, media, and so on. Alas, wikitext can’t be described by such a hierarchical model, because these substitutions make sure there is no such thing as wrong wikitext. There are even substitutions that fix common mistakes, such as '''bold [[link''']]. This is equivalent to '''bold [[link]]''', which has a defined hierarchy: the link is inside the bold text. In the former example, this hierarchy is not present: the bold text ends before the link element is closed.

While this is a silly example, there are more complex cases, which are widely used in Wikipedia. There are people working on a intermediate representation that does allow for these kinds of cases, but as this is quite difficult it may take a while.

For my thesis I investigated if it’s perhaps possible to build a different kind of interface instead of a visual editor, which is both easy to use and easier to implement on top of wikitext. Eventually I arrived at a compromise: users get to see the same page when editing as when viewing, but they can’t edit it directly. Instead, there are some explicitly marked elements on the page that are editable, such as sentences, paragraphs, lists, info boxes, etc. Such editable elements are marked by either a light blue background colour, or in case of larger elements such as paragraphs, by a bar at the left of the element. When a user moves the mouse over such an element, it lights up in a darker colour, indicating it can be clicked.

Once clicked, a popup appears with the original wikitext for that element. Once the user has edited the wikitext and confirmed the change, the popup disappears and the page is updated with the new content.

Now, the user still has to edit wikitext, but in much smaller quantities. The idea is that there are not so many complex codes inside a single sentence or even paragraph, which makes it a lot less scary for potential volunteers to play around with a page. Also, the direct feedback when editing a small piece of wikitext may help in this, as it immediately clear what effect the changed wikitext has on the page.

The big advantage is that it’s not required to use an intermediate representation when generating such an interface. It’s only necessary to know for the editable elements to which parts of the original wikitext they correspond. For example, if it is known for a certain paragraph in the HTML output to which exact lines in the wikitext it corresponds, then we can show this wikitext when clicking the paragraph on the HTML page, and replace it when the user changes this wikitext.

To get the correspondence between wikitext and HTML I use a trick: annotation. Before the wikitext is transformed to HTML, I add some codes to it to mark some positions. These codes are chosen in such a way that they are not transformed into anything else, and they are also all unique. They are placed around basic elements, such as paragraphs, sentences, in fact everything we want to make editable and is easy to recognise. For every added code, we also record the exact position of the code inside the original wikitext. After this, the annotated wikitext is transformed into HTML, and the codes survive this transformation. Finally, the codes themselves are transformed again to make a valid HTML page (see Example 1). This way, every editable element gets a unique identifier based on the code it belongs to, so now it is possible to look up positions in the original wikitext whenever an such an element is clicked.

This doesn’t directly solve the problem of hierarchy, as HTML itself expects a strict hierarchy on elements. In the transformation this is fixed for the wikitext, but not for the added codes. This means that the example from above is still invalid:

<sentence-0>
<bold-0>'''bold <link-0>[[link'''</bold-0>]]</link-0>
</sentence-0>


After all, link-0 has to be closed before bold-0 is closed. This time, however, there is a remarkable simple solution: we can just remove all the conflicting codes! If it’s not possible to edit a single link in some cases, this doesn’t really matter, as it can still be changed by editing the entire sentence:


<sentence-0>
'''bold [[link''']]
</sentence-0>


There is always an element at a higher level that doesn’t conflict with any other element. In the worst case this means the highest element — the entire page — has to be edited, as that can never conflict with anything else. This is rare, however, and in most cases editing a single sentence or paragraph suffices. Such a fallback mechanism for weirder cases of wikitext does not exist for a visual editor.

You may wonder whether or not such an interface in which the user still has to edit wikitext — be it a bit less — is any improvement at all. To test this, I’ve worked together with GRNET, a Greek research institute, to test this hypothesis. They tested my final interface with “real” users, to see whether it works or not. The results were mostly positive, users found it quite easy to do most basic operations. Complex tasks were still difficult for most users, especially because users tried to do things they were used to do with visual editors, such as dragging and dropping of elements. While this is a downside of such a new editing paradigm, it was great to see how most tasks became a lot easier.

Despite these positive results you won’t see this interface on Wikipedia anytime soon, as it’s not finished. In my thesis I describe all the algorithms and other ideas for finishing the interface, but as the Wikmedia Foundation recently started working on a true visual editor, I decided to put this project on hold for now. On the other hand, an editor like this has other advantages, such as being easier to use than one big text box for power users who don’t want to use a visual editor, or for newcomers who’d like to slowly learn to do more complex tasks. So who knows, perhaps one day you can use my interface to edit Wikipedia!

• Adapted from “Help, ik wil Wikipedia veranderen“, FMF Periodiek, #3 2011.
• Based on the bachelor’s thesis “In-line Editing: a New Approach to Editing Wikis“, Jan Paul Posma, University of Groningen, 2011.
• Implemented in the MediaWiki extension InlineEditor.

Let’s get into details! The system is running on Aleutia T1, which is a really nice, silent PC-ish thing. PC-ish, because the performance is not really up to todays standards, but on the other hand it’s quite cheap, really silent and comes pre-installed with Ubuntu. Cool! (However, I installed Windows XP…) I got mine with a SSD, which means that there are no moving parts whatsoever, therefore it can stay on 24/7.

Using a simple XAMPP setup, it runs my photoframed software mentioned in the previous post (demo, source).

The webcam setup is quite interesting. First I tried to plug the webcams using some USB extension cords. It was highly unstable, so now the PC is actually positioned in a cardboard box, lifted from the ground, so all the cables fit exactly.

Another issue with the webcams is having it stream, but also have it stream securely. A promising format seemed to be MJPEG: this is just like sending out JPEG frames as fast as the connection can manage. I run the following code to generate a MJPEG stream using VLC. The stream is only accessible from localhost for security reasons.


vlc.exe dshow:// :dshow-vdev="USB Video Device" :dshow-adev=none :dshow-size=640x480 --no-sout-audio --sout=#transcode{vcodec=mjpg, vb=512, fps=1, width=640, height=480}:standard{access=http{mime="multipart/x-mixed-replace; boundary=7b3cc56e5f51db803f790dad720ed50a"}, mux=mpjpeg, dst=127.0.0.1:8080/cam.mjpg}


The boundary thing is a code required for modern browsers to correctly recognize the data type. If you remove the IP-address at the end, you’ll allow anyone to watch the stream. Now the next proxy is to make sure only authenticated people are able to see the stream. I tried this using a PHP script which simply read the stream and echo’ed it (and some other variants). I also tried using the Apache proxy module. But both options have the same problem: as I have a terrible internet connection, I really need the last frame. Once a frame is transmitted, the new frame must be the most recent frame possible. However, all options I tried seem to cache the data, so you’ll see 1 second of recording spread out on, like, half a minute on the client.

In the end I just went with a simple script I found online somewhere, that reads exactly one MJPEG frame and spits it out as ordinary JPEG:


$boundary="\n--";

fclose($f);


Now you have to refresh the image using for example Javascript, so that’s fine too. The webinterface I’ve written for this purpose also features a slider to set refresh interval, which is pretty handy if you’ve got a shitty connection like myself. Also, this brings me to the home automation part, which is actually pretty brief. All devices in my room are plugged into a KlikAanKlikUit unit, and the PC’s got a TPC-200 interface plugged in, and a little bit of software does the trick (demo, source).

The TPC-200 interface comes with a DLL which has one single command: Send(id, value), with id being an integer and value a boolean. A simple executable wrapper, hacked together in VB, makes it easy to send commands from PHP, using exec.

The first room control breach has happened already: I used the inferior Apache Basic Authentication for the login procedure, and it turns out that sessions can keep open for a long period of time. Even when the server restarts during that time. I logged on the system on the laptop of a friend of mine, and 3 days later, he scared the crap out of me by playing with my lights. ;-) The PC restarts every night at 5am, so I’m still amazed that the session lasted that long.

Anyway, I quickly tracked him down using the access logs and we had a good laugh about it, but I still don’t trust the security anymore: the inside camera is pointed at the ceiling now… SSL and stuff like that will probably be secure enough, but if you’re considering building the same setup, don’t plug in your nuclear power plant.

Most of the original source code is lost, and the system doesn’t work well anymore, so I’m redesigning it. In a few months you can expect another blog post on this, but I thought a writeup of the old design would be nice.

It started with an old laptop. In an impulse I decided to see how quickly I was able to strip it until only the bare essentials were left. It was quite easy to disassemble it, and the wires were long enough to separate the display from the other components.

Once the laptop was disassembled, it was easy enough to go to the DIY store and buy some materials. With some careful measuring, patience and painting twice, the job was done in a few evenings.

To display the photos, a clock, and some RSS feeds, I used a PHP script by Tommy van der Vorst, running in a fullscreen Firefox window. It worked pretty well. After some modifications, it was used by myself and others for 3 years.

A few months later I stumbled upon this post on a forum, which describes how to easily hack a cheap home automation remote control to hook it up to a computer. There were sets available for about €20 to control lights and devices with a remote control. So I bought two of these sets. The first hack was to hook it up to ordinary lights that are directly connected to a power source, without a wall socket in between. The setup wasn’t very safe, but it worked.

Next, I followed the instructions on the forum post: hook up the remote control to the serial port, detect commands using LIRC, and send them back to the remote control. It worked fine on the computer, but the problem is that on laptops the serial port is weaker: it usually won’t give a nice and strong 12 volt signal.

The solution was rather simple: by hooking up transistors to every button, you can simulate a press of that button simply by putting a small voltage on the transistor. The easiest way to do this is by using the parallel port. Fortunately, the laptop was pretty old so this was no problem.

With some Visual Basic programming, the Microsoft Speech API and some PHP scripts it was possible to control the lights by voice and over the internet. Which is pretty cool. Unfortunately, I lost most of the source code, so I won’t be able to share it here. Right now I’m building a new version, and when it’s done I’ll share the code!

For now, I’ve started improving the PHP script that shows the photos, which I’ve dubbed photoframed. It’s pretty nice already, you can download and contribute to it on my github page. It even works perfectly fine in an iframe like the one below.

In a few months the new system should be up and running, so I’ll probably write another blog post then. Meanwhile, I invite everyone to look at the source code of photoframed and contribute. Or you can just leave a message in the form below. ;-)

They even upload your photos to Flickr, Picasa, Facebook, etc., and put your video on Youtube and other video services. They also send notifications on Twitter, and other microblogging sites, and even on social network sites and other blogs. They have an extended list of all the sites they support auto-posting to.

They also support custom domain names, Google Analytics, Feedburner, a bookmarklet and a nice Share on Posterous button. It’s simply amazing.

However, the limitations of Posterous quickly became obvious to me. No options whatsoever to customize the design and the media options are pretty limited.

An example: for my next blog post I want to be able to embed multiple small galleries on different places in the post, as it’s quite a long read. There are no upload facilities on the site, so I just e-mailed all the photos using multiple e-mails for the different galleries. Now I copied the gallery code from the different posts that were generated to the ‘main’ post. It looks something like this:

[[posterous-content:XfwIQTnahWsSQOSZUGMi]]

Thinking that the photo access would be limited to the user account, I thought it was a nice way to add multiple galleries to one post. Wrong: the access to photos is limited to the same post. Still, why use such a complex code with a hash; if the photos are limited to the post, why not use something like:

[[ gallery ]]

Maybe it’s an upcoming feature, maybe it already exists but hidden somewhere (like those crazy tag options in the subject field)..

Anyroad, WordPress works excellent, it’s a really sound system, and very easy to setup. I’m also quite happy with this minimalistic theme.

In conclusion, Posterous is a fine system for people who ..

1. .. don’t understand much of blogging and just want to type some nice stories, optionally with pictures. Useful for the average non-tech person who barely understands e-mail.
2. .. want to be able to write a nice photo- or videoblog, very easy to add photos from vacation or a mobile device, just by mailing them. Your various social accounts will be updated too, very nice.
3. .. don’t have the time updating the status of all their 10+ social, microblogging and blog accounts and want one nice interface to add things to all of them. Finding out what went wrong with their lives would be a great idea for these people as well.

What do you think? What is your favorite blogging site or system? Do you have suggestions for this blog?