• width/height is dependent on clarifying the questions on parent task and identifying needs in design.

• For whitespace, we should minimize it as much as possible and add it via CSS where needed, that provides us best flexibility and lowest image data.

• Color/opacity requirements are mostly about guiding designers/implementors on what they are allowed to use. Wordmarks are all greyscale, for improved anti-aliasing they will be produced as RGB SVGs and 24bit PNG fallbacks.

• Currently logos are in 1x, 1.5x and 2x resolution. With increasing device dpi even 2x can already result in relatively blurry appearance. We have several options here:
  • trying to revisit globe as SVG, @Jdrewniak started an initiative a while ago and see if we could come up with a modified, optimized SVG that fulfills data limit needs
  • leave globe as 1x/1.5x/2x PNG, but connect it with SVG typo underneath. That would also provide us with one SVG for usages of wordmark only in other places than header or in a responsive mode

We should consider re-evaluating 1.5x, from my experience that could be technically outdated and not provide us a lot.

No idea how much the world/communities out there is also an audience for any guidelines to be created. If communities are an audience, then https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Change_the_logo_of_a_Wikimedia_wiki welcomes a check / updates.

Mentioned tasks above have to be taken into consideration when updating the logos and defining future guidelines.

@Volker_E @Jdlrobson @ovasileva here's where I'm at so far:

Depending on how much we want to anchor on the Wikipedia use-case specifically it might make more sense to go with a 2 part system rather than 3 parts (see image below). Most of the other project logos make more sense in 2 parts, plus I think in general it's more common to have [icon] [text].

Regarding trying to make things fit to a general guideline we try for something like:
[icon] = 40px tall (or shorter), and no more than 60px wide
[text] = 32px tall (or shorter), vertically center aligned with icon (4px - or more - padding above & below)
spacing between [icon] and [text] = 10px

Regarding how the horizontal logo layout look on some other projects here are a few examples:

Wikipedia
Wiktionary
Wikiversity
Commons
Wikidata

@alexhollender - one issue with a 2 part system is that we won't be able to use the same wordmark for mobile (because of the tagline)

moving this to doing since it seems like work has already started - since it's mostly a design focused task, I'm not sure if we need to estimate

@alexhollender @ovasileva And what about using the 3 part system making parts optional? The guideline could specify that, if a tagline is not configured, the wordmark should be vertically centered. Then it would be up to the skin implementing when the wordmark should be displayed alone and when with the tagline bellow.

In T245190#5922964, @ovasileva wrote:

@alexhollender - one issue with a 2 part system is that we won't be able to use the same wordmark for mobile (because of the tagline)

"The free encyclopedia" is going to be the trickiest part here because of the i18n requirements. I wonder if that could be broken out into a 3rd logo called "tagline" or done using text overlayed across the image?

As Olga alludes to here if we used the same wordmark on mobile this gives us one less logo to worry about during project logo changes and is much easier to maintain.

PS. We'd also need logos for wikibooks, mediawiki, wikinews, metawiki, wikimedia incubator, wikimedia cloud services and Wikimedia Foundation but maybe you missed those out intentionally?

@alexhollender This is great!
My vote with all information given goes to a 3-parts system, which might be more work in the beginning, but provides us most freedom long-term.

What I've shared with Alex in our 1:1 is that we're not yet providing SVGs on desktop at all, which we should enforce.

Alright, a bit more information after a broader investigation today.

To begin with, I'm aiming for the display size of the wordmark + tagline on the updated Vector header to match their current size in Vector (which already roughly matches the size in Minerva.)

The dimensions and spacing of the wordmark + tagline are more varied than I thought initially. Judging by the SVGs here (which are exact matches to the PNGs used in production), there is a range in wordmark + tagline height from 52px to 36px. To accommodate this range we could use a globe at 44px. We could reduce the number of variations (e.g. just have 52, 48, 44, 40, 36, or even less) but this would require us to make some minor adjustments to the sizes of certain wordmarks and/or taglines.

Some wordmark + taglines currently are overlapping by 1px. Again we could modify the spacing so that this isn't the case, though I would just want to first check to understand if it's an intentional overlap.

Mobile and desktop wordmarks are currently inconsistent. There is a range of how inconsistent they are. If we intend to use the same wordmark SVG for mobile and desktop, we'd need to choose which size to anchor on because it will affect the sizing and spacing of the respective tagline.

We should settle on either width or height guideline and the other property is flexible. In our proposed layout it seems height should be fixed value, as we have horizontal flexibility in the layout, but not so much in vertical flexibility.

Met with @Jdlrobson and @Volker_E today to review further. I've put together some examples of how we could render the logos for Wikipedia and other projects using 2-3 separate images (depending on the project), and not much CSS (thanks flexbox): https://di-logo-sandbox.firebaseapp.com/

