Problem/Motivation
Two or three weeks ago I've done an impromptu user test, asking attendees of the Drupal Dojo Austin about their first impression about certain parts of Project Browsers browser page. For the reference, that nights attendees were @rocketeerbkw and @cutehair. Back then the changes for renaming the source types to Contrib modules & Core Modules just went in, and i've enabled all available source typescontrib modules, recipes, and core modules on the instance. When looking at admin/modules/browse their initial reactions were:
- There are so many secondary tabs. one attendee said they dont like the tabs, why are there tabs at all in the first place?
- The secondary tab labels were all challenging.
recipes said nothing to one attendee, sounded like something to do. while contrib modules and core modules, they knew, but considered potentially confusing for people in particularly new new to drupal.
- There was the question about the purpose of the
core modules source type, isolated it seemed not to provide any benefit nor purpose.
Steps to reproduce
Proposed resolution
For @rocketeerbkw's, from a experience perspective those three secondary local tabs are the same thing as another filter drop down. In his ideal world he wouldnt have to bother about searching in modules, core modules, recipes, or any other available source types. He raised the following exemplary task: "a user wants to install a contact module and searches for the string "contact" in project browser". for the core source type he finds the contact module, in recipes he then mayb finds recipes that add for example contact blocks, searching on contrib he gets all the contrib modules in relation to the term contact, same as on any other available source type. he would have to step through every available source type to make sure one might contain something related to their search objective. more ideal would be a search bar to find everything (what project browser is already doing but the interface is communicating in a potentially confusing way -
#3457966-6: Filter (categories) selection is leaking over into other sources →
). Why one has to search in multiple tabs. in the current implementation it is easy to miss and not to find what you are searching for when you have to step through the different source type tabs. so technically @rocketeerbkws's suggestion was moving the list of available source types from secondary tabs into a new multi select filter with the default option to show all source types.
The main problem i see with this approach is that none of the available source types has an identical set of filters. that makes this endeavor a "bit" tricky.
An intermediate step we'Ve discussed would be to at least merge the contrib and core source type into one filter type. those two source types have a similar set of filters so you are able to search contrib and core together. cuz at the moment the core source type lacks sort of a purpose but having at least those two source types within a filter, for one you could call the secondary tab just modules instead of contrib modules and core modules which would make it less confusing for in particular new users. the tab is about the concept of modules, contrib and core are subsets of the concept of a module. and then you would be able to search for core and contrib at once and that way would already see modules in that search context that are already installed or available for core while also seeing the results for additional contrib modules on d.o.
another downside, by moving things from different source types, into a single filter, is the point about if a context for source type is the local file system or a remote repository on d.o or a private repository somewhere lese. that is another aspect that makes molding different sourcetypes together into a single search experience potentially problematic.
But overall i thought it is worth raising and bringing those ideas to a broader discussion. At the moment it is still a loose collection of thoughts and discussion artifacts.