With 2009 underway, Brion Vibber and the rest of the great staff developers of MediaWiki at the Wikimedia Foundation have put their noses to the grindstone once again, rolling out one minor but distinctive feature on Wikipedia and testing another very significant one.

It’s the little things that make a difference

The first is the addition of friendlyclock. Once only a part of Friendly, an optional collection of JavaScripts that many Wikipedians use to automate common editing tasks, friendlyclock is a simple feature that adds an updating UTC clock in the top right-hand corner of the screen next to the usual links for logged in editors. Clicking it also acts as a purge of your page cache.

on the far right

on the far right

Friendlyclock may not sound so exciting, but once you spend even an hour or two editing, you’ll come to appreciate having both of those features handy. In fact, I’ve had a JS gadget enabled that does the exact same thing for months now. It’s just this kind of incremental but gratifying change to the software that shows how sensitive Brion and the Wikimedia Foundation has been to the needs of the core community over the years.

Important new functionality.

The second MediaWiki addition is a full extension that Brion announced Friday. Currently in beta on test.wikipedia.org, the aptly named Drafts extension is a serious advance in MediaWiki and wiki software in general.

It doesn't get much easier than this.

It doesn't get much easier than this.

At least once, everyone has written an extensive draft only to see it disappear when human error, a browser crash or saving problems cause you lose all your hard work. In fact, several months ago I saw this exact experience happen to wiki inventor Ward Cunningham when using a MediaWiki installation.

Needless to say, an inability to save drafts in a wiki without a live version being saved as well has been frustrating at times. A lot of other great platforms (such as WordPress) have drafts capability built in already. But as far as I know, there is no wiki engine with native drafts functionality.

From some test edits to the Sandbox I made, I can tell that drafts is a delightfully AJAXy addition to the ecosystem of MediaWiki extensions. Drafts can be saved via an easily accessible button and are saved every 120 seconds regardless. Not only can you save and view drafts from a particular page, but you get a special list of all your drafts.

I found the interface for viewing saved drafts extremely intuitive.

I found the interface for viewing saved drafts extremely intuitive.

When it comes to wiki software, and MediaWiki in particular, I tend to be something of a stick in the mud. I’m used to MediaWiki and I like it just fine the way it is, thanks. But Drafts is one extension that I think is inarguably useful, and makes up for a key weakness in wiki software to date.

In part one on this topic, I spoke ecstatically about how Wikipedia, in our quest to be more user friendly, could find some inspiration in SocialText’s ability for both WYSIWYG and wiki text editing of a document. Upon further exploration, I’ve found that a few other enterprise wiki software providers, such as Atlassian’s Confluence platform, include dual Rich Text/Wiki Text editing modes. Wikia is also testing a new Rich Text editor of their own, but it is pure WYSIWYG, rather than an optional mode one can choose in the editing window. which, as Angela has kindly pointed out in the comments, also has optional rich text or wiki text editing capability .

But whether it’s SocialText, Wikia or Atlassian, the larger point still stands.

MediaWiki development has done a fabulous job of scaling to meet the crushing demand of some of the biggest wiki communities in the world. A rich ecosystem of useful extensions has sprung up as well, much like the garden of delights to be found among Firefox add-ons.

But the one area that enterprise development has outstripped MediaWiki is in catering to those who need a dead simple wiki. (In all fairness, MediaWiki does have a WYSIWYG extension, but I personally find it to be unsatisfactory, and it is rarely used.)

Why is the enterprise so much better at producing wikis for the neophyte? Because their customers absolutely demand it.

When you’re dealing with a company full of people who almost never step outside the box of Microsoft Office and email, just introducing the idea of a collaborative workspace is like pulling teeth. If there is any real technical hurdle at all, then you can expect your product to fall flat.

I am a drunken cheerleader for commons-based peer production wherever it appears. But within the wiki community, ease of use is the one realm where the profit motive has admittedly produced better results. I say we take it as an opportunity to recognize the success of others, so that we may duplicate it.

With that frame of mind, I’d love to hear what your favorite usability features from enterprise wikis are, and how they might help Wikipedia.

Several weeks ago, the Wikimedia Foundation announced they had received a sizable grant to make the MediaWiki software Wikipedia and other sites use friendlier to edit. Whether it was being in a open frame of mind or just serendipity, I’ve discovered what I think is a perfect example of how we can open the door to less-technical writers.

Recently, I joined some members of the larger wiki community (something we like to call the Wiki Ohana) on a project for which we are using SocialText — who were the first to build an enterprise wiki platform — to organize the group effort.

Since other than a 14-day free trial, SocialText isn’t free software, I’d heard of their latest release (SocialText 3.0, launched in September), but hadn’t explored it until now. Despite some big improvements, it didn’t seem like anything light years ahead of other wiki providers. Until I actually gave editing a go, that is.

