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)
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
Comments
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
Comments
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
Comments
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)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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
The search box is the most important element, so it should get the most prominent spot, in the upper left.
Proposals
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
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
Comments
The article history, recent changes, search results and several other lists use the following syntax to page through many items:
That is completely non-standard and obscure.
Proposals
Comments
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
Comments
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
Comments
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
Comments
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)
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
Comments
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
Comments
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
Comments
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)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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
The search box is the most important element, so it should get the most prominent spot, in the upper left.
Proposals
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
Comments
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
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
Comments
The article history, recent changes, search results and several other lists use the following syntax to page through many items:
That is completely non-standard and obscure.
Proposals
Comments
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
Comments
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
Comments
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
Comments