1. logo
2. wordmark
3. (optional) tagline

Regarding the requirements, I think we can figure this out a bit later, but it could maybe be something like:

1. logo — should be an SVG or PNG on a canvas that is 44px tall. For circular shapes (e.g. wikipedia globe) you can fill the entire 44px height, for squares (e.g. wikiversity icon) 40px with 2px on top and bottom, horizontal rectangles (e.g. wikidata icon) 38px with 4px on top and bottom
2. wordmark — this is dependent on whether or not there is a tagline.
   • if there is a tagline, height should be between 30–18px, with a width no more than 120px
   • if there is no tagline, height should be between 52–36, with a width no more than 120px
3. taglline – height should be between 10–18px, with a width no more than 120px

@Volker_E @Jdlrobson here are a bunch of SVGs to start with:

Wikipedia

Here are all the files above as a .zip (for easier download):

Other projects

project	icon (svg)	icon (png)	wordmark	tagline	wordmark height (mobile)
Wiktionary (French)	wikitionary-logo.svg36 KBDownload		wikitionary-wordmark-fr.svg13 KBDownload	wikitionary-tagline-fr.svg19 KBDownload	18px
Wikiversity (Portuguese)	wikiversity-logo.svg4 KBDownload		wikiversity-wordmark-pt.svg6 KBDownload	(na)	14px
Wikimedia (Office)	wikimedia-logo.svg2 KBDownload		wikimedia-office-wordmark.svg6 KBDownload	(na)	22px

@alexhollender One more question for shared understanding:
For “2. wordmark — this is dependent on whether or not there is a tagline”
I assumed from our conversation, that we're setting on a strict height and the width is flexible as… T245190#5934226
What made you fix the width, could you probably share a descriptive layout image of context with the flexible/fix ranges?

In T245190#5939475, @Volker_E wrote:

@alexhollender One more question for shared understanding:
For “2. wordmark — this is dependent on whether or not there is a tagline”
I assumed from our conversation, that we're setting on a strict height and the width is flexible as… T245190#5934226
What made you fix the width, could you probably share a descriptive layout image of context with the flexible/fix ranges?

I'm not sure I understand what you're asking for. The width is not fixed, but there should probably be a max-width in the guidelines. Judging by the current logos the height would have to be a range. We could investigate standardizing the height but from the initial investigation it seems complicated and I think the variation is necessary to get the logos to display at a size that looks consistent to the eye.

Moving to blocked until we know more about the exact strategy for T246170: Build new logo for Desktop Improvements Header. We can continue with the guidelines based on that.

T245190#5942228 is already great. For a systemic guideline we additionally need to provide not only a range, but best-practice and do/don'ts, for example for major script families like Latin, CJK etc. Concern here, that we might otherwise end up with tagline in German of 10px height and the one in Latin 18px.

@alexhollender To get back to the Farsi example above, what would be the harmonized version then?

In T245190#5945782, @Volker_E wrote:

@alexhollender To get back to the Farsi example above, what would be the harmonized version then?

I think it would be this:

Note: I adjusted the proposed guideline above, in the case where there is a tagline the wordmark height should be between 18–32px, in the case where there is no tagline the wordmark height should be between 36–54px.

For whitespace, we should minimize it as much as possible and add it via CSS where needed, that provides us best flexibility and lowest image data.

I would like to challenge this. From experience I know that whitespace does have close to zero effect on the file size (assuming .png and .svg). Positioning via CSS is also not harder when an image does have baked-in whitespace. Especially when the whitespace is required anyway, and the image will never be used without it. We have CSS properties like background-size to easily scale and position images.

Baked-in whitespace makes it so much easier to use a logo correctly, without accidentially forgetting about the whitespace, or with different whitespace every time. And yea, people will download and use the optimized versions they get with a page, instead of searching for an "original".

Hey all. I explored how this might look in code.

Two questions:

1. Is it viable for the logo asset to always be a fixed width square e.g. 40x40 and make use of whitespace inside the SVG or do we need to make width and height configurable?
2. Is using the alt text a suitable fallback for older browsers? (no JavaScript/no SVG support)

$wgLogos = [
       // No width and height properties needed if we can agree on a width and height and assume the logo is a square.
        'icon' => 'https://di-logo-sandbox.firebaseapp.com/img/globe.png',
        'tagline' => [
                'alt' => 'the free encyclopedia',
                'src' => 'https://di-logo-sandbox.firebaseapp.com/img/tagline/en-tagline-117-13.svg',
                'width' => 117,
                'height' => 13,

// if needed for the logo e.g. Burmese Wikipedia
'offset' => 0
        ],
// shared with mobile site
        'wordmark' => [
                'src' => 'https://en.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-en.svg',
                'width' => 116,
                'height' => 18,
        ],
// for legacy
        '1x' => 'https://en.wikipedia.org/static/images/project-logos/enwiki.png',
];