The central goal with the grant money is “a series of improvements to the MediaWiki interface” with a focus on “hiding complex elements of the user interface from people who don’t use them” (from the Foundation’s Q&A). Though the identification of the most common barriers to entry for Wikipedia editors will be determined through user testing, it is commonly understood to mean complex template and citation markup, as well as the possibility of WYSIWYG editing.

Below is the initial edit view for SocialText users. It looks like a fairly standard WYSIWYG editor the call Rich Text mode.

picture-22

But click the Wiki Text button to the right of Rich Text, and with a single action you have toggled to a fully featured view of the page’s underlying wiki markup. It wasn’t an instantaneous change from one view to the other, but this simple feature was fairly miraculous an effect for someone used to an “either/or” world of markup vs. WYSIWYG. The two options in edit mode have essentially solved the problem of catering to all experience levels.

picture-32

Also important to note is that that the Wiki Text editing mode wasn’t designed only with master editors in mind. Clicking the Edit Tips button pops up a concise, useful syntax list that can serve as either a short introduction or a refresher course on the SocialText markup language. Hiding the inumberable markup guide buttons that clutter the MediaWiki edit window is almost certainly one of the goals we have for the grant project.

My problem with hiding complexity and using pure WYSIWYG has always been that it makes editing easier for newbies, but cuts more advanced users off at the knees in terms of true power and flexibility. This was the one factor that stood in the back of my mind while reading the news of the grant. Turning a cold shoulder to the community of veteran editors that have made Wikipedia a success is the worst conceivable outcome to any sweeping changes to MediaWiki.

Seeing SocialText 3.0 has dispelled my fear that ease of use and power/flexibility was necessarily a 1:1 trade-off. Here’s hoping that the Foundation and the new developers they hire take a page from SocialText in their attempt to make editing more accessible to the general public, while continuing to enable veteran editors.

401px-wikimedia_foundation_rgb_logo_with_textsvgThe Wikimedia Foundation, the parent non-profit of Wikipedia and many other free culture projects, just received a grant of $890,000 from the Stanton Foundation. According to the Q & A the Foundation has provided, the primary mission of the project that the grant will fund is:

* user testing designed to identify the most common barriers to entry for first-time writers, and
* a series of improvements to the MediaWiki interface, including improvements to issues identified through user testing and a focus on hiding complex elements of the user interface from people who don’t use them.

What exactly these improvements will be are yet to be determined (changes will begin to be tested mid-2009), but are said to include everything from making the edit button more visible to hiding or altering complex wiki markup for templates, tables and the like.

Why this is necessary

Wikipedia is a project that welcomes contributions from anyone and everyone interested in participating, and this openness is the key factor that makes the encyclopedia tick. However, like any new social software, Wikipedia has always taken some time to learn. Along with our exponential growth has come a significant increase in this learning curve, thus preventing some with the desire to help out from doing so.

Don't forget that our 2008 fundraiser is still underway. Click to learn more about donating.

Like the direction this is going? The 2008 fundraiser is still underway.

While it is true that the vast majority of contributions on the site come from a dedicated core group of editors (less than 1% of all contributors, in fact), people do leave the project or fall behind in contributing when offline life intervenes or they lose interest. Like any online community, new contributors must be welcomed in to the site in order to keep the ecosystem healthy.

What it means for you, even if you don’t edit Wikipedia

Not only does this mean good things to come for Wikipedia and its encyclopedia articles, but it has the potential to benefit literally thousands of other projects. MediaWiki, the free and open source software originally written for Wikipedia, has been downloaded by millions. Until now, a lot of the best work in MediaWiki design for skins and so forth have been done outside the development team that works directly on Wikipedia. Somewhat ironically, the biggest and most popular wiki in the world has lagged behind slightly in the area of UI.

These funds have the potential to change that. Just like everything else, all of the new development enabled by this grant will be free and open source, meaning that anyone interested in using, running, or starting a wiki can benefit from this.

Finding a certain article on Wikipedia isn’t usually too hard — you just search for it. But what if you’re just interested in what Wikipedia has on a certain topic? For instance, would you have guessed that there are 44 articles on Olympic competitors from Oregon?

One of Wikipedia’s great strengths is the “category” system. At the bottom of every article, you’ll see a line that begins “Categories:“. The links on that line provide a really interesting way to browse the encyclopedia. For instance, if you’re reading up on one Olympic competitor, you might be surprised at who else you stumble upon by browsing categories.

Ever wonder about the history of bridges in Portland? Looking for a museum in Oregon, but can’t remember the name? Have some questions about Oregon state legislators? Browsing categories can help.

A final note — if you look at the last couple examples, you’ll see not only lists of articles, but lists of sub-categories. In fact, the category for Oregon legislators contains no individual articles; that’s because every legislator we have an article is further categorized as a senator, a representative, or both. So, to get to the individual articles, you’ll need to burrow down into the more detailed categories.

Finally, for a more visually interesting introduction to Oregon-related articles on Wikipedia, you could always try the Oregon portal! On that one, keep in mind that every time you refresh the page, it will load a fresh set of article previews.