[Meta] Create a logo for a contrib module

Can one of the requirements be that logos stick to a certain color palette or a few colors approved by the community or maybe something that matches the Olivero theme or the default theme? I'm not a designer but it would be nice to have some consistency when looking at ll the logos. As of right now they are all over the place in term of colors/background/no background. Some designer input and guidance would be appreciated.

@Adrian_S_M That's a nice idea, but many logos are already RTBC, so it would be tricky to introduce at this stage.

Also, module maintainers are responsible for their module logos, so it would be down to module maintainers to adopt a color scheme.

I'm hoping that one day we will allow SVG logos. One thing that SVG logos could do is reference CSS variables. This would make it possible for the admin theme to assign color names, for example a primary and secondary color, and the SVG logos could utilise those. Then if there is a theme change in future, or the site owner picks an alternative admin theme, the project logos could automatically adapt to the new color scheme.

I know there are good reasons for not allowing SVG images for now, but I feel these are no more difficult than filtering HTML input in content fields, so hopefully this can be adopted in future.

Fixed a typo in the issue description. Great tracking issue!

Also late to the party here, but seems like it would have made sense to also provide more detailed guidelines for creating these logos, such as stroke width, solid vs filled iconography, a restricted (in-palette) background / foreground color choices, rounded corners vs hard edges, and maybe most importantly, define a minimum amount of whitespace around the edges of the foreground image vs the background. The whitespace seems a bit all over the place.

Agree with having consistency. I for one dislike seeing a hodge-podge of styles. Maybe something like this could be created to stick onto the ticket once a style has been agreed on?

Think guidelines are great. But in the end it's the maintainer who decides on what the logo will be.

#8 this is the way. Nice job. I thought I saw somewhere in all the logo work to avoid rounded corners, but no idea where I saw that now. Plus it wasnt clear if it was in reference to the background color corners on the box, or rounded strokes/icons for foreground.

You are correct, @jwilson3, there is a note on rounded corners in the documentation page → :

Please note: you should not round the corners in the PNG itself, unless there is some compelling branding reason. We will round corners when displaying in the Project Browser.

This is mainly referring to the logo background, since rounding is applied by the CSS, having rounded corners on the logos would lead to inconsistency.

I like the idea of having style guidelines, but I think the priority when logo work was started was to have logos for the 100 most popular modules.We've gone well beyond this.

Perhaps we could set up a working group to propose a set of style guidelines, either for future logo design, or perhaps people would be interested in revisiting some of the existing logos and reworking to fit the guidelines. However, as @BramDriesen says, it would be up to module maintainers to decide on a project logo.

Please note: you should not round the corners in the PNG itself, unless there is some compelling branding reason. We will round corners when displaying in the Project Browser.

It is worth pointing out that the documentation page → mentions the logo.png from the Project Browser module, which doesn't follow the recommendation to NOT use rounded corners. Needs follow-up?

Good catch, @jwilson3.

The logo in the repo is 328x338 pixels, so it's not even square.

I agree it should be corrected, although I'm not sure what will happen to the logo after Project Browser gets merged into core. We should still have the PB logo as a good example for other modules to follow.

I'll create an issue for it.

I've added the note about rounded corners to this issue. I've also added Inkscape to the list of recommended vector art software, as we should be promoting the use of open source software.

I still feel that creating all the logo's in this issue queue is not the best approach.

• First of all, there is no visibility for the module maintainers that this is something being worked on.
• Secondly, we're RTBC'ing issues here, without maintainer input. What one might like creating/reviewing the logo might not be the taste of the actual maintainer.
• Finally, it doesn't look like really anything is happening after setting a logo to RTBC. There are 144 RTBC issues linked to this meta issue (at the time of posting this comment)...

I would suggest creating the issues in their respective issue queue, and link to this meta. The only thing you will lose is the ability to filter in a single project for all logo suggestions. But that can still be done from the all issues view if you would leverage a proper tag or naming convention.

As a project maintainer, I ended up just switching the issue from Project Browser to the contrib module, in order to get an MR, and then switched it back to this issue queue, so it could be marked fixed. The problem with creating new issues in the respective project queues is that ultimately its going to be a lot more duplicate work to re-upload images, copy over instructions for maintainers, copy over issue credits, etc.

The detailed steps I followed for a module I maintain:

• Create the logo issue in this project's queue.
• Once a logo is settled and RTBC in this queue, move to the respective project's issue by making the following changes:
  • Select the project name from the Project typeahead. This is required in order to create an MR (see below).
  • Specify the project's latest stable branch.
  • Change status from "RTBC" to "Active".
  • Add a tag Project Browser Logo →
• Click "Create issue fork" button and create an MR against the correct project (this cannot be done while the issue belongs to the Project Browser issue queue!)
• Clone MR locally; add logo file to codebase; make a commit; and push to MR.
• Change status back to "RTBC" and ping maintainer via contact form.
• TBD: Once maintainer reviews/merges/marks "Fixed", switch the issue back to this issue queue. (Is this actually necessary?)

The problem with creating new issues in the respective project queues is that ultimately its going to be a lot more duplicate work to re-upload images, copy over instructions for maintainers, copy over issue credits, etc.

Hence why I'm saying the issue should be created in the real project issue queue from the start and not here. I'm not talking about new issues.

Once maintainer reviews/merges/marks "Fixed", switch the issue back to this issue queue. (Is this actually necessary?)

And here is my issue, people are doing so much work without the maintainer input. If the work would be moved into their project queue, they have a view on it and comment early. Before someone has to go through all that trouble, and then after that again.

I think @BramDriesen makes a very good point.
If logos are created as a child of this issue, they are visible in the sidebar here, so designers can easily pick them up to work on them.
Creating them in the target project rather Project Browser means the project maintainers have visibility of the logo design process and can engage with it if they wish.
It also makes it easy to turn the accepted logo into a merge request.
It might make it easier to get project maintainers to accept logos as they will have seen the creation process and may have contributed to it.
It would also reduce the number of issues in the Project Browser queue.

I'll do some issue triage and cleanup in the referenced issues here as well, as there many set to RTBC which could be set to fixed.

Mentioning an easier-to-use PNG minimizer alternative.

With these logos it will be so easy to find a list of installed contrib modules on any Drupal site.

Would it makes sense for the logo creator or other contributor to see if a logo or logo creation issue already exists for the corresponding project? Or was this already done?

Pasting from Slack:

If I want to mentor an intern to create project icons/logos, how should I help in that effort? How do I choose which projects? How do I communicate we are working on those? Etc

@tekNorah said she'd try to help get this organized ❤️

Fyi, I'm going to pick a few projects for logo/icon work right now and double-check them against the issues to make sure they haven't already been done and then I'll make child issues.

I went through the top 250 Drupal 10 compatible projects and:

1. Check if there was already a child issue here and, if not
2. Tried to remember to check if it was marked obsolete or not (may have missed that on some) and, if not
3. Created logo issue with instructions and linked to project

I've added 116 child issues. Example:

📌 Create logo for jQuery UI Selectable for Project Browser Initiative Needs work

I'll work with my kids on doing some of these (already started).

I have moved or closed all the non-top-100 logo issues I created. For the closed ones, I removed this issue as the parent so it won't show up in the sidebar.

Quite a few modules that are not in the top 100 still have this meta issue as their parent. But the link back here is still useful, therefore they can be changed to 'refer' to this issue instead, and not have it set as 'parent'

Updated the issue summary to include a hint about testing the logo files locally before committing.