User:AxelBoldt/Wikipedia usability problems

This is a list of usability problems I have come across in Wikipedia. Notwithstanding this fairly long list of negative remarks: creating a comprehensive coherent multilingual multimedia encyclopedia is an amazingly complex undertaking, and the fact that our current interface empowered tens of thousands of untrained and uncoordinated volunteers to do just that shows that the usability of the Wikipedia website, overall, is outstanding.

Generally, I think Wikipedia suffers from a plethora of links and features on every page, overwhelming and intimidating to the new user, and I will usually argue to remove from the default interface those features that lack a clear rationale for casual readers, our main audience. Features that are mainly useful for editors should be user preference options. All the below comments are about the default skin, MonoBook, from the viewpoint of an anonymous user.

Please feel free to leave comments. AxelBoldt (talk) 20:42, 25 December 2008 (UTC)

While trying to avoid too much redundancy, I've put together my own list of usability problems. I encourage other users to do the same. –M^T 04:12, 29 December 2008 (UTC)

General layout

History tab

One of the tabs at the top says "History". In the context of an encyclopedia, virtually all users will assume this talks about the history of the article's subject, not about the article's version history (which is a foreign concept altogether to the uninitiated). This is an extremely important feature of our website, so its function should be made completely clear.

Proposals

• Call it "Article versions", "Version history", "Versions/authors", "Revisions" or similar.

Comments

• cannot make this too long. I vote for "Revisions". -- 116.49.224.61 (talk) 08:10, 25 December 2008 (UTC)
• "Edit this page" is even longer, and the layout (at least for anon users) has plenty of room here. I now prefer "Versions/Authors", as in the German Wikipedia. AxelBoldt (talk) 20:42, 25 December 2008 (UTC)
• "Revisions/Authors". Reducing space at the cost of clarity is bad. "Revisions" is the appropriate term for writing. –M^T 01:37, 29 December 2008 (UTC)
• I would say revisions is the best option, I would also say I think it would look a lot neater if the tabs at the top were all the same size. Darryl.matheson (talk) 17:51, 29 December 2008 (UTC)
• Versions. -- John Broughton (♫♫) 20:53, 7 May 2013 (UTC)

"From Wikipedia"

Every article, at its most prominent position, states "From Wikipedia, the free encyclopedia". This was historically useful to establish brand recognition, especially in results returned by search engines; those times are over. Everything that can be removed from our crowded interface is a net win. Our brand phrase is already given in the logo in the upper left and in the HTML title; "Wikipedia is mentioned seven times on the page.

Proposals

• Get rid of it.

Comments

• keep it at the bottom to continue brand strength -- Michael Janich (talk) 08:12, 25 December 2008 (UTC)
• Just get rid of it. It's verbatim 1 inch away in the logo. –M^T 01:37, 29 December 2008 (UTC)

Font

Neither Wikipedia nor anybody else should ever use a font that doesn't visibly distinguish between I, 1 and l, or between O and 0.

Proposals

• Use only correct fonts.

Comments

• I quite like the fonts as written. May I ask why this is a problem? Best, PeterSymonds (talk) 17:52, 27 December 2008 (UTC)

Different letters and digits have different meanings, so a font which doesn't distinguish between them doesn't do its job and obscures meaning. AxelBoldt (talk) 22:07, 28 December 2008 (UTC)

• Fonts are browser dependent. On Firefox 3 on Windows, I can see the difference between I and 1 and O and 0 just fine. Mr.Z-man 18:09, 27 December 2008 (UTC)

Yes, me too, I was just listing all possibly problems, so that we won't switch from one broken font to another broken one. On my system upper case I and lower case l cannot be distinguished. AxelBoldt (talk) 22:07, 28 December 2008 (UTC)

• Fonts vary not only across browsers but across operating systems and individual system configurations, and the primary means of specifying fonts is CSS, which only specifies either families (i.e. serif, sans-serif, or monospace) or names (i.e. "Times New Roman", "Helvetica", or "Lucida Grande"), which could refer to any number of fonts. While it would be very nice to specify exactly which font is to be used, the only nearly foolproof method (giving the font data directly as a part of the stylesheet) is not supported by most browsers. This issue probably isn't worth the effort it would require to implement well. {{Nihiltres|talk|log}} 20:26, 27 December 2008 (UTC)

