"add-ons" vs. "recipes"

@ultimike fair question!

We don't want to use the term 'Recipes' in the UI at all, but ended up with that one instance because of some late changes in PB that we were unable to override. It's a Drupal-specific term that is meaningful in terms of the technical implementation, but end users should/will not care what is under the hood. Rather than going all in on the term just because of this one instance, we decided to try to hold the line, even though it means some inconsistency in this first iteration.

Ideally in future we can group ALL add-ons to Drupal under one umbrella and users won't know whats a recipe vs a module (vs whatever else we come up with in the meantime). They're all just things that extend your site. The fewer Drupalisms users need to learn, the easier it is to adopt! Or so we hope...

@pameeela - thanks for the quick response. I understand the reasoning, but for some reason, something doesn't sit right with me. I think that if I put myself in the shoes of someone new to Drupal, and I click on something that indicates I'm going to see some 'add-ons' and then I arrive at the page where I don't see that word, it might be disorienting.

Anyway, I totally get it from the fact that things are moving fast, and there's bound to be some inconsistencies as well as some additional evolution. From a teaching/learning standpoint, I find great value in consistency.

thanks,
-mike

I argued against re-using the term recipes in the early days of the Distribution Modernization Initiative. I conceded in part because very few current Drupal developers knew about/remembered drush recipes, but also because the word "recipe" described what these were to novice users as well as how they were different from modules AND implied that they are designed to be mixed and altered at the same time.

The name worked on many levels.

Renaming recipes as add-ons is misguided unless the goal is to prevent Drupal CMS users from being able to use Drupal.org documentation to learn more about Drupal.

Because add-ons really have to no meaning in Drupal, this is the top result when someone searches "Drupal Add-ons"

https://www.drupal.org/node/1990588 →

Vs the useful information you find when searching "drupal recipies".

Is there any data that shows users find add-ons more descriptive?

Well, as I said, this is decidedly a sub-optimal state where things are not yet consistent. But for me, the ideal scenario would be that a user doesn't have to Google a term they see in the UI to figure out what it means.

"Add on" is a common term with a widely understood meaning, and it is our hypothesis that this will be more meaningful to new users than "recipe" based on this alone. And again as I said, we are not "renaming" recipes, we are trying to normalise the user-facing language in the UI.

We will be conducting user testing soon and absolutely plan to test this. For my part, I would be quite shocked if non-technical users were confused by the term add-on because they wanted to understand functionally what it was. And I would also be shocked if the prompt 'Choose recommended recipes' even registered as something they would want to do, having no clue what it meant in this context.

Having said all of this, there is of course a chance we are wrong. But we are making these calls to align with not only the Drupal CMS strategy to make Drupal more accessible to non-technical users but also the de-jargoning Drupal → work that is being done by folks on the UX side.

I didn't think a user would search for what the term Add-ons meant as much as what Add-ons are available WITHOUT having to do that within a Drupal CMS instance. That seems like a pretty reasonable scenario

I don't think the issue is confusing users while adding functionality within a Drupal instance. I'm sure Add-ons will test fine in that scenario.

I think the issue that isn't "sitting right" with @ultimike is consistency in how we describe the building blocks of a Drupal configuration.

I completely agree that referring to the feature a CMS user is browsing to add to their sites "projects" isn't ideal. The module, recipe or theme is created and maintained as a project. Project makes sense in that context as the creation and maintenance = work, but you don't want to imply to users enabling a module that there will be work.

The Salesforce version of Project Browser is now called AppExchange. There used to be Marketplace for closed source, commercially supported packages and Open Commons for free, open source packages, but the packages are now combined in AppExchange. You can now find an open source package like Education Data Architecture, Summit Events App maintained by staff at the University of St. Thomas and ascend Advancement Suite which requires a license. The UI users use to browse Managed Packages is very consistent regardless of whether happens through the website or in the CRM.

In CU's D7 install profile, we had our own version of Project Browser and called the combination of Features and Modules we allowed Site Owners to enable Bundles. I completely understand that using terms like projects, modules and recipes is meaningless to some site-building communities, but in our case we were using bundles to hide which modules were used from our users. In our SaaS offering, we did not want users trying to find support on Drupal.org directly since so many of the options were preconfigured and locked down.

It really goes against the "come for the code, stay for the community" ethos if we use different terms for users vs. contributors, but the more I think about this the less I see the use of Add-ons in the Drupal CMS profiles as the problem.

One potential solution to the consistency problem actually solves a few other problems is to replace the dated Downloads top level nav on Drupal.org. with Add-ons. Implying that someone should download Drupal core or even a module in 2025 is unnecessarily confusing.

With D7 fully EoL and #3277250: Distribution packaging sunset in November 2022 → complete, I'd push to remove Distributions. At some point we lost the link to Downloads > General Projects → which is the project type being used to create and maintain Recipes. The General project type was originally created for js projects like https://www.drupal.org/project/drupal_js → that didn't require the GPL inheritance like a derivative module or theme, but is now being used for many things... including the Drupal CMS. Creating a new project type specifically for Recipes would be a lift, but adding a field and filter to separate the General projects by Recipe, Javascript or Install Profile type would be relatively easy.

We'd also need to address the Download > Download link that is Drupal core, but that is already happening with the Try links. I think everyone who has been involved in the evolution of install profiles > distributions > install profiles + recipes agrees that we took install profiles too far in D7 and understands the technical reasons why https://www.drupal.org/project/cms → was created as a General Project.

@ultimike If the top level Drupal.org nav was updated to...

• Add-ons
• Modules
• Themes
• Recipes
• Javascript

... and we continued to describe the different types of Add-ons the way it already is in https://new.drupal.org/node/10000037, would that address your consistency concerns?

Heh - I think the discussion here has outgrown the title of the issue 😂

Anyway, @kreynen, your hierarchy makes sense.

-mike

There is no mention of the "Add-on" term in the Drupal CMS documentation: https://new.drupal.org/docs/drupal-cms .

We are already using term "Extend", so probably something like "Extend the site functionality", or something like this would be much better, until the term "Add-on" is widely used in Drupal CMS/Drupal core. Otherwise I agree that it has potential to create confusion.

@pameeela's instincts are on point - apparently the research agrees with her: 📌 Test user understanding of the difference between Modules and Recipes Active

To be very clear: that is not the issue for bikeshedding a new name for extensions (including modules and recipes). It's just about doing the research to find where the disconnect is, and how to improve it. But if you have insights that might help that cause, I think that issue is probably the place to talk about it.

We will continue to use "modules" when we talk about modules? Will we use the word "contrib"? Or we just move to generic "Addons". Will we talk about "Core modules"