The last couple of days we have received some excellent feedback. First of all thank you to everyone who took the time to study our problem and form an opinion. To be able to receive input from the best people in the field is extremely rare and rewarding. So what we’ve got is: Lots of applause, some questions and some reservations. Let’s take a look at some of these now.

We chose to address the following questions and comments from a well-known and respected authority:

Jared M. Spool asks:

1. The LA Times tried this experiment and failed. How is your design informed by their experience?

The LA Times failed because they used a courageous yet—in hindsight—incredibly naive approach. Their most obvious mistake is that they allowed anonymous posting. We feel the key to preventing the same result is user identity. Under their own name people usually act much more responsibly, and, for a newspaper, clear identification is not so difficult: They can link profile identity to their existing (paper) subscriber database.

Posting on a newspaper is a (pretty cool) privilege, not a right. Here is how it works:

1. This project, whilst based on Wiki software, will not be a public editing tool. It is a tool for editors to gather information and feedback for the paper edition of the next day. Only editors can edit articles.
2. To comment, you will need a basic level account in your own name. Good comments will be integrated into the printed article the very next day (instead of the usual letters to the editor days later). If that turns out to be too liberal, commenting will be restricted to identified users. Users will also rate each other’s comments.
3. Paper subscribers will be automatically ranked as an “Amateur”. For non-subscribers, identification will be as strict as with citicendium. The incentive to become an “Amateur” is that you have a chance for your entry to be published in the online edition, and, if it’s really good, in the print edition. You will be remunerated for both.
4. Editors will be able to move articles between different categories and sections. Before being published, user generated content will be edited and checked for integrity.
5. Journalists will be able to edit their own articles.
6. Once an article goes to print, it cannot be altered, but only annotated. The history is accessible to everyone.

2. It’s very sharp looking and you’ve obviously put a lot of thought into it. However, in either the description or your comments, I don’t see what user research was involved in how a wiki improves the user experience of the paper. In other words, what’s the improvement in the user experience because of your redesign?

We feel the answer to this is in two parts – how the concept of a wiki (openness) can improve the overall newspaper experience, and also how the the wiki software itself can improve the usability/experience of the website.

Improving the Newspaper experience

Newspapers as they are are fairly closed environments, and as you can see from our explanations above, we don’t intend to open up the website, but the entity of the “Newspaper” itself. The full power of the technology will mostly be used by in-house journalists and editing staff. From their perspective it will streamline the entire production process, where-by the wiki becomes an airing ground for ideas and drafts, and through wiki-style collaboration, they can see these ideas through to a finished piece.

Where readers benefit from this is through transparency – they will be able to see what’s coming up, how it was made, and where the information was sourced. Once the article is published online it becomes open for comment and suggestions from the general readership, and after this (at the discretion of the editor), will appear in the print edition along with the best reader contributed content (which they will be paid for). Is this an improved experience for a newspaper reader? We believe so.

Improving the technology experience

From a conceptual and technical point of view, Mediawiki is a work of art. However, for most user’s it has some pretty insurmountable Usability issues. Most usability-minded people wouldn’t have too many problems finding sore points. We have identified a few:

1. Wikicode (used to format articles) is jargon and to most people, probably just looks plan scary. The default text editor is extremely powerful, and to give this to people right off the bat is both intimidating and dangerous. We’re currently working on integrating a Wordpress-style WYSIWYG into the software. This also means putting a GUI on top of all the templating and layout functionalities possible with Mediawiki.

2. Navigation is also confusing – we’re experimenting with more sensible navigation tools (breadcrumbs, for instance) and completely re-skinning the default interface. This includes, obviously, the concept of an “edition” which can be easily navigated in and between.

3. We are looking at the various system pages, search results and user pages in order to make them more intelligible.

In terms of user testing, we have been using profiling and testing with the various flavors of users (editors, journalists, readers, etc) to gather requirements, and are constantly improving our changes based on their feedback. At the moment we are trailing this project with an online magazine, in which we can test the remaining assumptions we have made. Worst case, the wiki will be modded down to a simple CMS. As the initial investment is – compared to professional CMSs—considerably low, this test run is more than a reasonable approach for our client. If it doesn’t work out they can still use the developed designs in another environment with less functionality.

A word on scrolling

1. Since the nineties, the general assertion has been: People like to have as much stuff as possible in the visible area.
2. Our assertion is: People want to a) be able to find the information their are looking for quickly, and b) be find their news well organized, easy to read and easy to scan – which leads to bigger font sizes, less clutter and scrolling. (The New York Times has 100% font size (16px) on their article pages. Why? Because it’s more important to be able to read the text than having as much text as possible on one page.)

In our experience, which in great part goes back to working with T-Online (and these guys were obsessed with the page fold and getting as much clicks from the start page as possible), people don’t mind scrolling if they find everything they need in the visible area. That is the art of the online page fold. Not to cram as much information in there as possible (hoping for a lucky shot) but to reduce the info to it’s very essence. The actual reduction to the present state was a lot of work. This is how it’s organized:

However, the assertion that people prefer organized, scannable pages over the usual link orgies needs serious real-time testing; and this is where our preliminary magazine project will help us again.

A bit more fat to chew

So, with those concerns hopefully answered we’d like to provide a bit more detail on how things will work. Here’s another diagram detailing exactly what each type of user will be able to do:

What do you think?