Module interviews analysis

Goal

This study was focused on understanding the current behavior of users and the desired behavior of users. This to inform our process in redesigning the module page.

Specific research questions we set out to answer:

• In which situations do people use the module page?
• What are the commons tasks the user performs on the module page?
• How do they experience using the module page for these situations?
• What are their needs and desires for the module page?
• How do people experience the grouping?
• How do people experience the operations?
• How do people make experience using the description, version and module name?

Based on the insights we derive from answering these questions, we inform the direction of the module page redesign?

Targeted audience: current users

We wish to learn how people currently use the modules page. To do so, we want to talk with a broad range of roles, from the occasional sitebuilder to the module maintainer. In order to get comparable input for our questions, each participant must meet the following requirements:

• Familiar with Drupal
• Experienced with using the module page for site building
• Not involved with core issue http://drupal.org/node/538904

We differentiate primarily in how experienced they are with Drupal. Are they using Drupal for their personal pet project or do they build with Drupal on a daily basis.

Acknowledgments

We would like to thank dcmistry, bleen18, lisarex, Sutharsan for carrying out the interviews.

We would like to also thank all those who reviewed the analysis; webchick, yoroy, Kattekrab, nearlythere, jenlampton, tvn - and anyone we missed in this list!

Results

The modules page is a crucial page for people who are building sites and configuring new functionality. In its current form, this admin page succumbs under its own weight. Many discussions and suggestions for improvement have been made. We found we first needed to research how people use this page before taking decisions on which problems to solve and how to solve them.

To do so, we interviewed 22 people. Developers and site builders both professionals and hobbyists.

• Have built small personal website, to enterprise sized websites.
• On average 3.4 years of experience with Drupal doing various tasks, from site-building to custom module and theme development
• Used Drupal 4.5 up to Drupal 7.
• Install between 20 and 200+ modules for a site

Interview script
Anonymized raw data of the interviews

Current use

The primary use of the module page is to enable and disable modules.
When we asked people what they want to do on the module page, the answers were:

• Enable/ Disable modules (16 participants)
• Configure settings (9 participants)
• Check dependencies (6 participants)
• Set permissions, (6 participants)

What’s important to you? (we asked them to assign points to a list of tasks)

Scrolling and slow loading of the module page, is marked as a major pain point

• “Hate going to that page because it takes too long to load” (P5)
• “Historically poor page-load time” (P10)

Enabling and disabling modules that have dependencies is difficult to do

• Enabling modules with dependencies, is primarily done in a trial-and-error fashion: simply getting Drupal to tell them another module is required/needs to be installed.
• Enabling modules with dependencies is considered easy, until it requires installing modules that are not present.

Categories are used sporadically, mostly to filter the amount of information when searching for a specific module name.

• Apart from the single ‘Core’ category, people feel the categories are very inconsistent and often do not help in actually finding the module.
• It’s hard to collapse all categories, it requires a lot of scrolling and the collapsed states are not saved for the next visit.
• 16 of the 22 participants had negative reaction to the groupings used on this page.

When we asked how they go about finding a module, browser search was identified as a common pattern.

• Browser Search (15 participants)
• Scrolling/ Scanning (2 participants)
• Grouping + Scanning (1 participants)
• Drush + Browser Search (1 participant)
• Unavailable information (3 participants)

Finding a module through browser search (CTRL+f) is quite difficult to do

• It is common to run into many false positives with browser search before finding the actual module, due to the module being named as dependency.
• More than half of the respondents had negative reaction to their process of searching. The remainder of the participants had a neutral reaction about it.

Drush users hardly use the module page anymore; enabling, disabling and uninstall is handled by drush

• Drush users only occasionally come to the module page to find the configuration and permission per module.

Desired usage

Overall people would like to find modules faster

• When they know the name of the module, it is currently to hard to find it (methods like CTRL+f don’t really work). A filter of some kind would help.
• When they just uploaded the module, finding the module on the page is difficult
• Categories hardly help in finding modules. People wish there were better ways to filter the list.

Would like for the module page to be less overwhelming and better at hiding or removing information like dependency information

• The dependency information is overwhelming and people feel they often don’t need to see it at first sight.

Would like a certain workflow for configuration and permissions after you enabled a module

• After enabling a module, its not clear what to do next - this is especially true for modules that the user is unfamiliar with.
• Experienced and beginning users use the configuration and permission links, however some do not notice them.

Discussion

There is a lot of information in this packed analysis, some of it confirms our assumptions but a lot of it also sheds new light on what we thought was important.

We would love to discuss these results, and move forward towards redesign proposal for the module page later this week. We should have released all the important material, however let us know if anything is missing or we need to clarify more on the research methods we used.