MediaWiki Developer Meet-Up 2009/Notes/Usability

This session on Friday was attended, for at least part of the time, by Raymond, Trevor, Tgr, Nikerabbit, Danny B., Arash, Angela, Henna, Purodha, Stu, TOR, Inez, and Multichill.

See also the separate notes on WYSIWYG.

Wikimedia's Usability studies

Wikimedia's Usability studies (WMU) are primarily focused on the English Wikipedia, but also hoping their work will be of benefit to other MediaWiki users including Wikimedia's other projects and other languages. The work may have a greater impact on the growth of the very small wikis than on the English Wikipedia. It is also hoped that chapters will get involved and continue the usability studies in their own areas and languages. The tests being produced can be re-used by others.

• Qualitative studies have been done remotely and in a lab. Small scale study but still finding the majority of problems people have in editing. Can be hard to find out why people do not edit in real-life lab settings as they may be embarrassed to say they have nothing of value to add.
• Quantitative studies may also be done in future, such as surveys asking people whether they find editing easy or not. And looking at "what just happened" by viewing revision histories or seeing whether more categories get added after features such as Category Select are implemented.
• There is a need to measure quality and see how usability features affect that.
  • This is being testing on test.wikipedia.org in the form of a box on the article asking readers to rate it.
  • Could also check deletion rate to see whether more new bad articles are added.
• The wiki at usability.wikimedia.org will be used as a reporting tool and will contain the tests used.

Shortcut keys

• Who uses shortcut keys? Are they meant for accessibility or for power users or for new users?
• Do they need to be the same in different languages? By default alt-e is edit (not alt-b in German), but this can be changed on the wiki.
• Shortcut keys can be displayed on tooltips but aren't consistently.
• WMU found people trying to use shortcuts they knew from other applications, such as Ctrl and B for bold but these do not work as Ctrl is used by the browser for something else.
• Some of the shortcut keys rely on javascript (eg - drafts extension) whereas other use key mapping instead.

Educating people in wiki syntax

• Important for people to learn why they ought to use "second level heading" and not "big text". People need to learn that headers are used for reasons of document structure and not as a reflection that one paragraph is more important.
• There is some fear that WYWISYG will take away this learning experience and people will not understand proper structure.
• There was an example at Wikisym 2005 of using wikitext but instantly showing the effects, so == would make the text after it in the edit box look like a heading, so you learn the wikitext more quickly.
• Is there a need for people to be educated in wiki syntax? This might not be the goal.
• If the barrier is too low, will the quality of the content decline?
  • If so, could that be better dealt with by the community and not technically?
• Arguments against WYWIWYG
  • People with no investment in the movement behind Wikipedia will be less likely to understand and/or share the community's goals.
  • People may not take it so seriously if they do not need to learn anything about it.
  • They ought to be willing to invest some time. If they don't, how will they cope with licensing or conflicts?
    • Perhaps those areas are where the time investment and education are needed, and not in the simpler editing tasks.
    • Education can also come when people study the Manual of Style and guidelines.
• Outside of the larger-language Wikipedias, there may not be such a perceived need for artificial barriers to entry.
• Wiki syntax might not be the largest barrier, so making radical changes to that is not a goal of the WMU.

Educating people in what is happening

• People are confused about why their text or article was removed. They don't know if it is awaiting moderation or if there was a technical problem. It's not obvious that someone has reviewed the text and removed it from the live site within seconds of you saving it!
• Could use more messaging to tell people in near-real-time what is happening with their edit
  • User talk page messages may not be enough. In the WMU studies, one person was trying to work out why their sentence had been removed and ignored the orange box telling them they had a message.
    • Solutions found on other sites may work better. For example, having a box appear over the screen you're on already showing activity rather than needing to go to a separate page to see that. Other sites show your messages in an "inbox" format which new users may find easier than a plain page full of text.
  • They don't know to look in the page history for edit summaries.
  • The community should inform editors what is happening, but this could be supported by technical solutions, such as giving editors an option to leave a message for the user automatically when they rollback an edit. It needs to be part of the workflow.

Community needs guidelines on usability

• Wording of templates can be confusing. For example, talk pages with a template saying "this is not a forum". People assume that means they should not post there - they don't understand that it means you're allowed to the discuss the article but not to give opinions on the topic!
• Some of these bad templates are not visible enough to the community so are not fixed.
• How can the community be taught about better usability?
• The wiki at usability.wikimedia.org aims to become a repository of information and an educational resource for informing people about making their wiki more usable.
• Sometimes the problems are due to a clash between tech people and others rather than any UI problem.

Uploads

• There is a separate grant-supported project from the WMU to improve the upload system, though it does tie into usability as well.
• Simpler uploading tools are available, but are not currently tied into any system of making the licensing process easier to understand.
• Wikia has more images per article, but this is partly due to different rules some wikis have on accepting fair use images and not entirely due to image upload improvements.

Categories

• Category pages aren't always what people want when they click a category.
• People don't know which categories exist or which one(s) to add to a page. They may try one and get a broken (red) link.
• Tagging versus categories - they have different aims. Categories need to be part of a hierarchy or tree. All tags are valid, but not all categories are. People are more used to tags from other sites.
• Category difficulties apply both to articles and to images.
• Categories may be more suited to an encyclopedia whereas tags may be more suited to images.
• A better category management system is needed.
• One problem with categories is the lack of a good category search built into the wiki, and a lack of ability to look at category intersections.
• If the search worked well, it might not matter so much if people used categories or tags.
• The concept of "does a category exist" may be confused for newcomers. Does making the category description page make it exist or does putting something in that category make it exist? no such problem with tagging.
  • Wikia tried out making all category links blue on one wiki even if the category page didn't exist, and many more categories were added - though they were not part of any tree (it's not clear whether or not that matters)
• Categories on commons tie in with i18n improvements and the use of a global translation dictionary to automatically translate them.
• One way to improve the search on commons would be to show the images used in Wikipedia article "foo" when someone searches for "foo" on commons.
  • They're often the best images for that topic.
• Only 3% of images on Commons have a topic (not license) category.

i18n

• On Commons, templates are translated automatically.
• ?uselang= does not stick and preferences do not carry across projects. (global preferences would be useful)