User:Wwwwolf/MediaWiki Usability

I'm collecting some points about MediaWiki's (lack of) usability here.

Overall, I think MediaWiki is a fabulous piece of software at least what comes to interface, wiki markup language, operations, and features and versatility.

Really Freaking Big MediaWiki problems

MediaWiki isn't a forum, bug tracking system, or a learning environment. It just masquerades as one. Sometimes badly.

We use MediaWiki for a lot of things. We have message boards, periodic initiative tracking, formal sessions with multiple sidetracks and voting, software bug tracking... and the thing is, MediaWiki isn't really built for this stuff. It's a platform for general information dissemination, and it's built for displaying articles efficiently and to offer a markup syntax that is expressive and powerful, for that particular purpose. If you want to do something else, the Implementor has to come up with new markup. The Reader has to shift gears in mind to find the page that the Implementor has wrought. The Reader becomes a Participator, and has to shift gears once again, to understand the markup logic that the Implementor has invented. In other words: We have a bunch of discussion happening in AN every freaking week where people have to tell people "this really isn't a matter that needs administration attention"... because people can't find the correct message board for whatever they want to talk about. We have people come in AfDs and not know how to a) present their views and b) present their !votes, and people have to reformat their comments later. Argh. You can understand things like ''double apostrophes'' for italics, but logic about markup can't be extended to situations where markup meets the Implementor's protocol - "in Wikipedia discussions, you have to indent the messages with colon" is One of Those Things You Have to Know®. Imagine how nice the world would be if all this would be taken care of automatically?

MediaWiki isn't a mine.

Data mining and Wikipedia. Data mining and Wikipedia. Think of that! We have tons of frigging data here. Why can't we use Wikipedia's data more efficiently, both for informational purposes and for administrative purposes? Why aren't our reports more clever? Why can't we build complex ad-hoc queries on the massive Wikipedia database? This is pretty hard stuff, but if we had that, oh boy, life would be so easy...

General MediaWiki problems

• Image pages are confusing as heck, and probably will need to be completely redesigned.
  • File history, metadata and links look like they're part of the image description page.
    • Perhaps put metadata and links on the right side of the page, visually separated from the rest of the contents of the page.
  • File history is shown separately from the page history.
    • Suggestion: Change image history tabs; The current one should be labelled "Page history" and add a new tab labelled "File history".
    • Or combine the Page and File histories into one page.
    • Or just combine the histories into one unified history page that includes both the file changes and page changes. It could have an option to view just the page history or just the file history.
• Uploading new versions on top of existing images is confusing too. The page gives you exact same controls as you get when you upload a new image, but the page contents are used for edit summary! These interfaces should really be separate.
• Signature magic words sign time in UTC, yet the users frequently see times as local time. (Not sure how to elegantly handle this. Maybe make log/contribution listings have tooltip that, when you hover on top of a localtime-based datestamp, shows the UTC time on tooltip.)
• Admins should be able to view user's deleted contributions through Special:Contributions. They could, for example, show up in grey or be somehow visually differentiated. (Or just show up in black, with a link to Special:Undelete.)
  • There's a new feature in works that will allow this; however, last I checked it showed up as a different Special: page. For comparison purposes it would be really cool if the existant and deleted revisions would show up as one list.
  • Likewise, diffs on deleted revisions break for normal users (as expected), but they also break for admins. Why do we need a different interface for this stuff? Why can't we have an "I see dead revisions" mode?
• Special:Contributions should be able to limit the links to pages that start with certain phrase. (E.g. "Contributions by User:Wwwwolf to Articles for deletion debates")
• Special:Whatlinkshere should be able to limit the links to certain namespace (like Special:Contributions already does) or to pages that start with certain phrase.
• Ordinary Users® have considerable problems finding the page log. They have no idea why the article was deleted. (Proposition: If the page has deletion log entries, show the most recent one at the edit page and missing page, and an easy link that points to the rest of the log.)
• If there's an exact hit for a Search, it should be made a little bit more prominent. Currently, the exact hit is listed in a rather small typeface.
• Working with new templates is hard, especially if the template contains ParserFunctions, includeonly and like...
  • Possibly a multi-document editing mode where you can edit Template:InfoboxWhatever along with RandomArticle and see how InfoboxWhatever would look on RandomArticle...