Surely a combination of name and family can be found that produces a correct font on most systems? AxelBoldt (talk) 22:07, 28 December 2008 (UTC)

• I believe Wikipedia defaults to the user's font. Many people are not aware that they can change it to something nicer, but others (especially those with vision problems) rely this because it lets them easily make this default font larger, or serif, etc. Usually p0or charakter use !sn| a major problem. –M^T 01:37, 29 December 2008 (UTC)

"About Wikipedia" and "Contact Wikipedia"

The Interaction box in the left margin has "About Wikipedia" and "Contact Wikipedia". The left margin should be reserved for frequently used links, which these are not.

Proposals

• Combine the two and put them in the footer. That's where people traditionally look for this type of information.
• Agreed. That entire area could be removed. Community portal should be in navigation. Recent changes should be on the main page/community pages. Help (and donate) should be on the top right. –M^T 01:37, 29 December 2008 (UTC)

Comments

Toolbox

The toolbox in the left margin mixes several logically distinct groups of features: tools that relate to this article (what links here, related changes, printable version, permanent link, cite this page), general tools (special pages, upload file) and functions related to a user when viewing a user page (email this user, user contributions, logs). This is counter-intuitive. People expect the tools in the margin to stay the same; I'm sure very few people ever find the "user contributions" link on user pages.

Proposals

• Have a toolbox that deals only with tools related to the current article, maybe titled "this article", another with "general tools", and a third about "this user". The "this article" box could also contain a link to other language versions of the article, see below.

Comments

• Yes, they need to be separated. However, all this should be moved to the bottom of the page. I would love to have data on how often it's used (through referrer header data), because I don't think it's used often enough to merit that much real estate above the fold. –M^T 01:37, 29 December 2008 (UTC)

Languages links

At the left margin, below a series of standard navigation links, comes a list of language links under the headline "Languages". This points to the article in other languages, but it is not clear from the interface; if anything, the interface suggests that these are links to Wikipedias in other languages. The links are fairly far down in the left margin, visible only after scrolling, and I believe they are underused because of this.

Proposals

• Not really sure what to do here. Maybe turn the headline into "Article in other languages", or have a link "In other languages" in the toolbox, which would open a little javascript in place window with the language links.
• Make it a dropdown, and put it below the fold (that is, probably at the bottom). View this article in [English |v]. They're underused because readers very very seldom need to check other languages. If this is being used to lure editors to expanding other wikipedias, we need something more explicit like "translate this page". –M^T 01:37, 29 December 2008 (UTC)
• When a page in :en lacks sufficient information i often use it to look at other wikipages in languages i can read. in the worst case google translate (via ubiquity) can do the work for me, so i can get some additional info. for this reason, even if you use a dropdown, it would be nice to retain the info that some foreign articles are featured articles.-- ExpImp^talkcon 11:40, 8 March 2009 (UTC)

Comments

Footer

The page footer is too crowded, with lots of unessential links. What a tax-deductible non-profit charity is doesn't need to be explained here with links. The GFDL details can be given under Copyrights (which shouldn't be bolded). The fact that Wikipedia is run by and a trademark of the non-profit Wikimedia can be explained under About Wikipedia (Wikimedia is already mentioned via the Wikimedia logo at the left). Information about the last modification time of the article doesn't belong in the footer; people expect the footer to be the same on every page, giving general information about organization and website. The last modification time needs time zone information, obviously.

Proposals

• Cut it down radically: all that's needed is "Copyrights - About Wikipedia - Privacy Policy - Disclaimers". I don't know where best to put the last article modification time; maybe centered just above the footer box? At time zone information to the last modification time.
• About Wikipedia, Contact Us, Copyrights, Privacy Policy, Disclaimers. Print this page, Cite this page, Permanent link, What links here, other languages. The size isn't really a problem, but the way it looks is. The centering is ugly, the two logos on opposite sides should just be text. "Wikipedia is a wikimedia project powered by mediawiki and is a registered blah blah. All text is available under ... GNU. This article was last modified on X". –M^T 01:37, 29 December 2008 (UTC)

Comments

Article layout

Contents hide/show

Every article's table of contents has a [hide/show] link. This is configuration overkill; probably a left-over from ancient times, intended to mollify opponents of the article TOC feature. There is no reasonable reason that a user would want to switch off TOC's; a single tap on the PgDn or Space key takes care of it.

