Provide brief summaries about each category

Created on 2 July 2022, over 2 years ago
Updated 31 May 2023, over 1 year ago

Problem/Motivation

Imagine you are a new user using Project Browser the first time and you are unfamiliar with the list of available categories and Drupal in general. There are two scenarios:

As a sighted user:
You select a single category for example Decoupled. You then get the list of modules returned starting with the one with the most installs REST UI. Me as a sighted user had based on the category an assumption what kind of search results to expect. That assumption got validated.
But in contrast if you select instead of something explicit like Decoupled something like Third Party Integration it isnt that clear upfront what to expect. Could i expect an integration for an external third party service or api? The first result Google Analytics makes sense but in contrast Colorbox I wouldn't have expected at all. Same for Simple XML sitemap or Slick Carousel? The gist what the category is about is still not that clear to me. Then there is the example of the category Novelty. The only guess about the meaning of the category is it contains brand new modules? But when i take a look at the modules provided in the initial search result i am unable to find a common thread. There are a few brand new but also some from 2018? Functionwise there isn't no real affinity also. Me as a user have a hard time how to handle and categorize" that category. Then you have wastebasket taxonomies like Other and Utility. Both way too broad und unspecific - Other in particular. Most categories are more or less clear after some playing around, but a few provide even after some investigation still some head scratching.

As a screenreader user:
For screenreader users it is even more challenging to orient and find their way through the categories and their meaning. As a screenreader user new to Drupal you also first have select a single category. You also have an assumption about the meaning and purpose behind a category. then you have to aurally scan through the initially returned modules for the selected category. In contrast to sighted users you have to rely onto your memory entirely. If the working memory is small that task could become even more challenging. So on the first usage, if you want to be able to search specifically later on, you have to work through each category and validate your assumptions ideally. A cumbersome, time and memory intensive task.

Proposed resolution

- Create brief one line easy to comprehend summaries about the gist and meaning of each category.
- For the categories list in the sidebar add a visually-hidden span at the end inside of each label element. That way screenreader users would have the option to revisit the summary what a category they gonna select is about if necessary. Either because they use Drupal the first time or because they simply forgot - it is optional. By front-loading using the pattern Category name: summary the most important information is at the begining and the user is able to jump off at any time skipping the optional summary.
- Between the filters component and the search results (the module cards) underneath the category name plus the summary could be added for sighted users as well. That way you get an explanation what the category and the search results are about. The only problem here is how to handle the case if two or three categories are selected in the sidebar? I am not sure about that. Only show the title and summary if a single category is selected or show the title and summaries nevertheless for all categories selected? Or would there be another option that comes to mind?

Remaining tasks

  • โœ… File an issue about this project
  • โ˜ Manual Testing
  • โ˜ Code Review
  • โ˜ Accessibility Review
  • โ˜ Automated tests needed/written?
โœจ Feature request
Status

Active

Version

1.0

Component

Drupal.org changes

Created by

๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States chrisfromredfin Portland, Maine
  • Status changed to Fixed 4 months ago
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

    That link to d.o fixes only one out of the three points listed in the proposed resolution. :/ Plus it is suboptimal if you have to leave your site and the pb search ui to look up the meaning of a category on a different site

  • Status changed to Needs work 4 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States chrisfromredfin Portland, Maine

    Doh! I got overzealous.

  • ๐Ÿ‡ฎ๐Ÿ‡ชIreland lostcarpark

    Agree 100% that this is needed.

    I think the first part has been completed as part of the category revamp, and the new categories have descriptions.

    I'm not sure if the descriptions are currently fed to the Project Browser UI.

    I think we need some way of accessing those descriptions in the UI. I think a visually hidden element for each label could solve it for screen readers. For non-screen reader users, we need to come up with a UI mechanism. They're a bit old-fashioned, but would tooltips work?

    This would probably need to be a separate issue, but I think the descriptions should also be displayed to module maintainers when setting categories for their modules. I don't think we can expect module maintainers to go searching for category descriptions unless they are put in their eyeline when selecting the module categories.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia prashant.c Dharamshala

    The description/summary about the categories on hover or click would be a very helpful thing not only to new users but also to developers, and site builders as well.

  • Assigned to lostcarpark
  • ๐Ÿ‡ฎ๐Ÿ‡ชIreland lostcarpark

    I've started working on this. At the moment I just have it fetching the descriptions with the categories and adding to a span after the category labels. I plan to visually hide this so they'll still be available to screen readers, and I should be able to use that as the basis for providing tooltips.

  • Pipeline finished with Failed
    4 months ago
    Total: 487s
    #246412
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

    the downside of tooltips is that a sighted user has to hover over the category title which is not necessarily expected for a list of categories to get the category descriptions there. how about making category titles directly visible instead? with nothing searched yet one option might be making the category descriptions part of the project browser "start page" as outlined in โœจ Show curated content and links on the start page Instead of results without a search query being entered beforehand Active . each tile could provide the information about the category and quick refresher, as well as function as a link triggering an initial filtering of the project list without a search term entered, so the user gets all the modules associated with for example the accessibility category.

  • Pipeline finished with Failed
    3 months ago
    Total: 414s
    #260609
  • Pipeline finished with Failed
    3 months ago
    Total: 421s
    #260631
  • Pipeline finished with Failed
    3 months ago
    Total: 507s
    #260644
  • Pipeline finished with Running
    3 months ago
    #260665
  • Pipeline finished with Failed
    3 months ago
    Total: 517s
    #260689
  • Pipeline finished with Failed
    3 months ago
    Total: 599s
    #260697
  • ๐Ÿ‡ฎ๐Ÿ‡ชIreland lostcarpark

    I have been working on a basic category tooltip.

    I have the following working:

    • The JSON API fetches the category descriptions as well as the titles.
    • An additional span is placed inside the label containing the description. This is visually hidden so it will only be visible to screen readers.
    • I've added a mouseover event to the checkbox and the title to show the tooltip.
    • I've also added a focus event to the checkbox to show the tooltip, so moving over the checkboxes with the keyboard will cause the tooltips to be shown.

    Some areas need work.

    • I'm having some trouble getting the tests working. I think part of the problem is tests that check for the text of a category title are getting thrown by the extra element in the label. I think a possible fix would be to move the category title into a span (so the label would contain two child spans, one for the title, and another for the description). That should make it easier to isolate the title element.
    • It would be nice if the tooltip appeared after a short delay, so it didn't show when moving over quickly, just when hovering.
    • Moving the mouse over the categories quickly can result in more than one tooltip showing.
    • Moving the mouse quickly produces some unsightly flickering as descriptions appear and are hidden.
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia prashant.c Dharamshala

    I also gave it a try, worked smoothly, and majorly the points mentioned in #21 in Some areas need work.are the major things(mostly usability).

    We could also consider to show it by:

    • Displaying an (i) icon against each category name and showing the tooltip on hovering that only
    • Showing the tooltip the way we are currently trying to show but show it to the right side so that the options below and above the hover option are not hidden

    Thanks!

  • ๐Ÿ‡ช๐Ÿ‡ธSpain fjgarlin

    We don't seem to be testing this via PHPUnit/nightwatch (which might be fine), but note that we we want to test descriptions/tooltips, we might need to alter the fixtures used (so the real API endpoint is not queried for testing):
    - https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/tests/fi...
    - https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/tests/fi...

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States leslieg

    Is this RTBC and @fjgarlin didn't mark it or does it still need work?

  • ๐Ÿ‡ช๐Ÿ‡ธSpain fjgarlin

    Iโ€™d say still โ€œneeds workโ€ as there are actions/feedback not addressed yet.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States pfrilling Minster, OH

    The markup is changing in https://www.drupal.org/project/project_browser/issues/3485747 ๐Ÿ› The multi-category filter needs to be an actual set of labeled checkboxes Active . This will likely need a rebase once that fix lands.

Production build 0.71.5 2024