Module interviews analysis

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

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:

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)

Task Rating
Enable / Disable / Uninstall module 26
Find a module 15
View available updates / update module 10
View current module versions 6
View list of disabled modules 5
View list of modules by functional set (e.g. Views) 3
View list of modules of specific category (e.g. Core modules, administrative modules, media management modules) 6
View list of recently installed modules 9
View module description to orientate what the module is about 8
View which modules are required to be able to enable, disable or uninstall a module 6
Other 7

 

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.

Comments

Huge Win

cosmicdreams's picture

Looks like we can have a huge win in D8 by optimizing the page for "Browser Search", which i assume means using the in-page search ability of the browser (Control+F in Windows) to search the text on the page.

This would mean that we can hide the dependencies and requires statements and provide those when the user clicks to show that information. Additionally show all that information when a user tries to install something that can't install because of missing dependencies.

Software Engineer @ The Nerdery

Awesome!

neclimdul's picture

Awesome! I see a lot of things that support concepts we'd already identified like packages being useless and searching being a big pain point which is very reasuring.

Everyone is probably interpretting these they're own way but I find something else interesting. People are focused on enabling/disabling modules and people with drush available avoid the current workflow and go for the drush alternative of a basically 1 click install removal process. I'm sure there are other ways to interpret this but it seems supportive of my request to remove the checkboxes in favor of some sort of button/toggle workflow. At least it makes the solution worth investigating.

The number of checkboxes

Sutharsan's picture

The number of checkboxes required to enable or disable modules was never mentioned. But the iterative process of disabling modules which have dependent (children) modules was mentioned to be a pain. To make the disabling of modules with dependencies as easy as enabling modules with dependencies would be a bigger win than getting rid of the checkboxes.

As a site maintainer I

neclimdul's picture

As a site maintainer I disagree but I wasn't allowed to be interviewed because I have a stake in the discussion and I'd be interviewing myself. :)

Because they didn't specifically site checkboxes as a problem doesn't mean that we can't synthesize that they are or might be a pain point. I was trying to cite things I think hint to this and might lead us to further research on the subject.

Another thing that was mentioned was scrolling which is a function of our checkbox workflow. I know there's a mockup with the button fixed on the side that addresses this particular concern but as I think I've said, removing the checkboxes addresses a bunch of problems, provides a better interface for developers, and provides a path to address concerns like "Would like a certain workflow for configuration and permissions after you enabled a module" in a sane manner.

When I build a site that

Draven_Caine's picture

When I build a site that someone else will maintain, i always install Module Filter. The admin module page is always a bit daunting for newer admins.

Also on a permission point Faster Permissions is always installed too.

If you have a few roles and a bunch of add-on modules, both these pages can be over-whelming.

I'm enthusiastic about the

jessehs's picture

I'm enthusiastic about the talk here so far. I agree with the conclusions people seem to be arriving at.

For the most part, I wouldn't push any drastic changes here. I've always thought it was fairly straightforward, if not efficient. (Yes, it's relatively slow for sites with a lot of modules.)

+1 for hiding dependency info on initial view, both for browser search ability and to keep it simple for non-technical users. (The less info that's crowding the page, the better. Users should be able to show all the extra info via JS if they want to see it.) I also like the idea of saving the users' settings so when they collapse the "Core" fieldset, it stays closed until they open it again, or if they prefer to always see all dependency info, it will always be there. I, personally, would leave most fieldsets sets closed most of the time, except for the "Other" one. I think some nifty JS would be cool here. Perhaps an autocomplete box at the top that automatically opens the fieldset where the match is located.

I also agree with the notion that disabling a module with dependencies should be as simple as enabling one with dependencies. It should take only one round of disabling -- no iteration should be necessary.

It functionally can't be as

neclimdul's picture

It functionally can't be as simple sadly. Say my module depended on views and nothing else on the site depends on views(views ui is not required for views to work). I disabled my module does views is automatically get disabled?

That's not to say the process couldn't be significantly improved though. Finding crufty modules in Drupal is miserable.

Regarding the disabling of

jessehs's picture

Regarding the disabling of modules with dependencies, I was just referring, for example, to disabling the Views module itself. If the Views UI module is enabled, then the Views module's checkbox is grayed out. So in order to disable Views, I first need to un-check Views UI and submit the form. Now Views' checkbox is no longer grayed out, and I have to submit the form again to disable Views.

The desired behavior (I say) is that I would be able to un-check Views and submit the form. I'd then be presented a confirmation message something like, "Views UI is dependent on the Views module. Would you like to disable them both?"

If a module is left enabled that is no longer needed, I think it should be a manual operation to disable it. I could see it being frustrating/confusing if I disabled a module and Drupal forces me to disable a module, simply because it no longer has any dependents, although it could be a feature for Drupal to ask whether or not you wanted to disable it. (I think the Features module currently does this.)

Bikeshedding

Sutharsan's picture

I suggest we move this discussion over to Allow disabling of modules with dependents. It'll be more fruitful there.

More autocollected infos on a module ...

ronan.orb's picture

Even as a experienced drupal developer, some modules do not point me in the right direction WHAT they do or better where to start setting things up. Most of the time, when in luck there is this ONCE message from the installation where I can start.

Some modules which are more envolved come mostly with a great advanced help.

In my opinion, each module tells the drupal system via hook, which menu calls of Type XYZ and which forms is maybe alters. Well the last part is not so easy.

I have no idea if such an module exists, but there are other modles like the http://drupal.org/project/variable module, which try to fix or make things more useable.

For example, a module could be invented, which has a info hook, where on install a module can tell which forms it alters. The menu hook already tells the system which url pathes the module uses. With that informations a drupal page could be provided, where Links to pages could be provided which the freshly installed module added to the drupal system.

http://foobar.com/admin/module/module_name could then show these gathered informations.

This indeed would be a little bit redundant, BUT a very helpful starter for users of a new unknown to them installed module. It's just an helpful page of pointing fingers.

Improved module handling

NWwaterboy's picture

I have many years in site development/admin but only 6 mos or so in Drupal recently, one moderately complex site using a distro and 3 or 4 simple sites; quit using it about ver 4.5 or so.

What I would like to see is when installing a module, that after install, a list of uninstalled required modules, and a list of installed not enabled modules, would be generated, that I could checkbox for installation or enabling. Then click a proceed button and they would queue up and start to download or enable.

A recently installed or enabled filter would also help for selecting the modules to check for permission and configuration settings. But generally, I go with the defaults initially and changes to the permission and configuration is done as needed at a later stage.

To help understanding; a option next to each module to show required / related installed modules would be helpful.

Hi! I'm doing Drupal meetups

svenryen's picture

Hi! I'm doing Drupal meetups in Singapore and been developing for drupal since 2007. After observing many developers and new users that try out different modules, I think a module audit log would be useful.

The module audit log or trail would simply show the history of module activation/de-activation, the time/date and user id that was used to activate/de-activate modules.

This small improvement would be highly useful for debugging and tracking down issues related to recently enabled modules.

-Sven

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week