Proposals

• Get rid of it.

Comments

• Agreed. –M^T 01:37, 29 December 2008 (UTC)
• yes. -- ExpImp^talkcon 11:41, 8 March 2009 (UTC)

Nonstandard location of geographical coordinates

Normally, the geographical coordinates of an article's subject are given in the upper right, under the headline. This is ok I guess, but several templates place the coordinates in the template itself and not in the upper right. That means that people get trained to always check two locations for the coordinates.

Proposals

• The article subject's geographical coordinates must be located in the upper right corner.

Comments

• Seems reasonable to me. Best, PeterSymonds (talk) 17:55, 27 December 2008 (UTC)
• And if an article is dealing with multiple places? Or the coordinates are referring to something other than the article subject? Changing the MoS to say that coordinates of the article subject should be put in the top corner is one thing, changing all the templates to do this is another (and would also break existing uses of the templates). Mr.Z-man 03:29, 28 December 2008 (UTC)

Fair enough, I've changed the proposal so that it only applies to the article subject's place. AxelBoldt (talk) 22:47, 28 December 2008 (UTC)

WikiMiniAtlas too well hidden

The geographical coordinates displayed in an article contain three links: one for general information about coordinate systems, one to the WikiMiniAtlas tool hidden under a tiny globe icon, and the coordinates themselves linking to a list of map sources. Most users will never think of clicking on the globe and will never find the quite useful WikiMiniAtlas tool. It is illogical to have the globe link to WikiMiniAtlas and the coordinates themselves link to other map sources.

Proposals

• Only one link should be given with the coordinates. When the user clicks on it (or hovers over it with the mouse pointer), a modified WikiMiniAtlas shows up, which in addition to an interactive map should give the link to other map sources. That map sources page should contain a link to explain geographical coordinate systems. If the user's browser can't display the WikiMiniAtlas javascript tool, then they should be sent immediately to the map sources page.

Comments

• A case in point: I learned from reading this section that the globe was a different link than the coordinates. WikiMiniAtlas look like a nice tool.-- ExpImp^talkcon 11:44, 8 March 2009 (UTC)

Collapsed templage boxes

A battery of collapsed template boxes at the bottom of an article is utterly bewildering to the reader. (See for instance the bottom of Minneapolis.) What am I supposed to do here, what's going on? Click on "v", or "d", or maybe "e"? Or on one of the highlighted bold words in the middle? Or rather on the tiny "show" at the far right? This is a nightmare from start to finish; I'm sure the vast majority of users will never realize that this is a list of related articles.

Proposals

• I'm inclined to say: delete the lot of it, good riddance. Or perhaps more moderately: get rid of "v", "d" and "e" links which are irrelevant to the reader, and then make clear what is hidden here with a text like "Related articles about..." or "Other articles about...". Don't link any terms in the template header, so that the reader is basically forced to click on "show". All these terms are already linked elsewhere in the article anyway. Or more moderately still: make the "v", "d" and "e" links only visible if the template is expanded, and then only in some corner at the bottom somewhere; the "show" link must always be the most prominent.

Comments

• Well, since finding out what each link does, only recently(!), I've found them quite useful. That said, I think the initials need changing. "v" maybe should be "t" (for template); "d" should be "t" (for talk); and "e" should remain. Best, PeterSymonds (talk) 18:01, 27 December 2008 (UTC)

• I agree that the v, d and e links are not relevant to the reader so perhaps they could not appear by default, with editors being able to have them appear if they wish. On the Minneapolis article, I agree that an average user would be completely confused by the array of templates, I have always preferred the way most football templates have been done (Scottish Cup for example) because none are collapsed and the user can be left in little doubt about what they are for. Perhaps all templates could be always displayed although I realise this could look very messy, if possible it could be a good idea to be able to click any part of the template header to make it visible although of course that means you can’t have links in headers. Darryl.matheson (talk) 17:34, 29 December 2008 (UTC)

Related templates are different

The template for French cities is completely different from the template for American cities. This negates the usefulness of templates: to allow the user to quickly locate relevant data. Whenever you come to a city page, you have to scan the whole template from top to bottom to find the piece of information you are looking for. The same is true for the various templates about people, etc.

Proposals