In T245190#5949351, @thiemowmde wrote:

For whitespace, we should minimize it as much as possible and add it via CSS where needed, that provides us best flexibility and lowest image data.

I would like to challenge this. From experience I know that whitespace does have close to zero effect on the file size (assuming .png and .svg). Positioning via CSS is also not harder when an image does have baked-in whitespace. Especially when the whitespace is required anyway, and the image will never be used without it. We have CSS properties like background-size to easily scale and position images.

Ok, point taken. I might have been exaggerating on the size impact above.
But would like to stay with simpler guideline & maintenance standpoint on canvas filling logos. That was me from personal experience speaking, when we've got such guidelines in place it seems easier for volunteers to cut off logo without whitespace and prepare the logo accordingly. It's easier for them to imagine and calculate in for non-designers (again, my experience).

Relying on background-size can get really messy, as aligning with scaled/decreased whitespace to other elements.

In T245190#5950149, @Jdlrobson wrote:

Two questions:

1. Is it viable for the logo asset to always be a fixed width square e.g. 40x40 and make use of whitespace inside the SVG or do we need to make width and height configurable?

When the logo is a circle, it should take up more space than when it's a square to be perceived harmoniously. See https://design.wikimedia.org/style-guide/visual-style_icons.html

2. Is using the alt text a suitable fallback for older browsers? (no JavaScript/no SVG support)

I think that would be fine, is this only affecting browser with combination no JS&no SVG?

Having the alt in the config is a bit confusing to me. Why not a localizable message here?

I think that would be fine, is this only affecting browser with combination no JS&no SVG?

It would have to impact all grade C browsers (e.g. no JS, no SVG, Android 2 etc)

Having the alt in the config is a bit confusing to me. Why not a localizable message here?

That's good feedback. Yes I think that could make use of a localised message. However it would mean that editors would have to make the local change. If we are happy with no alt text by default that could work.

In T245190#5950149, @Jdlrobson wrote:

Two questions:

1. Is it viable for the logo asset to always be a fixed width square e.g. 40x40 and make use of whitespace inside the SVG or do we need to make width and height configurable?

I've updated the guidelines to reflect our decision that the icon area will always be 50x50px

2. Is using the alt text a suitable fallback for older browsers? (no JavaScript/no SVG support)

Yes, that is a suitable fallback

Also: I think we will be fine if we want to define a height for the header of 54px, as long as we ensure vertical centering. I've explore this in the sandbox: https://di-logo-sandbox.firebaseapp.com

In T245190#5961602, @alexhollender wrote:

I've updated the guidelines to reflect our decision that the icon area will always be 50x50px

The current patch is 44x44px. What's the decided upon size? The comments and images here are also inconsistent, some showing 44px, others 50px.

Also: I think we will be fine if we want to define a height for the header of 54px, as long as we ensure vertical centering. I've explore this in the sandbox: https://di-logo-sandbox.firebaseapp.com

Vertical centering is simple with IE>=11 and evergreen browsers. How much do we care about a few pixel misalignment in 0.33% of the user base (IE<=10 - T248061#6017455)?

In T245190#6021219, @Demian wrote:

The current patch is 44x44px. What's the decided upon size? The comments and images here are also inconsistent, some showing 44px, others 50px.

Thanks for pointing this out. The icon area should be 50x50px. The images in the task description are up-to-date.

Vertical centering is simple with IE>=11 and evergreen browsers. How much do we care about a few pixel misalignment in 0.33% of the user base (IE<=10 - T248061#6017455)?

That should be fine. Are we able to know how many pixels specifically it will be off by?

Vertical centering is simple with IE>=11 and evergreen browsers. How much do we care about a few pixel misalignment in 0.33% of the user base (IE<=10 - T248061#6017455)?

That should be fine. Are we able to know how many pixels specifically it will be off by?

Half of the difference of the wordmark+tagline height compared to the most common / what we use in development (enwiki).

enwiki	small wordmark	misaligned	big wordmark	misaligned

The current patch hides the logo icon for browsers with no-JS (basic) support. Upon revisiting that list it seems to me that includes all browsers that cause trouble with vertical centering, so the logo won't be visible if it would be misaligned.

@Demian thanks for following up here with the screenshots.

The current patch hides the logo icon for browsers with no-JS (basic) support. Upon revisiting that list it seems to me that includes all browsers that cause trouble with vertical centering, so the logo won't be visible if it would be misaligned.

Sounds good