Improve and clarify the microcopy for the search field placeholder

Tested using MR!320 latest.
The Placeholder text now changed to 'Enter Module name here' and is visible in the search filed

Testing Steps
- go to /admin/modules/browse
- take a look at the search field placeholder text before you enter anything

Keeping this in review state for approval

Hello! I'm looking at this during Florida DrupalCamp 2024, and freshly installed Project Browser with the MR applied. The placeholder text appears as expected, both in the visual output of the search field and in the DOM as a placeholder attribute. Screenshot attached of the visual output.

Going to mark this as RTBC. Thanks!

I think we need to hold off on pushing this through, due to the nature of what's being searched *right now* versus what's going to be searched when there's a real Search API-backed instance running. "Module name" is good with the current mock situation, but we need to think about what this text should *actually* be against the live backend, and that we don't quite know yet.

Though, I anticipate it would be project name & project description (title & body) at a minimum.

I might suggest just "Keyword(s)..." as the placeholder, but I'm curious if that makes sense given what other folks do, and what some UI people think.

Moving back to NW. With the real d.o backend up and running - we're searching and finding based on the Elasticsearch config at d.o - what should this keyword filter be for microcopy?

I suggest "Keyword(s)..." - but I would like consensus on something, then this is an easy/novice issue to work on.

Using "Enter Module name here" is technical and not something that our target audience would necessarily understand.

After discussing with Chris, I suggest keeping it simple and using a few examples as the placeholder.. (e.g. image gallery, spam protection) to give users an idea of how it can be used.

Also suggest that we change the label from "Search for modules" to just "Search " as it can now search for recipes and eventually themes, etc.

already asked over on slack, but what would be the elements that are queried and or could be queried with elastic search? the title, the body field, anything else? guess that list of elements should inform the decision how to label things.

Screenshots of the current Search API index configuration are attached. Only title has a bump of 8, rest 1. No other custom code is written anywhere.

Deciphering this, it's CURRENTLY

• Title (weight/boost 8)
• Body (weight/boost 1)
• Categories (weight/boost 1)

Should we change version to 2.0.x here?

After discussion with Chris, moving it to 2.0.x

As we now have a list of elements that can be queried, can we decide on naming the placeholder, keeping recipes and future themes in mind?

I would recommend the label become "Search" and the placeholder be examples of what to search for, like Leslie suggests. I propose something close to "(e.g. image gallery, spam protection, Gin theme)" - I'm not sure that we can/should be promoting a particular theme in that way, however, it's really great because there are also modules that work with Gin today so that the example is relevant even before there is a theme browser.

If people can throw a few ideas around, or just +1 this one, I think we can just decide (it can always be changed later).

Good suggestion up there, but I would not put anything "theme" related as we are only looking for modules (https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...) in the default plugin.

Re #20, I think placeholder text should change based on plugin or it should be such that it applies to all plugins.

big +1 for the point made in #20 📌 Improve and clarify the microcopy for the search field placeholder Needs review by @fjgarlin (and alsothank you for the search api index configuration screenshots in #14 📌 Improve and clarify the microcopy for the search field placeholder Needs review ).

in regards of the suggestion in #19 📌 Improve and clarify the microcopy for the search field placeholder Needs review , I am uncertain whether it makes sense to provide a few module names as examples. that way a user would ask the same question i've asked in #13 📌 Improve and clarify the microcopy for the search field placeholder Needs review , what is actually searched in. to provide some sort of "inspiration" and priming to the user i guess something like ✨ Show curated content and links on the start page Instead of results without a search query being entered beforehand Active might be the more impactful approach?

For this issue it might be good to illustrate the current aural interface for the search field (search.mp4) and the downsides of placeholder text have also be noted ( see https://www.smashingmagazine.com/2018/06/placeholder-attribute/). Two suggestions come to my mind for now:

• go with the suggestion from chris in #19 📌 Improve and clarify the microcopy for the search field placeholder Needs review using Search as the label, but instead of providing a list of module suggestions tell the user what is actually searched. so the placeholder text would state something like "...the module description and title on drupal.org" . that way the input field label and placeholder complement each other and get announced in one single sentence in the aural interface as an additional plus?
• "simply" drop the placeholder and just go with the label for the input field.

Will think of more options, and run it by the other in the drupalisms group as well as the ux group. but as chris said the label and the placeholder are not set in stone and could still changed in a followup.

I don't want to have to change code if we change d.o's mechanism for indexing. I think it needs to be more generic, and providing examples of things to type in to search for is a good way around that. To that end, I say we just do "spam protection, image gallery" and scrap the theme. if we'd rather, we can change one of those examples to an actual module name, like "recaptcha, image gallery" or add it "spam protection, image gallery, Google Tag" or something.

I have updated the placeholder and label according to the discussion on the issue.But i still think @narendrar made a valid point in #20 📌 Improve and clarify the microcopy for the search field placeholder Needs review that we should consider the recipes as well as the search component is generic.I'll mark this NR for another round of review.

Changes seem in line with comment #23, hence marking it as RTBC.

Sorry, I've taken a look at the latest state of the MR, the placeholder text in the current form is not helpful at all. For contrib modules the placeholder text tells the following: as a person new to drupal, it tells me nothing at all. i dont know what field group mean and recaptcha also doesnt ring a bell, i only know there are captchas on the web. as a person experienced with drupal, it tells me ah i am able to search for module names and nothing else but module names in this field. and searching for either recaptcha or field group in recipes provides me zero results, same for the core modules.

I wonder if we are overthinking this.

I think most people know what to do when presented with a search query box. It's the commonest of patterns. You enter some text there, it finds stuff that matches. I don't think they need to know that it searches module names, descriptions, whatever. That's the job of the app to figure out.

So IMHO there need not be any placeholder text at all. I think this might be a case where trying to be too helpful will actually be less helpful.

Oof, yes, overthink. I thought placeholder text was a "recommended" pattern but actually if it's not adding clarity, yes, just boot it and leave it "Search" as the label. That solves it across every plugin. Thanks for the light, @phenaproxima - sometimes we need to be reminded we're too deep in the weeds, but we're too deep in the weeds to see out.

Removed the placeholder.Ready for review

Looks okay to me!

Wonderful! A bigger victory than the code suggests. :)

Meanwhile, we have to find a way to not bikeshed language decisions. But, this works! When in doubt, make it more minimal.

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