Media Viewer Research Round 2 (August 2014)

Screenshot of the Media Viewer prototype tested in this research.

Introduction

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

Previous research, done in July 2014, revealed usability issues with the live instance of Media Viewer.

Here are the high level findings from that research that relate to this research:

What needs improvement

We observed these usability issues in the July research:

• 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).
• Info panel in Media Viewer causes other usability issues:
  • When info panel is all the way up, it covers “use this file” fly out.
  • Next and previous arrows covered when info panel is expanded
  • 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.
• Message in the prototype (Viewing options panel) is not clear (This was a very early prototype of the enable / disable flow.)

What worked well:

• 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.

Why we did another round of research:

To address these issues with the live version of Media Viewer (noted just above), we iterated and prepared a minimal design, including these basic features:

• a more visible link to the file page
• an easier way to disable and re enable Media Viewer
• an image caption right below the image
• clearer icons for download and share

Goals of this research

The goal of this round of research, done in August, 2014, was to do a usability test with readers, to understand if the revised, minimal design of Media Viewer successfully enables readers to accomplish the following tasks easily:

a) Primary tasks

• Preview larger images (click on thumbnails to view images in Media Viewer)
• Learn about the image (read full caption and/or full description)
• Get more details (go to file page)
• Browse related images (next/previous)
• Disable feature (cog icon to opt out of Media Viewer)
• Re- enable feature (cog icon)
• Go back to article page (close Media Viewer)

b) Secondary tasks

• Enlarge image
• Share this image (copy the file link)
• Download the file
• Find out who created the file

During this usability study, we also tested a drop-down menu over image thumbnails on article pages. Though this is an experimental feature, we wanted to test it for possible future implementation. So, we decided that if participants discovered the drop down, we would ask them about it and have them explore it to gather some preliminary research for this functionality. Please see the find

Findings and Recommendations

We observed that test users were able to accomplish these key tasks with no problems:

• Preview larger images (click on thumbnails to view images in Media Viewer)
• Learn about image (read full caption and/or full description)
• Get more details (go to file page)
• Browse related images (next/previous)
• Go back to article page (close Media Viewer)
• Enlarge image
• Share the image (copy the file link)
• Download the file
• Find out who created the file

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.

Disable / enable flow:

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.

Recommendations for disable / enable flow:

• 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.
• Provide a small confirmation that the feature has been disabled, and notification that to re-enable, you go back to the settings icon, rather than the enable call to action. (“Media Viewer is disabled, to re-enable, go to settings icon”)
• 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?

Other Findings

Below the Fold on Media Viewer:

• 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.

Recommendation for Below the Fold:

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.

Drop Down menu on thumbnails

• 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.

Contextual Awareness:

• 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.

How this research was done

Methodology

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.

Each research session was recorded, and notes were taken through the sessions. After all the sessions were complete, we reviewed notes and recordings and looked or patterns in the observations. We found patterns, and those are what is reported in this report (success or failure of usability of the tasks we were testing, plus some bonus findings.)

Where

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.

Who

Here is a description of how we recruited participants for this usability study. (Note: The research was conducted with 6 readers, 1 casual editor and 1 power user, and the findings in this research are based on the 6 readers. We would like to talk with more casual editors and power users, but ran out of time in this round. Because Media Viewer is being built for readers to experience media, focusing on readers was most important for this study.)

1. Sent out a recruiting survey
2. Chose people who submitted surveys to invite to this research.
3. Qualifications for each user type for this resaerch (via self report survey):
   1. Readers:
      1. 0-5 edits
      2. Reads Wikipedia
      3. Selected interest in "Multimedia (viewing and uploading)"
      4. Has high speed internet
   2. Casual Editors
      1. 10-100 edits
      2. Reads Wikipedia
      3. Selected interest in "Multimedia (viewing and uploading)"
      4. Has high speed internet
   3. Power Users
      1. Vocally Opposed to Media Viewer
      2. Major contributions
      3. Has high speed internet
   4. Send invitation emails
   5. Coordinate willing and able participants.
      1. Release forms sent and signed
      2. coordinate timing of research session

Questions We Always Ask

We also gathered some information from the participants to better understand how they use Wikipedia in the beginning of the conversations.  We asked participants to show us what they did last in Wikipedia (a kind of show n’ tell). With every usability study we will ask for the same show n’ tell, and over time, our understanding of users will be more clear. Depending on what functionality we are researching, there may be slight variation in for example, question 3 below.  Here is specifically how we asked this question for this research:

1. What usually takes you to Wikipedia?
2. How do you usually get to Wikipedia?
3. When you find the information you are looking for in Wikipedia, are you just reading, or do you gather information from images too?
4. Do you remember the last time you engaged with or used Wikipedia? Would you please give me a reenactment?

Recordings and Other Information

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.

• Shiran, P2
• Carol, P5
• Hasanga, P3
• David, P8
• Morgan, P7
• 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.