Notes from our BoF meeting about the project detail pages on Drupal.org and in Project Browser. First of all, thanks to everyone who participated, we had some really great, insightful feedback!

=== NOTES ===
Suzanne Dergacheva - Does a lot of training with people that are new. So - does this module do what my requirements are? (2) What is the credibility? How do we assess these?
- description right now is too long in order to know that information / answers to those questions at a glance. sometimes there is too much information. On the other hand, sometimes it's really good - but it's not too succinct in there for what we need.

For establishing credibility:
- how many use it (active installs)
- how many issues (can be tricky, because lots of issues might mean good activity and a lot of people using it)
- who wrote it (useful to more advanced users)

Adding on - what version is it in? Is it stable, security advisory? Current d.o page shows compatibility, but says "compatible with Drupal 8" but also shows "works with Drupal 9" - this should be consolidated and made consistent.

On Drupal.org - the "works with 8" but also "works with 10" ... if it DOES work with 10 (as in, next version already), wow, that's a really good quality signal. (drumm)

Andy - images - screenshots of what the config page is helps me understand what a module does or does not do. Looking at wordpress and magento, 6-8 screenshots on a lot of those. these are SUPER important. Animated GIF!!! (people were really excited about that)

"Use Cases" section - explain HOW this module could be used. Most used use cases for something like Geolocation can "put stuff on a map"

WHY DO WE SEE CTOOLS FIRST?! I have some API-modules only, I get it. But it's not interesting as the first result in project browser. May need something with the project browser to eliminate developer-only or api-only modules by default.

Andy - Dries talked about featuring some modules that need to come to the top even if they don't "win" by popularity but is something we want to feature.

Discussion moved to HOW does this change the existing page?

Information at the BOTTOM now needs to be brought up. We need a summary of attributes / metadata that shows up at the top. The Release information and usage project... people scroll down ALL the time to see this part of the page. Metadata section at the top would be good to see what we now typically scroll way down for more readily.

Newcomers don't really understand how to interpret the bug/issue data. Oh wow 200 open issues, that's not good. Does 200 bugs mean that the module is GOOD or BAD?!! More important are being able to search the issues, so just trying to search the issue queue to understand.

By consensus, all we really agreed we need is just a link to the issue queue. More advanced users will appreciate having that once they have the knowledge of how to parse the issue queue to intuit it for their needs.

Reinforcing this idea, from a newcomer: "when I was new and searching for issues... it was a real struggle, I might be understanding something differently because we might understand the same issue two different ways. People need to know how to understand the queue to use that information effectively."

Currently, images are not digestable as a slideshow. Most people agreed that they wanted a carousel (Neil clarified we used to have one, but the module we were using went insecure). Many people coming from other CMSes (Craft, WordPress), said "It's the first thing I look at." I look at the images before I read the description, to help determine if I should even BOTHER reading the description. If I see things that look promising, that's great. It would be even better to make Claro the theme used in the screenshots.

For logo image - maybe better than using a puzzle piece--could use an image that ties to the first chosen category?

Description field, importance:
- WHY should I use this / purpose of the module
- first paragraph should explain the WHY
- one person: personally I like bullet points - high level summary
- keep the sections SHORT
- sometimes there are installation instructions in here... sometimes the instructions are in the README... should the project page / descriptoin / that section use / pull in the project's README
- tabbed interface for different branches/versions??
- maintainers are featured so important at the top of the bar, but the RESOURCES is more important... the maintainers could be moved toward the bottom. we like that it's there, but it's not as important as it's there.
- company sponsors would be tied together. sponsors + maintainers are a similar group of information in the hierarchy
- being able to enhance the corporate sponsors to pull their logo in would be even better!
- depending on audience some people want to see if there are other / related modules. some people don't want it. if that's a section (structured or not) it would be lower. IF we do this, it's important to tell users WHAT'S different or WHY to use something different.

