Newspaper Wiki: Schematics
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:
- 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.
- 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.
- 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.
- 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.
- Journalists will be able to edit their own articles.
- 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:
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.
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.
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
- Since the nineties, the general assertion has been: People like to have as much stuff as possible in the visible area.
- 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?
4.10.2007
00:29
Okay…after reading your details, there is definitely a lot to like here (and, as you know, I was skeptical before). I think this model could be pretty interesting to apply — to stories. It works there because stories don’t contain structured data, which circumvents the biggest problem with wikis (their inability to store structured data). So, for stories, this could be interesting.
But I’m sure you know that a good newspaper site contains a lot more than just stories. Here are some of the other types of content newspapers typically have which really require structure in order to be done well:
Overall, I’m impressed with some of your ideas on workflow and business process. There’s a lot of good stuff in both charts above. Much of these ideas can be applied to all types of content, not just stories. But, with wiki software being inherently designed for storing unstructured data, I’m not sure that technology is appropriate for the content types I listed above.
I’m glad to see your ideas don’t really just apply to wikis, though. I can see how a lot of these ideas could be implemented in our content managements system (www.ellingtoncms.com), which will never be a wiki (because we’re obsessed with storing good, clean, semantic and structured data).
Well done.
4.10.2007
00:32
Nice overview of the NewsWiki process. I especially enjoyed the user roles chart.
Question: Isn’t the print edition irrelevant? I think newspapers need to start grasping the undeniable truth that readers are beginning to realize the printed paper is outdated by the time ink hits the paper.
4.10.2007
00:50
The print edition still makes a crap ton of money (more than the online editions, for sure!). So, while it’s definitely on it’s way to irrelevancy, I don’t think it’s quite there yet.
4.10.2007
09:27
@Jeff - I thought so too but this kind of startled me:
“Newspaper companies are still making money. But their average profit margin of 17% is down from 26% as recently as 2000–just one data point in the industry’s Worst Year Ever: “I think 2006 will turn out to be the first year in which print revenues actually were negative for the year,” says analyst Rick Edmonds of the Poynter Institute.”
From this article: http://www.fastcompany.com/subscr/114/open_next-essay.html
4.10.2007
15:42
@Jeff,
I am particularly proud we could convert you. A guy high in/on information design and also journalist insider—who can stop us now?
: )
As soon as we get a ready to go from the client, I’ll happy to give you access to the first prototype.
As for the profitability of online journalism: It’s pretty easy to criticize the WaPo designwise, but economically they seem to be ahead of time:
IMHO newspapers are not going to disappear anytime soon, the weak ones are dying already though; the strong ones will (have to) become a luxury product, much nicer than what we’re used to today.
Maybe within 20 years reading printed news will be as exclusive and expensive and nice as riding a horse vs riding a car. But that’s just speculation. In the mean time, we’ll do our best to give journalists a more powerful tool than MSWord… Happy, you’re on board.
4.12.2007
18:31
Finally, this was bound to happen one day. And it’ll work. Why will it work? Because the best software in the world are written that way: by open source communities. Why won’t it collapse to an anarchic disaster? Because it’s in the origin of species to evolve that way: some natural selection will happen among contributors so that a hierarchy of skilled journalists will naturally take place, just like a chemical process that crystallizes a substance at the top of another one.
Newspaper wiki is Open Source Writing raised to the level of Humanity. And we’ll love it!
4.14.2007
00:03
I’m wondering about the user roles and whether they could be simplified. The language in the Duties row morphs from “duties” to “responsibilities” and “potential punishments” once it gets to users, which makes me a little nervous.
I don’t remember all the details on the LA Times wiki debacle, but I suspect that like most big media companies, they figured they could just bolt on community and sell ads on the resulting traffic. The very fact that they were unprepared for the chaos that ensued pretty much proves this out. Anyone who’s managed an online community knows how much tending it takes to be successful. It’s very much like gardening (public, community gardening).
What you can learn from successful startups like Flickr is that 1) you have to spend a lot of time on your site answering questions and helping new users learn their way around, and 2) eventually, you are going to need your user community to help with #1. If you’ve built a valuable resource your users care about, they will want to help out.
But to get there requires trust.
Who do you value more: Journalist Joe who writes a popular column on the site, or User Sally who spends hours in the comment threads, keeping conversations on track and answering questions? They both have an important role to play.
So — I’d flatten the user roles by combining Journalist, Amateur, and Commenter.
Requiring registration, the ability to flag objectionable content, ban users, and having an attentive human moderator will allow you to protect the space you’ve created while trusting your users.
As for Jeff’s comment on structured data, it’s true that wiki pages don’t include that as a default. But I wonder if you couldn’t achieve much of the same thing (without the db efficiencies, of course) by using custom input forms that could translate an obituary, for example, and display it as a microformat? Bit of a hack, I admit.
I’m definitely on Jeff’s side re: semantic, structured data. The advent of the Django (what Ellington CMS is built on) and Ruby on Rails Web app frameworks is really changing the entire software game, and you really need to be thinking about re-evaluating your software strategy.
These frameworks are radically changing how Web apps are developed, deployed and managed. And the risks involved in going with a custom solution can often be lower than customizing a large open source project.
6.11.2007
21:43
Fascinating - fascinated already
6.17.2007
17:55
I agree on the role that an easy text editor could play. Just a suggestion: the text editor should also contain flag and other tags used by the wiki engine. Tags are the way to turn a wiki build for raw text files to a more structured system.
7.3.2007
18:38
Hm, the fact some comments get simply erased if you re not comfortable with em, sounds a bit like censorship.
7.3.2007
19:10
Franky,
I rarely delete comments. Here are the reasons to delete comments:
If I deleted one of your comments because I misjudged it, I am sorry, but I don’t censor people because of their opinion.
Of course, I am only human, if I have a bad day, and someone just really pisses me off, I kick that bastard off my site.
Lately I get a lot of iPhone and anti-iPhone propaganda. I delete most of it.
The other day I had one of those anti-iPhone dudes here that posted a long seemingly prefabricated argumentation in spanish why some spanish woman shouldn’t buy the iPhone. And I had a bad day. So that means hasta la vista. It’s not a spanish site and it’s not meant to be used as a propaganda platform.
Accusing me of censorship after all I allow here (check out the 95% typography post), actually kind of pisses me off, but I have a good day, and it?s a relevant suspicion (are these just the positive posts? - Answer no!)
In the beginning I had a lot of moaning and whining and complaining about my grammar, but recently people became quite nice.
Ah yes, and there was this anonymous stalker, that thried to find a weak point on every single post, trying to bully me on my site. Guess what, I tracked him down and told him, I’d post his crap, if I could use his real name. And guess what again? He didn?t want me to.
So which post did I delete that you felt had a good argument?