• Unify related templates.

Comments

Distracting tags at the top of articles

The top of the article, right below the headline, is the most important real-estate, the area that all readers will focus on. Yet we often use that location for bookkeeping tags that have no relevance to readers, overwhelming them with jargon and technical information that they couldn't care less about. Examples I came across in the last couple of days: [1], [2]. Readers do not care whether some editors believe that a given subject is notable enough, or might merit merging, or is "orphaned", or needs cleanup, or might be written up in a too technical style, or that the lead section might be too short, or that the article is about a current event etc. etc. All of these are solely of concern to editors; it is a crime to waste our reader's time and attention with them.

Proposals

• Tags at the top of an article should be restricted to the ones of immediate relevance to readers: missing references and neutrality disputes. Everything else should be put on the Talk page, or at the bottom of the article, or should only be shown to logged-in editors. (I'm not sure if the software currently allows for the latter option.)

Comments

• This is a perennial proposal. Mr.Z-man 18:13, 27 December 2008 (UTC)

Pronunciation link overkill

Many articles hit readers over the head with three bewildering links before the text even starts; see for instance [3]. Until you try out the links, the terms "help" and "info" are synonymous. Where do I have to click if I need help or info regarding the pronunciation of "Eindhoven"? It turns out neither link is for that, you fool.

Proposals

• Pronunciation should be given with a single link, consisting of a loudspeaker symbol and the word "pronunciation". Clicking on that link should bring the user to a page that has a link to the actual sound file and its description, as well as a general link to help regarding sound files. This requires one more click on the part of the user, for a very rare use case, but removes all confusion.

Comments

• Agreed. PeterSymonds (talk) 18:02, 27 December 2008 (UTC)

Images

Image description page

If you click on any image, you'll get the image description page transcluded from Commons, and one sentence somewhere in the middle of the page tells you so. The Wikipedia page has a different History and Discussion page from the one at Commons. If you click on the correct link, you'll be sent to the Commons image description page, and only then can you see the categories the image belongs to, as well as get access to relevant tools, view the right discussion and history page etc. The difference between the "History" and "File History" links are obscure; the meaning of the "File" and "File links" links are obscure. No user can figure all that out initially, it is unbelievably complicated, layers on top of layers of obscurity.

Proposals

• If you click on an image, a naked page should appear with a single sentence on it, telling you that the image is hosted not on Wikipedia but on Wikimedia Commons, and providing a link to the image description page there. (Logged-in users should have a user preference option to be sent directly to the Commons page.) At the very least, Wikipedia pages about transcluded Commons images shouldn't be editable and shouldn't have a discussion page on Wikipedia.

Comments

Searching

Search box location

The search box is the most important element, so it should get the most prominent spot, in the upper left.

Proposals

• See the Dutch Wikipedia design

Comments

• While I agree that the search box could be placed better, I disagree that the Dutch Wikipedia's layout, or merely moving it up in the sidebar, is the answer. I personally prefer the current sidebar search box sandwiched between the "navigation" and "interaction" sections: if we're going to make it more prominent the answer is probably a new skin, which would have the beneficial effect of also accommodating many of the other changes suggested on this page. {{Nihiltres|talk|log}} 19:38, 27 December 2008 (UTC)
• This was most recently heavily discussed at MediaWiki talk:Sidebar#Moving search box above navigation in November, and before that [when it was successfully requested that it be moved from below "interaction" to its current position above "interaction"] at MediaWiki talk:Sidebar#Moving the search bar in July - this should all be considered. Aside from that, I personally agree with Nihiltres' comment above. Also, I still prefer the idea of just highlighting the current position with color - either background or border, for example - in order to break up the block-list of links (and draw the readers' eyes to them), and for aesthetic reasons. -- Quiddity (talk) 21:46, 28 December 2008 (UTC)

"Go" vs "Search"

The function of "Go" vs. "Search" is not clear; it's non-standard. Only advanced editors will ever want to use "Search", but most casual users will click on it because they don't understand "Go".

Proposals

• Use "Article" vs. "Search".

Comments

• It's not clear. Not even with "article" vs. "search". Why not do the obvious: if article exists, go there. If not show search results. -- Michael Janich (talk) 08:18, 25 December 2008 (UTC)

That's precisely the behavior of "Go". Since almost all casual users will want that, maybe it's best to have a "Search" button with our current "Go" behavior, and a small "advanced" button that brings you to the search page with all the options. AxelBoldt (talk) 20:42, 25 December 2008 (UTC)

• I would support swapping "Search" for an advanced search link, provided the Special:Search page was improved first. Pretzels^Talk! 21:18, 1 January 2009 (UTC)

Auto-suggestions obscure buttons

When the a list of auto-suggestions is presented in the search box, the Go and Search buttons are obscured. Thus the functionality of the "Search" button is in effect not available to users, since nobody can be expected to find the "Esc" key.

Proposals

• Getting rid of the "Go" button as suggested above would take care of this problem as well. But make sure that the "advanced" button is not obscured by the auto suggestions.

Comments

Cursor keys in auto completion

When a list of auto-suggestions is presented in the search box, holding down the cursor-down-key should scroll down in this list, but in IE 7 it doesn't, it goes down only one position. Firefox 3 works.

Proposals

• Fix it.

Comments

Search results page layout

The search results page should present the search results most prominently, starting at the top, but it doesn't. First in small grey font it whisperingly reminds me of what I searched for, and offers me to go the pages that start or link to the term. I haven't even had a chance to look at my results yet! Then it tells me how to view this page without the search results! What? Then it offers help about searching. Then it tells me I have to search for images elsewhere! Could you please get to the point? Now, not yet, first another search box, where it says "MediaWiki search", a phrase that is meaningless the casual user. Finally and exhaustedly, we make it to the search results. This is a disaster.

Proposals

• The MediaWiki search box does not belong on the search results page. We already have a search box in the upper left (which ideally would give us access to advanced search). The search results should start at the top, followed by a headline "Not what you were looking for?" and then a list of hints, such as Searching help and advanced search and creating an article. The detail about image search should be covered on the Searching help page. The advanced search functionality belongs on its own page, not on the search results page. Wikipedia:Searching should be Help:Searching.

Comments

• Wow. Never saw any of that, but now that you point it out, it is obvious HOW cluttered that is. It's just that my brain has become so good at NOT SEEING useless stuff on webpages. The casual user should not be expected to have that ability. Wow again.-- ExpImp^talkcon 11:54, 8 March 2009 (UTC)

Advanced search

The namespaces should be explained; as mentioned below, the "Wikipedia" namespace will be mistaken for the encyclopedia. The drop down menu defaulted to "MediaWiki search" is obscure.

Proposals

• Instead of a drop down menu, create a radio button list, so that the user immediately sees all options: "ah, they allow me to use Google instead!". Use "Wikipedia search" instead of "MediaWiki search". It's incorrect but clearer.

Comments

Search in namespace "Wikipedia"

The search result page offers to restrict search to "namespaces". That term cannot possibly make sense to users. Every thinking person will check "Wikipedia", since they want to search in Wikipedia. How are they to know that the encyclopedia is not in the Wikipedia name space?

Proposals

• Rename the Wikipedia name space to "Project", which is what the tab at the top calls it already.

Comments

Sister projects box in IE 7

If the browser window is too narrow, IE 7 will display the sister projects box so that the first search result's text cannot be seen. Works correctly in Firefox.

Proposals

• Fix it.

Comments

Searching help

The top of Wikipedia:Searching confuses the confused even more, with two lines of technical and irrelevant crap. The introductory paragraph, supposedly about Wikipedia's search, gives another link to Wikipedia's search! "Am I supposed to click on that now?" The link to Wikipedia:Look it up only adds to the confusion: "should I go there or will I find my answer here?"

Proposals

• Get rid of the top two lines. Get rid of Wikipedia:Look it up; it doesn't add anything.

Comments

History page

Layout

The order of elements on this page is very illogical. First in small font it gives "logs", then it gives a "browse history" box, then comes the navigation row allowing you to go through the history entries, then comes a line of help, then come external tools, then a horizontal rule and another two lines of help. Finally we reach the history list proper.

Proposals

• Concise help on top (no need for Help:Edit summary), but need to explain that every line contains date in UTC, author, and edit summary, and that clicking on date gives the then current version. Then navigation row, then the history list. Then the "browse history" box. At the very bottom a box combining external tools and logs. (The fact that the tools are external is not important to the user.)

Comments

Browse history box

The "From year (and earlier)" language is awkward. Also the use case is unclear; would people be more interested in browsing the history starting at a certain date, rather than ending at a certain date?

Proposals

• Maybe "Show article history from before/after Year.... Month...." and make before/after a drop down list.

Comments

History help

Suppose a user is overwhelmed by the article history page and clicks on Help:Page history. They are then accosted with the following text: "This is a copy of the master help page at Meta. Do not edit this copy. Edits will be lost in the next update from the master page. See below for more information. edit Shortcut: WP:PAGE This page deals with revision control." Not a word of this makes the least bit of sense to the new user. It is jargon-filled useless crap from start to finish.

Proposals

• Help pages should only show help, not technical information intended for experienced editors.

Comments

• The text you mention is from the {{tl:H:h}} template; it's not built into the the Help: namespace. And I suspect that the practice of overwriting wiki.riteme.site Help pages with meta.wikimedia.org Help pages has fallen into disfavor, which makes the warning not only confusing to newcomers but also bogus. If we really didn't want people to edit help pages that originated (at some point) from Meta, then we should fully protect them, and have admins do the overwriting when needed. -- John Broughton (♫♫) 23:05, 31 December 2008 (UTC)
• That technical stuff could better be put into an editnotice or something. ParlorGames 19:13, 2 June 2009 (UTC)

Editing

Categories in edit preview

If you edit an article and then preview it, the list of categories is shown at the very bottom of the screen, where no one would expect them and few will ever see them.

Proposals

• The list of categories of a previewed article belongs at the bottom of the preview screen, just above the edit summary line.

Comments

Copyright warnings in edit window

The edit page repeats the same basic copyright warning five times, with different words and fonts and links and footnotes all over the place. Similarly, the test-in-sandbox messages is repeated twice. The interface is already way too overloaded as is.

Proposals

• Put a single statement there, in clear and simple language, in a bold font.

Comments

Templates

By far the most intimidating aspect of editing Wikipedia are the templates. Ever changing, ever expanding, each with a different set of parameters, nobody can remember them all, nobody knows when to use which one or where to get a list. It is a nightmare, the antithesis of the original simple Wiki syntax. In many articles, the first thing a user sees when they hit 'edit' is code producing some sort of infobox; only if they think of scrolling down will they ever find the comprehensible text. If you think you understand templates, check this out.

Then, at the bottom of the edit page, we read: "Pages transcluded onto the current version of this page" followed by a list of template names. Could that be phrased any more obscurely? The edit links behind the template names are overkill; changing a template is such a rare operation that editors can be expected to spend a separate click on it.

Proposals

• I don't know what to do about the general problem of templates; probably we should radically cut them down in number. Separating the editing of infoboxes from editing the article text might be a good idea, as done on Chickipedia and on Wikia. The statement on the edit page should read something like: "The following templates are used on this page. Click on a name to find out how to use it." Get rid of the edit links. Each template must have simple usage instructions on its page.

Comments

• I agree we need to reduce the number of templates. I disagree that they are "the antithesis of the original simple Wiki syntax." Templates are a simple way to include complex things in a (ideally) standardized way. The options are to either use templates, or put the complicated syntax directly into articles. Mr.Z-man 03:34, 28 December 2008 (UTC)
• At minimum, it would be nice to color text that is part of the template itself - the text that novice editors generally should not change - so that it isn't so similar to text inside the brackets that has been added by editors. -- John Broughton (♫♫) 23:11, 31 December 2008 (UTC)

Editing support features

The row of edit buttons and the box that allows to insert unfamiliar symbols belong together. Right now the latter box is even below the Save/Preview/Cancel button.

Proposals

• Put the symbol box right below the edit button row, above the text field. That's where all text editors have their toolbar.

Comments

• If the symbols are to be above the text box, they would surely need to be collapsed with a JS Show/Hide, so as not to take up too much space? Pretzels^Talk! 21:09, 1 January 2009 (UTC)

Button row balloon help

The balloon help for the buttons can be improved: "Level 2 header" is meaningless; just say "Section headline". "Embedded file" should be "Embed image or sound" (the example should be an image, not an .ogg sound file, since the former is much more common). "File link" is too rare to warrant a button. Create a button for a bullet list.

Proposals

• See above.

Comments

Preview/Save/Changes/Cancel/Help

Once done with editing, the user has four choices: Preview/Save/View Changes/Cancel. All these should be buttons, next to each other in a row. Editing help is logically separate and should be somewhere else, probably above the text window, by the editing support tools.

Proposals

Comments

Page length

Somewhere in the middle of the jungle that is the edit page, we find ourselves reading: "This page is 49 kilobytes long." This information is neither needed nor desired at that point.

Proposals

• Get rid of it.

Comments

• Some people want it, so stick it in an unobtrusive space like, say, in the corner or something? ParlorGames 19:16, 2 June 2009 (UTC)

Miscellaneous

Scrolling through long lists

The article history, recent changes, search results and several other lists use the following syntax to page through many items:

"(Latest | Earliest) View (newer 50) (older 50) (20 | 50 | 100 | 250 | 500)"

That is completely non-standard and obscure.

Proposals

• Maybe use a layout of the form

"(prev) 1 ... 13 14 15 ... 67 (next)

"Show 20/50/100/250/500 items per page"

more akin to what Google and most other sites do.

Comments

Article evaluations

The talk pages of many articles contain templates that place the articles under the purview of a certain WikiProject, rate it according to a standard quality scale (stub, start, C, B, good, A, FA) and give feedback. (See e.g. [4].) But the templates don't specify which version of the article was reviewed, thus forcing the reader to do detective work in article histories, comparing dates and times to track down the reviewed version.

Proposals

• The evaluation tags need to provide a link to the reviewed article version.

Comments

Permanently linked pages aren't truly frozen

Users who use the "Permanent link" feature from the toolbox to get a stable URL expect a link to a page that's frozen in time, but that's not what they get. The resulting page is not stable, since the contained templates and images can change over time. The underlying wiki text is stable, but to the average user this distinction is so subtle to be meaningless. If an editor wants to truly and completely "watch" all changes to a page, they need to put all contained templates and images on their watchlist as well.

Proposals

• Ideally, permanently linked versions (as well as all versions from the article history) would always include the templates and images as they existed at the time, not as they exist now.

Comments

• Is this a solution in search of a problem? Highly used templates rarely, rarely change, and if they do, typically only trivially (adding another parameter), so the current version of a template is virtually always appropriate - and certainly much less problematical for the MediaWiki software. Keep in mind that templates are often nested; it's not just a linking to an older version, but then that version needs to link to an older version. In short, what exactly is problematical about the current approach of using the current version of templates in prior page versions? -- John Broughton (♫♫) 23:17, 31 December 2008 (UTC)
  • The problem is that the user doesn't get what they expect (and need). The main use of permanent links is for reference and documentation purposes and to provide links to checked and vandalism-free articles; because of the outlined problem they cannot be trusted for those purposes. Templates that aren't "highly used" are often deleted or changed radically, in which case a permanently linked page can become unreadable; this can even happen to templates that were formerly highly used (see old taxobox or reference or geo coordinate syntax). "Problematical for the software" should never be an admissible argument in usability discussions; I don't think it would be very difficult to give the template and image resolution routines a timestamp as additional argument. AxelBoldt (talk) 05:10, 16 February 2009 (UTC)

Talk namespace

The tab at the top calls it "Discussion", which is much more descriptive. It's an unnecessary hurdle for new users to make them figure out that "Talk" and "Discussion" refer to the same thing throughout Wikipedia.

Proposals

• Rename Talk namespace to Discussion. That would then also turn "Wikipedia talk" into "Project discussion", a lot more descriptive.

Comments

• That's actually two separate proposals; it's not clear that "Project" namespace is clearer than "Wikipedia" namespace. -- John Broughton (♫♫) 23:19, 31 December 2008 (UTC)
• Disagree with John. "Project" may not be the ideal name, "Internal" or something along that line might be better, but it is clearly better than "Wikipedia", which for all intents and purposes means the actual Wikipedia, which it does not contain.-- ExpImp^talkcon 12:03, 8 March 2009 (UTC)

See also

• Wikipedia:WikiProject Usability
• Stanton Grant for a Wikimedia usability study
• User:Pyrospirit/Design the interface for newcomers
• Wikipedia:WikiProject Usability/Reducing interface complexity
• User:M/Wikipedia usability problems
• Wikipedia — Time for a Redesign?