• And why in the name of sweet damn Jimbo the categories appear BELOW the edit box in previews? Did anyone really think this is a good idea?
• Editing nonexistent pages by default makes navigating hard:
  • When you follow link to a "User:Some guy/Incendiary subpage", and the article exists, you can return to "User:Some guy" with a click of a link. At least until someone deletes the article. There's no way to get to the upper level page if you're sitting in the page editor!
  • Likewise, deleted images appear as redlinks, and by clicking it you end up in upload form. Try seeing if a Commons file exists. I dare you.
• "Show version that was deleted" link on deletion log would be really cool, sending you directly to Special:Undelete of that particular version.
• If anonymous editing is disabled through LocalSettings.php permissions, "Edit" tabs are still "Edit" tabs... which means that there's absolutely no dead easy way to get to the View Source thing. All you get is an error. However, if the page is protected from editing, you can view source normally.
• When searching with Go, and the page doesn't exist, we end up with a list of stuff and another search box. Type stuff in, and ta dah - it repeats the search without the "Go". If you want a Go search, you've got to edit the stuff in the tiny little search box and hit Go.
• Special:Undelete for images doesn't set the file name properly. The file appears as "index.php" and when trying to save, you get a garbage filename. If it was something along the lines of OriginalFileName-RevID.extension it would be swell.
• Category pages list page content, followed by Articles in Category, followed by Media in Category. This needs to be way more configurable. I have a very difficult time teaching my users that any Word docs they want will be under the Media heading (below the fold!), while wiki pages will be under the Articles heading. For my purposes (on an intranet), they are all the same, yet I can't group them together -- I can't even change "Media" to "Documents", or put Media above Articles. As a result, Category pages are nearly useless to my non-web-savvy users -- I create new articles to re-list half of my category pages just to make them more useable, which creates its own set of problems.—Preceding unsigned comment added by 131.216.164.117 (talk • contribs)
• Special:WhatLinksHere is bloody useless for most purposes because it doesn't allow any sort of filtering based on link context - indeed, there is no way to specify the context on the linking page. For example, previously, checking what links to speedy deletion candidates was easy: Just click on the WLH link in toolbox and you see the few funny pages that link there. Now, you get tons of spam on everyone's Handy Alternative Views of CAT:CSD. Likewise, finding links to articles is bloody useless if you have gigantic navigation templates in the page: "Oh, yeah, five squillion unrelated pages link here, half of them through Template:Big-ass nav box on one topic and half more through Template:Big-ass nav box on completely different topic - sorry, no way to tell them apart". If these things would be categorised, like "link from an informational list of speedy deletion candidates" or "links related to the topic X" or "link added through navigational template", that would be great. Would Semantic MediaWiki be nice here?
• DB replication lag reporting isn't always informative. A good indication of this is that we've had to manually add guess-this-could-be-the-reason remarks in pages where lack of updates can cause confusion. "this page doesn't yet exist, it could be due to DB lag, or it could be something more sinister, but heck, we have no way of knowing - just don't panic, it usually is just DB lag." I hope there would be better reporting along the lines of "database lag is very high, so this log may not have the most recent entries" or "...this page may not be visible yet due to it."
• Create a namespace. Create a page. Delete a namespace. Now try accessing the page in any way. Hilarity and confusion ensues.
• Try to salt the article. The default protection state is "unprotected". Yeah, the list shows the current state of the page protection, but it could show the likely desired outcome of the operation (salt the damn page)

Markup problems

• Template syntax is effin' messy at times.
  • Especially in transcluded cases.
  • The worst are the templates that include table markup. Both tables and templates use curly braces and pipe characters, which means they're hell to use together.
• <ref> syntax is altogether too easy to break. Yeah, you can easily understand that if you delete a full reference that has a @name on it, all empty references with same @name break... but if you move the full reference around, you need to move the contents of the ref to the earliest reference, or all preceding ones break!
  • A better solution would be to always use shorter form of refs in the article body text (<ref name="foo"/>), then list all full references in a separate tag (<reflist><ref name="foo">...</ref><ref name="...">...</ref>...</reflist>. You know, kind of like BibTeX got it right back in the iron age.
• subst:ing stuff is pretty messy, as you can not say "always subst this template", much less "subst all stuff that this template transcludes, recursively". Perhaps we should get __SUBSTITUTE__ and __SUBSTITUTEALL__ magic words?

Monobook problems

• Want to save the site logo in browser? Um, that's harder than it looks like...

Wikimedia weirdnesses

• MediaWiki.org new releases links to release announcements instead of the tarballs. Guess what I'll wget when I'm over 90% caffeinated?