Screenshot of the Media Viewer prototype tested in this research.
Media Viewer is a new feature under development by the Wikimedia Foundation, which aims to provide a better viewing experience for readers and casual editors on Wikipedia and Wikimedia sites. This page is about user experience research that has been done recently to contribute to the development of Media Viewer.
Previous research, done in July 2014, revealed usability issues with the live instance of Media Viewer.
Finding image details (get to file page view of an image) on an article page is not very discoverable.
Difficulty discovering info panel expansion in Media Viewer (info below the fold).
When info panel is all the way up, it covers “use this file” fly out.
In the feedback survey responses, people noted that the info panel covers the image and they didn’t like that. Also, 2 participants in this research said this.
People don’t always understand how to control expansion of Media Viewer, even if they have discovered it.
People’s mental model of navigating in Wikipedia, is to scroll down to see more. Media Viewer info panel introduces a new way to navigate, and people don’t necessarily pick up on it.
People appreciate that Media Viewer keeps them on the article page (easier to move from picture to picture).
Media Viewer and File: Page View serve different purposes, and people like the idea of being able to go back and forth.
The only tasks we tested in this research that had usability issues were the disable and enable flows for Media Viewer. The rest of the tasks tested were determined to be usable by most users. Findings and recommendations are detailed below.
We also learned a little more than we were looking for. See the “other findings” section below.
The only tasks which have usability issues are the flows for enabling and disabling Media Viewer.
Everyone found the settings icon eventually, though one person went to preferences first, and one person went to the “edit” tab first.
Language inconsistencies: “previews” AND “media preview feature” AND “file previews” exist in the prototype. We call Media Viewer several different things within the UI, introducing some confusion and lack of clarity in the messaging. These inconsistencies exist both in the disable dialogue and the enable dialogue.
People understood they could press “disable file previews” to disable the feature.
It was confusing to land on the image file page after disabling the feature.
It was confusing to be asked if you want to enable when you just intentionally disabled.
Make language more consistent. Decide on one name for the functionality and stick to it any where in the UI it needs to be referred to.
If possible, once Media Viewer is disabled, land user back on the article page instead of on the file page. (How will they get back to the article page from the image file page view?) This will help with any potential contextual confusion.
How will users re enable Media Viewer (or whatever we decide to call it) from the article page, once it is disabled? This needs to be just as easy to find as disabling. Where will the settings icon be for them to re enable the feature?
The drawer (how any information below the fold is revealed) did not test well (discovery and accidental manipulation were observed) in our first round of research (in July 2014).
This time (August 2014) nothing was tested below the fold.
Drawer needs iteration and testing before re-releasing it.
In the fist round of research, (July 2014) we noticed discoverability issues for the panel (5 of 12 participants), and participants not being sure how to control the open and close of the panel once it was discovered (3 of 12 participants).
Because of these observations in the July research, we need to test any below the fold interaction for usability before implementing it.
The interaction on an article page is a strong mental model (scroll to see more). Scrolling on the light box is a different result, though a similar action for the user. On the Media Viewer, content covers part of the page you are looking at after scrolling. On an article page, nothing is covered, and you scroll down to see more.
The drop down was successful in general, as participants who discovered it (4 of 6) knew what it provided and basically how to use it.
On smaller images (for example images in a gallery), drop down is too large and it covers the image.
The drop down It is one more step than a disabled Media Viewer to get to file page view - (hover to get list, click to “view all details”), but it works well as a way to avoid media viewer as an exception now and then when Media Viewer is enabled.
On the drop down, the double click text needs to change to “double click on image” People were confused if they are supposed to double click on “preview” or on the picture itself.
Readers seem to understand they are on a different page (file page view) when they go to the file page view, but may not understand that they are on a different website all together.
Also, they may not understand that the information on the image page view is not only about the instance of the image they just clicked on, but that there is information about that image, it’s various possible iterations and all the instances of it on other wiki pages.
We spoke with 6 readers, 1 casual editor and 1 power user.
Introductions and show n’ tell about wiki experience and use (see “the questions we always ask section below).
Each participant was asked to complete a set of tasks with Media Viewer enabled, and also the same set of tasks with Media Viewer disabled, in a different article.
The test was randomized by doing the media viewer enabled tasks first and then media viewer disabled tasks second with one user, and then the next user experienced Media Viewer disabled first and then Media Viewer enabled second… and so on.
Also, Media Viewer being disabled/ enabled was be done in one of two articles. The switch from enabled to disabled is achieved by using different logins. So, the first user will experience Media Viewer enabled in the Rapa Nui article, and Media Viewer disabled in the New York City article. The next participant will experience the Rapa Nui article with Media Viewer disabled and then Media Viewer enabled in New York article… and so on.
We used Google Hangouts as a usability lab so we could work with people no matter where they were located (as long as they have high speed internet). In order to do usability testing it is important to be able to observe people functioning in the prototype (or whatever is being tested), so we use the screen sharing functionality to observe people working in the functionality that is being tested.
Chose people who submitted surveys to invite to this research.
Selected interest in "Multimedia (viewing and uploading)"
Coordinate willing and able participants.
What usually takes you to Wikipedia?
How do you usually get to Wikipedia?
When you find the information you are looking for in Wikipedia, are you just reading, or do you gather information from images too?
Do you remember the last time you engaged with or used Wikipedia? Would you please give me a reenactment?
If you have doubts about the validity of doing usability testing with 5 people, please read this article on why there is no need to do usability testing with more than 5 people.
Links to research session recordings. Please check out how the research sessions went by viewing these videos. If there is a link here, the participants chose to make their research sessions open to the public. You may want to fast forward as the researchers were waiting for participants to get on the call sometimes for 10 minutes, and that part is boring.
P4 Decided to share their video only within the foundation. However, the observations and data points from this research session were added to the findings in analysis, and are part of the findings in this report.
Note: The reason we provide the option for someone to only share within the foundation instead of with all of the public, is because some people are shy and would not do the research if they had to be on video for everyone to see. Also, it might hamper their willingness to be candid in their feedback, and we want candid open feedback. So, we provide the option so we can get wide range of people with all kinds of personalities to participate. That said, most people are willing to share publicly.