> Requesting a reinstatement of a deleted page in a properly designed UI should take no more than a couple of clicks and 1 minute of reading, tops.

That assumes that it would be beneficial to have people who don't understand anything about what makes an article worth keeping making requests like that.

It also assumes that requesting deletion review is Wikipedia's most valuable place to spend developer and designer time.

Neither is true.

No, it assumes that user task design should follow the tenets of good UI design.

What I'm hearing you say is that usability barriers are a good thing because they stop people who don't understand the system from using the system, which is the refrain of all defenders of bad UI design. We've seen plenty of disruption in the area of software UI design in recent years that disprove such a theory.

UI design is not a religion whose tenets are to be followed for their own sakes. It's a practical art. Good UI makes easy things that should be easy, and hard that which should be hard. (E.g.: http://www.zen171398.zen.co.uk/Alien%20Page%206/Ian%20Wingro...) Your mistake is naive optimization of one part of the process.

In this case, the right system would be one that makes it very easy for deletion review to process requests. It would also make sure that only well-formed, well-thought-out deletion requests make it to the deletion reviewers. The UI of that submission process could be made easy, but it's an essentially hard problem. You're supposed to think carefully, come to grips with the careful balance that Wikipedia has struck around deletion, and then submit a reasoned argument.

It's not possible that someone will do that in 1 minute of reading. This is like a submission to an appellate court: you have to know what you're doing or there's no point.

I haven't made myself clear. I'm not saying that someone should understand what the CONTENTS of their submission should be with only 1 minute's worth of reading, but rather the ACTIONS the user must take from a UI perspective in order to go through the process should not take more than 1 minute's worth of reading.

If the content of the user submission should be carefully thought out prior to taking the action, that's fine, but you shouldn't be deliberately throwing obstacles in the way just for the sake of slowing them down. What ends up happening when you do this is that knowledgeable people (who generally happen to be busy) won't bother contributing. I've seen this sort of situation occur countless times on Wikipedia (in general, not just with the deletion process).

Maybe I'm a fast reader, so try timing yourself reading this: http://en.wikipedia.org/wiki/Wikipedia:Deletion_review#Steps... . I don't find it to be much more than a minute.

I would really, really love to see this. Even with the core MediaWiki platform too.

MediaWiki is open source BTW. I would do this if I could, but alas, my UI skills are not quite there. Are there any sharp UI designers who want to do this? It would be a hell of an addition to one's resume, not to mention the world :)

There are simply way to many forms and inputs we have to deal with on Wikipedia to make it a one off for every case. We eat our dog food all over wikipedia for that reason.

Personal user styles and javascripts are even stored as wiki-pages. We use Wikipages as IPC for bots and users. We use Wikipages for user messaging. I mean it's everywhere. User's get used to it and can figure out wikisyntax through the site and it's easy.

For it to get added as a special page, it has rise to a general enough thing to be needed by everyone using Mediawiki or something so pressing that could never or should never be on a Wikipage. Meta concepts usually only fit that (like permissions and stats and new page reviewing).

"We use Wikipages as IPC for bots and users. We use Wikipages for user messaging. I mean it's everywhere."

And that's actually a big part of the problem. You're extending a paradigm far beyond what it's good at. When you're researching, you're looking for all of those deep nuggets of information that you'll get from poring over reams of data. Those tangental links are a joy to discover.

For a user trying to accomplish something quickly, however, it doesn't work. Reporting an issue, contributing to discussions or even FINDING them, navigating a voting page... Basically everything PROCESS related is a place where a wall of text is the most unwelcome thing you can be presented with.

It's great that you dogfood; just remember that the old unix hacks ate their own dogfood too. But rather than make things friendlier for people, it just made the unix hacks more defensive about their unfriendly system.

That's a reasonable concern, but I think the alternative historical paths are all worse.

Wikipedia was run on a shoestring for many years. Developer time was in incredibly short supply, and was mainly spent on keeping the site alive. However, there was a massive surplus of labor from people who could work a wiki. People did what they could with what they had.

Had they put more of there developer time into lower-priority features (e.g., a fancy but unnecessary discussion system), they could well have blown up. Or they could have tried to get more developer labor by increasing revenue sooner. But that would have meant ads, which could have destroyed Wikipedia in a different way.

Going forward, Wikipedia should definitely be more friendly, and the Mediawiki Foundation is devoting substantial resources to that.

That's very cool. Right now many experts are turned off by the unfriendliness of the system as it stands today. If that can be remedied, it will be a great boon to human knowledge as we'll see an increase in expert contributions.

I definitely agree that Wikipedia has wide-spread and deeply seating UI issues; but I disagree that opening a review for the reinstatement of a deleted page should be a simple matter of a few clicks.

If a lengthy discussion has already reached conclusion on a matter, having someone jump through a few hoops and provide a good reason to reopen that debate doesn't seem unreasonable.

All process related activities should be a simple matter of a few clicks, regardless of what that process is.

Making someone jump through hoops (beyond a simple warning page) as a deliberate policy is even worse than organically grown bureaucracy.

Part of the problem here is getting developer time onto fixing up such an issue. a) I don't think the Foundation employs a UI expert and b) the community actually requesting serious feature enhancements has a history of taking. absolutely. forever. :)

(although; I agree, improvements to certain processes would be very handy)

Wikipedia does employ UI experts. You can see them here:

http://wikimediafoundation.org/wiki/Staff_and_contractors

I have met some of them; they are smart and competent.

People's expectations about Wikipedia's development speed are all out of whack. The main problem is that Wikipedia is run on a shoestring compared with any other top site. A major contributing problem is that for much of Wikipedia's history it was run by a handful of people, all of them struggling mightily just to keep up with traffic growth. That means a lot of work has to go into paying down technical debt.

Fair enough; I should do better research :)

My comment about taking forever was not really to do with the lack of developer time (which, as a developer myself I totally understand!) but more about the difficulty of meshing two communities of people.

In much the same way that an outsider struggles to understand the Wikipedia system, many Wikipedians have difficulty understanding how development works, and how to interact with developers.

This disconnect means that requests for even simple things can take a while :)

I can highlight this disconnect; the idea given in the GP is smart and sensible and would help make the deletion review process a lot easier for newbies. This would certainly help with editor retention as well as being widely useful.

On the other hand, one dev recently wrote and deployed "WikiLove", which is a script for helping people give each other "Barnstar" awards.

Ok, so perhaps the GP's idea did not come up in discussions of "what should we improve next". But if the WP community proposed something like this it would probably sit gathering dust whilst the next WikiLove would appear on our screens.... :)