Ecosystem - start to build "suggestions" tab, or perhaps more simply, some indicator like "works with what you have" (for example, if you already have paragraphs installed, we can show that this "works with paragraphs" because it's mentioned in the ecosystem)

Resources section - what are you looking for in there specifically?
- more expansive documentation, either on or off of D.o
- example videos!!
- common FAQ's - better than having to comb the issue queue

There was a question about search -- when searching by name, how do I decide which module should come up first?
- suggest: Relevance, but push popularity as a big factor for relevance. Abandoned can push way DOWN in relevance.

Currently in "release" box... works with shows a composer version constraint. You understand that if you live in composer... is there a way to convert semver constraints to something more human friendly. (Good opportunity to contribute an off-the-island library that translates these things)

A field / checkmark for "works with most recent" or "works with next version" of Drupal (Neil's suggestion). This might be good structured data and would be a good quality indicator.

The search is happening with most relevant, but it's not being highlighted now... so we need to show that or feature it more. Might want to feature the exposed sort and show it elsewhere.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chrisfromredfin created an issue. See original summary.

chrisfromredfin’s picture

Based on this feedback, I've come up with an information hierarchy wireframe here: would welcome any and all discussion on that in this issue, and I can update the wireframe as needed!

https://projects.invisionapp.com/freehand/document/pwOhQ6IFC

leslieg’s picture

Thanks to everyone who attended. Thanks for the very helpful discussion.

chrisfromredfin’s picture

It still looks / works better in the Freehand (you can see the images), but here's a rough sketch in case you're leery of giving them your email. :)

chrisfromredfin’s picture

pvbergen’s picture

Looks great to me, the new order certainly feels more intuitive for site builders.

I want to voice two concerns for this draft:

  • I'm unsure whether we can fit all of the existing release / "works with" info into a sidebar. Maybe we can give general information in the sidebar (works with D9, D10, security advisory) and then still have the existing sections within main content section?
  • Icons are usually hard to make generally understood. Could we still have text links (maybe with icons) to issue queue, repository etc.?
chrisfromredfin’s picture

Thanks, pvbergen!! I totally agree. The fact that i had to do a callout just to explain the icons was more than intuitive. I have updated to put the links next to the icons; that makes a lot more sense to me.

Though I am trying to just represent the importance of information in the hierarchy and not really "wireframe" it - I think we agree that the current meta information is important enough to be toward the top, be it of the column / sidebar OR the main area, wherever it might fit.

With that said, I'm going to iterate on some version of breaking that block down and trying to describe what it could look like in wider or narrower forms, just to move ahead. Thanks!

chrisfromredfin’s picture

I have updated the Freehand with an example / possible implementation of a small table that might represent the metadata in a more concise way.

chrisfromredfin’s picture

Per @rkoller's suggestions, I have moved away from wireframe so we can first get clarity on content priority order first... this actually surfaced a number of things potentially wrong with the layout in the wireframe. Thank you, Ralf!

In order, I believe these to be:
---
Project Name
Branding
Quick Description
Release Information
Screenshots
Documentation & How-To's links (blogs, podcasts, YouTube, docs, etc)
Description
Link to Issue Queue
Maintainers
Sponsors

chrisfromredfin’s picture

Had much discussion with @rkoller in Slack, and have revised the content priority thus:

- The project title doesn't need to appear in the list here, because it will be the H1 / page title. This is more for the content _inside_ the page. So it's been removed, but with the understanding that it's the first thing.

New order:
- Branding
- Quick Description
- Release Information
- Screenshots
==== this ^^ is your "quick glance" eval criteria!!! ====
- longer description
- documentation and how-to's links (official docs, youtube links, external docs, whatever!)
- related modules / ecosystem
- helpful links (issue queue, source code)
- maintainers
- sponsors

chrisfromredfin’s picture

rkoller’s picture

leslieg’s picture

FileSize
64.62 KB
82.9 KB

Where is the Project information section going in the new layout? Categoreis, number of installs, created by, etc.

Examples:

rkoller’s picture

that is in the release information component in #22

leslieg’s picture

i wasn't Sure if the Project Informaitiion and the Releases sections on Drupal.org project pages were being combined into the Release Information section on the new Project Detail page. Doesn't seem like Categories, needs maintainers, etc. fit well there

rkoller’s picture

@chrisfromredfin has combined the two in the invisio mockup he drafted: https://projects.invisionapp.com/freehand/document/pwOhQ6IFC (the column on the right)

and i agree not every information might be necessary or suitable in the new release information section. as suggested in a thread on the drupal slack: https://drupal.slack.com/archives/C01UHB4QG12/p1669821384170479?thread_t... it might be worth a thought to create a detail priority guide based based on one module example (one a long description was already created for).

and there is also one other usability related issue. which module version will be installed. currently there is just a single install button. but sometimes (like in the invisio mockup there is more than one major version of a module available. are those displayed, are they hidden, or how to handle those? that problem reaches into the following issue as well. by which module version a module is sorted? https://www.drupal.org/project/project_browser/issues/3315866#comment-14...

i think having a detailed priority guide, having some discussion would be beneficial. and then there is also the overlap of the long description with the components listed in the priority guide mentioned in https://www.drupal.org/project/project_browser/issues/3322594#comment-14... (point 1)

chrisfromredfin’s picture

It might make sense to closed/fixed this issue and give credit for the BoF, and move discussion over to 3322594.

Re: "more than one major version of a module available" - it's up to composer what it installs, Package Manager essentially gives it the "composer require drupal/project_name" command, with no version constraint. So, it will factor in things like `prefer-stable` and `minimum-stability` with a preference for getting the latest version that it can get away with. (We may need to make that clear in the install UI.)

I will answer the other point (overlap) in the other issue, where it was brought up.

leslieg’s picture

Status: Active » Fixed
Issue tags: +Project Browser Initiative

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.