The goal is to establish consistent applications of the brand and provide clear guidance to create lockups for various relationships.
In visual lockups, Mozilla may be positioned above (leading) or below (supporting).
This is used on early-stage products, projects, initiatives, partnerships and open standards Mozilla has created or is contributing to (unless they have their own brand). We want these to get as much awareness as possible, while still clearly connected to the Mozilla brand. The relative size and spacing can imply the strength of the relationship. If we are one of several contributors to an open standard, for example, there may be extra space between the name and the Mozilla logo, and/or the logo could be smaller than the standard lockup.
This is used for teams within the organization, internal products, communities, events and other opportunities where the item in question is clearly a part of Mozilla. The type beneath the logo is set in ZillaSlabRegularHighlight, all lowercase. The supporting type gets the same x-height as the logo, which means the surrounding highlight is the same size as the box around the logo. There are no spaces added before or after the type.
The structure of the lockups is modular and can almost be treated as responsive. Depending on available space, longer names could be on one line or broken into two.
Here you can see the flexibility applied to the CCADB logo. CCADB (Common Certificate Authority Database) is a long name, one mostly used by people who already know what it stands for. By providing a few options, it can be applied in the most sensible manner to different parts of the UI. The longer version lives on the login page to make sure people are oriented, but the smaller version is in the header after the user has logged in. This takes up less space while maintaining clear branding.
No “qualifying” language in the lockup
Lockups should never include qualifying language, like “supported by,” “by,” “from,” “in partnership with” or similar. The logo placement below the name shows that Mozilla is supporting the project. If there is a need to distance Mozilla further, it can be done as described in the “Logo below” section, where extra space or a smaller sized logo is used.
Qualifying language for a project should be used only in copy, when the name of the project is written out, not in the naming lockup.
We should not rush to strip the Mozilla name off projects where others are involved simply because others are contributing. Part of what Mozilla stands for is being open, for the benefit of all. We should work toward an understanding that if you see the Mozilla logo on a project, it doesn’t preclude us working with others or inviting collaboration.
Expressing taxonomy in copy
Ordered from strongest to weakest relationship to the Mozilla brand
1. Mozilla _______
Used for a tool, service, resource or other asset either created by Mozilla or where we are trying to establish the strongest relationship with Mozilla. In this case, our logo goes above the lockup.
2. _______ by Mozilla
Used for product, tool, service, resource or other asset either created by Mozilla or where we are still trying to establish the strongest relationship with Mozilla, but where the other name gets top billing. In this case, our logo goes below the lockup.
3. In collaboration with [partner]
Used for media/editorial collaborations only and always in combination with either number 1 or 2 above. In situations where we partnered with another organization, team or agency and want to credit their contribution without diminishing our own brand's importance, we can say "_______ by Mozilla, and in collaboration with [partner]."
4. _______ from Mozilla
For a product, tool, service, resource or other asset being given (or given away) by Mozilla and where we are trying to establish a relationship with the Mozilla brand. An example might be a piece of technology we are hoping to evolve into an open standard, such as "emscripten, from Mozilla."
5. _______ a Mozilla product
For a product, app or service that needs more independence than provided by previous options, such as “Firefox, a Mozilla product.” Acquisitions are another prime candidates to request this treatment, such as “Pocket, a Mozilla product.”
6. _______ supported by Mozilla
This can be used for media partnerships, such as the grants we are making with teams or agencies who are doing much of the work.
This is also available for very limited use for a product, tool, service, resource or other asset that was created by Mozilla alone or by Mozilla with contribution from other parties who are particularly sensitive to sounding like it ONLY comes from Mozilla, but where we are still trying to establish a relationship with the Mozilla brand. This is not preferred.
7. In partnership with Mozilla
For a product, tool, service, resource or other asset that was created by Mozilla alone or by Mozilla with contribution from other parties who are VERY sensitive to sounding like it ONLY comes from Mozilla, but where we are still trying to establish a relationship with the Mozilla brand.
8. With help from Mozilla
(or) In collaboration with Mozilla
EFor editorial partnerships where we participate in or fund the creation of a piece of content, but especially where the partner has a great deal of editorial input or control. Examples would be previous work we've done with groups such as Nowness and UpWorthy.