Page MenuHomePhabricator

Top bar of Phabricator should signify to users they are interacting with a Wikimedia project space
Closed, ResolvedPublic

Assigned To
Authored By
flimport
Apr 17 2014, 8:20 AM
Referenced Files
F188117: Screen Shot 2015-07-02 at 03.41.58.png
Jul 2 2015, 2:46 AM
F183966: Screen Shot 2015-06-28 at 10.29.10 AM.png
Jun 28 2015, 2:35 PM
F25106: pasted_file
Dec 24 2014, 8:21 PM
F21374: Screenshot_from_2014-12-16_04:39:41.png
Dec 16 2014, 10:40 AM
F21296: wikimedia-phab-header.png
Dec 15 2014, 7:04 PM
F20970: Wmf_logo_white-02.png
Dec 12 2014, 10:57 AM
F20974: Wmf_logo_white-02.png
Dec 12 2014, 9:39 AM
F20972: phab-wikimedia-logo.png
Dec 12 2014, 9:36 AM

Description

The top bar is needlessly black and takes a lot of space for no real gain: in particular the LotR-like eye logo is huge and stressful. Bugzilla's discreet top bar is a good model to copy.

Whether you see it or not, here you have a white Wikimedia logo ready to be deployed as soon as upstream implements Allow installs to change or supplement the "Phabricator" icon: F20970

Wmf_logo_white-02.png (40×39 px, 634 B)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Quim, I actually don't think we should be supporting upstream T4214. It's a really poor compromise. If we put our logo there, I'm 99% sure that we'll be violating our own (relatively lax) trademark guidelines, and if we aren't, we might want to think about updating our trademark guidelines. Abutting our trademark a couple pixels away from the word "Phabricator" with no "Wikimedia" to be found makes it appear as though the logo is part of Phabricator's trademark rather than a separate mark. Many people probably won't even notice that the logo has changed since the "Phabricator" part is much more prevalent there, so it kinda defeats the purpose of the change. I have a hard time believing that the resulting trademark confusion is in their best interests, either.

In upstream T4214#46167, Chad Little notes "Logo/Header would likely resolve 98% of needs, and the work for full skinning for 2% would likely be not worth the development time." That comment is possibly true out of context. I say "out of context" because I don't think control over just the 40x40 logo is the "98%" solution they're loooking for. However, being able to have better customization in the header (setting height, full control of logo and background color) would get us to the point where then we should just be collaborating with them on the rest of the design rather than striking out on our own. I could see the login page (T862) also being an area where we need more custom control, but even there, we might be able to work out a more sensible stock configuration with upstream.

I'm not planning to comment on upstream T4214 until we come to some better agreement about what we want here.

Quim, [...]

In [...]

I agree with all of this. Thank you!

Can we agree to skinning Phabricator (with or without upstream's support) in the first half of 2015?

I'm actually less concerned about the technical side of this than I am about the design side of this, as the next logical question after "okay, let's redesign it" becomes "uhh, what should it look like instead?"

In my opinion, removing the eye from the header alone would be a real win, but simply replacing it with the Wikimedia logo isn't the right solution, as you note. Should the whole skin look more like Vector? Should it look more like Winter? MobileFrontend? Or should we focus exclusively on the top horizontal header from default Phabricator and leave it at that?

Qgil raised the priority of this task from Lowest to Low.Dec 14 2014, 9:06 PM

Thank you for all this feedback. Considering that our reference points are Bugzilla, RT, Trello, Mingle, Scrumbugz, GitBlit, Gerrit... that is, tools that will not be remembered by their Wikimedia UI customization, I wonder whether we can agree on a goal based on a lean customization:

  • Let's consider a local patch to customize the Phabricator name, logo, and also color of the header if needed. All the better if we can keep the same position and size of the images.
  • The current icons and structure of the header would stay as they are. They are quite neutral.
  • This would inherently mean that the header should keep using a dark color, otherwise the contrast with the Phabricator header elements would be lost.
  • We would keep the body and the footer as they are.

This should be enough to "signify to users they are interacting with a Wikimedia project", don't you think? If we agree on this lean approach, then we can estimate the maintenance cost. And if we agree on going for it, then I would recommend that @Heather takes the task and provides the design assets agreed with the WMF Communications team.

Setting Low priority for now. Your flexibility with the timeline is appreciated because we still have a lot on our plates. Also remember that we are three days away from a RT Migration, so bare with us if we are more quiet than usual out of the scope of that migration.

Or should we focus exclusively on the top horizontal header from default Phabricator and leave it at that?

Probably this, at least at first. The rest of the design, while maybe not everything we would have it be, is defensible, and actually not too far out of tune with Vector. Phabricator development is moving fast enough that I believe them when they say that a lot of customization will slow them down. I'm sure there's a point that this will no longer ring true, but we should cut them some slack as a new user of the software, and also generally try to influence the stock design of the software where we feel it needs it.

Even for the header, I wouldn't recommend we insist on a hard requirement to have full header customization. Furthermore, it might be in both our interest and in Phacility's interest to have some sort of "Powered by Phabricator" type wording in the header. In their interest for obvious publicity reasons, and in our interests to make it a little more obvious "this isn't MediaWiki anymore...things work a little differently here" (plus offering them a little traffic as good downstream citizens). If we take the "Phabricator" wordmark completely out of the header, we should probably add it to the footer.

I was going to suggest that the header say something to the effect of "<big>Wikimedia Foundation Issue Tracking</big><small>powered by <link>Phabricator</link></small>", but "issue tracking" isn't the only thing in scope here. I'm not sure if there is a pithy two word description that wouldn't add to the confusion. "Development platform" is the term Phacility uses to describe Phabricator, but I wouldn't call this site the "Wikimedia Foundation Development Platform". *shrug* I suppose having a descriptive header isn't strictly necessary.

In T69#846961, @Qgil wrote:

Setting Low priority for now. Your flexibility with the timeline is appreciated because we still have a lot on our plates. Also remember that we are three days away from a RT Migration, so bare with us if we are more quiet than usual out of the scope of that migration.

Yup, all seems reasonable especially in light of your backlog -- at first glance, I'm not seeing anything I'd suggest deprioritizing to make room for this. Thanks for your attention on this, Quim!

(plus offering them a little traffic as good downstream citizens). If we take the "Phabricator" wordmark completely out of the header, we should probably add it to the footer.

Hopefully that would even give some incentive to making the footer more readable :) (T628)!

Quim, [...]

In [..]

Also agree with all of this. Some pretty important points there.

Probably https://secure.phabricator.com/T4213. It's pretty incredible (and impressive, in a very disturbing way) that a team has created an application that has worse skinning support than MediaWiki.

I know this is a bit of a tangent, but I have to ask - what have you worked with that is actually any better? From the outside other things often look a lot nicer etc than they really are in practice; actually try to do it and a lot of the time it's just like WTF IS THIS I DON'T EVEN. Especially if you want to do really fancy stuff like i18n or micro-changes to an existing theme.

Some of the things we have on mw are pretty damn strange, I'll grant, like the ability to append css/js after the fact on the project itself, but in practice this is quite useful for little things. Considering how little overhead that actually causes, perhaps getting something like that added would be useful here, too, in lieu of a smarter, more complicated customisation thing? Yes, it would still need to be fixed every time there's a backend update, probably, but it would also keep all the stuff out of the backend code, so it'd make things a lot easier.

In T69#846576, @Krenair wrote:

It should be a simple case of adding this to the end of a CSS file somewhere: [...]

If we could make the logo image space bigger, just plopping in a 'wikimedia' as well as the icon would probably solve a lot of the branding issues presented by just having the icon... for us, anyway.

Here's my proposal for a nice, minimal customization:

wikimedia-phab-header.png (413×856 px, 24 KB)

In T69#848570, @mmodell wrote:

Here's my proposal for a nice, minimal customization:

That might just be enough, assuming others agree that it meets the minimum bar. I'll let others bikeshed on the exact font/size/wording. A little more customization would still be very nice, but this at least takes us to a minimally acceptable place (from my perspective).

I'm not sure if there is a pithy two word description that wouldn't add to the confusion.

After some thought, this Summer I ended up with "Phabricator is a collaboration platform...", which is the pithy two word description that we have in the homepage currently. Does this mean that I would be excited about seeing "Wikimedia Collaboration Platform" in the header? Gosh, no.

After years under the Wikimedia umbrella, Bugzilla has been always Bugzilla, Gerrit is Gerrit, and Phabricator will be Phabricator. Brands are successful because they are useful describing something unique without needing a description. So what about this:

[Wikimedia logo] phabricator.wikimedia.org

So simple that is even boring. But it has the Wikimedia identity, the 'powered by' Phabricator (without writing "powered by", which to me sounds more patronizing than the current vanilla header), and for the rest, the homepage and each page where a user can land speak for themselves.

I like Quim's proposal, but perhaps just "Wikimedia Phabricator"? We've been calling the Bugzilla installation "Wikimedia Bugzilla" pretty consistently.

In T69#848570, @mmodell wrote:

Here's my proposal for a nice, minimal customization:

I like this too. How can I help make it happen?

[Wikimedia logo] Wikimedia Phabricator

That would work as well. We have been talking about "Wikimedia Phabricator" since the beginning. According to Google, there are about 2,610 results for "Wikimedia Phabricator".

@mmodell's current proposal just brings too much text in the header. This is a contrast with spacious Phabricator UI everywhere else. Also, I'd rather have a solid agreement on a plan and change the header once. Anybody against logo + "Wikimedia Phabricator"?

@Qgil: so we drop the phabricator wordmark (which is currently in a custom font by way of a sprite sheet graphic) ...and we replace it with a plain sans-serif font? Or keep the phabricator wordmark and just prepend it with the logo + Wikimedia

@Qgil: I did what you said I shouldn't do ;)

Screenshot_from_2014-12-16_04:39:41.png (279×403 px, 15 KB)

... and I'm happy you did. :D

I think F21374 is a good proof of concept of what can be technically done. Observations:

  • If I'm reading the visual identity guidelines on co-branding correctly, Wikimedia and Phabricator brands can be side by side in equal terms. This means that Phabricator can keep its font.
  • "WIKIMEDIA" should go in all caps with... Gill Sans according to the official documentation (outdated? I remember an equivalent free font being widely used, just can't remember which one).
  • Reading the co-branding guidelines it is unclear whether we can use the original Wikimedia logo with colors, or this white version. If the background is still black (and we don't have better candidates for a dark color), then the original logo with colors would fit better imho.

I'm curious to know what @Heather thinks, since anyway whatever we do here will need to be blessed by Comms.

Blender's phabricator uses a complete custom logo, and could serve as inspiration for ours. They seem to have changed both the html and the css...

pasted_file (177×323 px, 19 KB)

Our HTML:

<a class="phabricator-main-menu-brand" href="/"><span class="aural-only">Home</span><span class="sprite-menu phabricator-main-menu-eye"></span><span class="sprite-menu phabricator-main-menu-logo"></span></a>

Theirs:

<a class="phabricator-main-menu-brand" href="/"><span class="aural-only">Home</span><span class="sprite-menu phabricator-main-menu-logo"></span></a>

https://developer.blender.org/

It seems that now the image with the word "Phabricator" in the header can be configured: https://secure.phabricator.com/T4214

@Heather can you provide assets and guidance on branding to the team working on this task please? The asset that you uploaded earlier in the thread looks like the resolution and dimensions might be too small.

@Jaredzimmerman-WMF, not that what @Heather uploaded (F20974) is a Wikimedia logo to substitute Phabricator's eye icon, but what we can configure now is a substitution to the "Phabricator" word in the header. If we want to use this configuration, we need an image of a text reading either "Wikimedia" or "Wikimedia Phabricator".

chasemp lowered the priority of this task from Low to Lowest.Mar 23 2015, 4:39 PM
chasemp subscribed.

We are basically just waiting on upstream to allow this easily. It's actually in teh works from what I have seen.

You could edit this file https://git.wikimedia.org/blob/phabricator%2Fphabricator.git/12913549e833e476f5bc317acab733624e36444f/webroot%2Frsrc%2Fcss%2Fsprite-menu.css or replace those images at rsrc/image/sprite-menu-X2.png and rsrc/image/sprite-menu.png with Wikimedia logo.

You would just need to add a file explaning a custom change that would need to be re added after upgrade. and phabricator is currently having a redesign it has a new look but logo still there.

We can certainly modify this without too much invasive hacking but it's not ideal. I don't see upstream making this fully configurable for a while yet.

The only way to do it Is this way because they have a tracking bug for this on phabricator but they say it is vary unlikely that it will happen this year. We could add a readme file to say why we changed it and for develepers for when they update they can look at it to make sure there changes doint change the file we modified.

MZMcBride changed the task status from Stalled to Open.Jun 20 2015, 5:00 AM
In T69#844043, @Qgil wrote:

Marking this task as Stalled, waiting for upstream's Allow installs to change or supplement the "Phabricator" icon.

I'm changing this task's status from stalled to open per https://secure.phabricator.com/T4214#120659.

If I understand correctly, apparently Phabricator allows to include additional CSS files: https://secure.phabricator.com/T4222#47245

Although it doesn't seem to be something easy as just referencing a CSS file somewhere in the config

Change 219580 had a related patch set uploaded (by Paladox):
Add wikimedia logo for phabricator

https://gerrit.wikimedia.org/r/219580

This is probably the right solution for now. It will break when upstream changes this image or significantly changes the design but it's a good easy solution that works for now.

If I understand correctly, apparently Phabricator allows to include additional CSS files: https://secure.phabricator.com/T4222#47245

Although it doesn't seem to be something easy as just referencing a CSS file somewhere in the config

@Ciencia_Al_Poder: Thanks for pointing that out, I wasn't aware of that feature and it could be useful at some point. That does look like it would do the trick for including some css, however, it'll be much more expedient to just merge a change into our fork, as suggested by @Paladox.

Change 219580 merged by 20after4:
Add wikimedia logo for phabricator

https://gerrit.wikimedia.org/r/219580

Hi we could add an important file in that folder where we changed the image for users to read to make sure they doint change anything we customised.

Change 220671 had a related patch set uploaded (by Paladox):
Add x2 image of wikimedia logo for phabricator

https://gerrit.wikimedia.org/r/220671

I'm having trouble getting the image to render as good as the original, but here's my attempt: https://phab-01.wmflabs.org/

I'm not at all qualified to say this but I bet a bit of smoothing around
the edges would do nicely.

@Negative24: indeed, however, the original phabricator source image seems to be specially constructed, because gimp sees it as an indexed color image with 1-bit transparency, yet it renders with alpha-transparency. I can't figure out how they did it in order to reproduce the same quality as the original.

I'm very happy to see actual progress here. Thank you!

About the Wikimedia white logo, wouldn't it be better to add a svg directly, and let the browser do the rest?

About the Phabricator wordmark, why cannot just keep the original? They are supposed to be two pieces now, right? We can hack the eye, and leave the wordmark untouched.

@Qgil: They are served from the same sprite image, so although we can leave the wordmark alone, it requires touching the image. When I touch the image with gimp it seems to gimp it up somehow. ;)

Re: svg: That would mean hacking the css, if we could touch just one file (the image) then that seems like a good solution. Note though, the new redesign upstream changes the size slightly (I think it does, anyway) so it'll take more work later :(

@mmodell: If I open it in gimp it indeed looks like 1-bit transparency. However, if I change color mode to RGB it suddenly recovers the alpha-transparency

For svg we could do like

background-image then webkit or the other prefix that decide for transparency then use background-image png for browser that do not support svg.

It looks good and best part new colour meaning phabricator now looks really good.

Screen Shot 2015-06-28 at 10.29.10 AM.png (127×997 px, 60 KB)

The Wikimedia logo is still a bit rough around the edges, but I'm fine with pushing this change. We can rely on Cunningham's Law to get the perfect logo. :-) But for now, switching to the Wikimedia logo and banishing the scary eye is a marked improvement, in my opinion.

Thank you for working on this!

Quim, I actually don't think we should be supporting upstream T4214. It's a really poor compromise. If we put our logo there, I'm 99% sure that we'll be violating our own (relatively lax) trademark guidelines, and if we aren't, we might want to think about updating our trademark guidelines. Abutting our trademark a couple pixels away from the word "Phabricator" with no "Wikimedia" to be found makes it appear as though the logo is part of Phabricator's trademark rather than a separate mark. Many people probably won't even notice that the logo has changed since the "Phabricator" part is much more prevalent there, so it kinda defeats the purpose of the change. I have a hard time believing that the resulting trademark confusion is in their best interests, either.

I agree. We've previously rejected proposals to stamp Wikimedia logos in random places for the same reason. For Gerrit we made a custom logo that adheres to our trademark guidelines.

Unfortunately, the change got deployed as-is and now looks like this:

Screen Shot 2015-07-02 at 03.41.58.png (310×544 px, 61 KB)

It violates our guidelines. It is confusing in general (design-wise it communicates that either our icon is the logo of "Phabricator" and/or that "Phabricator" is the name of our movement).

In addition, it's a rather poor quality rendering of the logo. I don't just mean that was boldly stretched to fit 2x sizes (instead of being a real 2x render), it was a GIF-like alpha rendering to begin with. Where the edges have no pixel aliasing.

Please revert this. We can try again later.

Perhaps a better solution would be to keep the phabricator logo in the
header thingy. Like with bugzilla, this is phabricator, we're not saying
otherwise, keep the usual whatnots. Maybe change the colours to match
the favicon, but nothing too fancy.

But this is also wikimedia, hence why this thing is here in the first
place. But put the wikimedia logo somewhere else. Maybe just a big faint
one in the content background or something. That might be neat. Maybe in
the back-background, with a faintly transparent foreground dealy over it
so it shows through, but only barely...

Bear in mind I just made all this up right now and haven't actually
looked at it or anything, though. I can make a mockup later.

I agree. We've previously rejected proposals to stamp Wikimedia logos in random places for the same reason. For Gerrit we made a custom logo that adheres to our trademark guidelines.

We're currently at phabricator.wikimedia.org. It's not a random place and the user confusion arguments seem pretty weak to me. Is there actual confusion or is this all theoretical?

As you mention, Gerrit uses the Wikimedia logo without issue. As does wikimedia-l: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l. As does Wikistats: https://stats.wikimedia.org/. There are quite likely additional examples.

Unfortunately, the change got deployed as-is and now looks like this:

Screen Shot 2015-07-02 at 03.41.58.png (310×544 px, 61 KB)

It violates our guidelines. It is confusing in general (design-wise it communicates that either our icon is the logo of "Phabricator" and/or that "Phabricator" is the name of our movement).

You really think we're communicating that "Phabricator" is the name of the Wikimedia movement? That's pretty silly. We're communicating that the user is on Wikimedia's installation of Phabricator, which is completely true.

This is, by the way, very analogous to how we treat MediaWiki. Yes, other wikis use the same Vector skin and consequently look similar to Wikipedia, but we've always supported a custom upper-left logo to allow installations of MediaWiki to brand themselves. In fact, MediaWiki actively encourages changing the logo. I don't see why Phabricator would be treated differently than how we treat our own large software application.

Please revert this. We can try again later.

Perfect is the enemy of the good. The Wikimedia logo is much better than the creepy eye. If you have a better image to swap in instead, I'm quite sure that @mmodell would be happy to accommodate. :-)

Change 222351 had a related patch set uploaded (by Paladox):
Add svg logo for wikimedia

https://gerrit.wikimedia.org/r/222351

For what I can see, the current header with the Wikimedia logo and the Phabricator wordmark are compliant with our Wikimedia Trademark Policy on Wikimedia sites and our Visual Identity Guidelines on co-branding:

This design has been supervised by @Heather, meaning that it comes from the WMF Comms team.

It looks good to me.

The quality of the logo rendering is far from perfect, I take credit for it's failing. Although I used to be fairly skilled with Photoshop, I stopped using a mac a couple of years ago for philosophical reasons. I haven't yet mastered the gimp, and I wasn't prepared to spend a couple of hours figuring out how to make it do what I wanted. I settled for just barely reasonable rather than perfect.

I'll have a shot at it. Does it have to be black-and-white?

I doint think it has to be black and white but I think it is preferred but if you can get it too look better in another colour.

T104515 seems to have changed it back to black. (that is, the header)

For my part, I see the WmF logo, then the Phab tag

I ment if the Wikimedia logo should be black and white?

Oh I think it should be white for now since the top bar is currently using darks colours for top bar.

Black/white would be more consistent with any other elements in the top bar (except for your user avatar).

But not so consistent with other projects like Gerrit.

Little bikeshedding here: the former default indigo blue were A LOT more convenient on workboard views, where the dark is a strange breakdown.

@derekson and anyone else who doesn't like the black. I agree that it looked nicer with the dark blue, however, I changed the background to black due to @Jaredzimmerman-WMF's comments (quoted below), simply because, as "Director of user experience" he would seem to be the person most qualified and probably the person with the requisite authority to decide this one.

Two things, we're not going to pick a color at random, e.g. It needs to come from an existing palette, either at the product or foundation level.

If at some point the phabricator logo will be replaced with a wikimedia logo then we really have only two options. Black or white. Brand guildlines will not allow for the logo to appear on a color background.

I recommend black, to give some contrast with the rest of the page, but hey, white is a great color two.

mmodell claimed this task.

If at some point the phabricator logo will be replaced with a wikimedia logo then we really have only two options. Black or white. Brand guildlines will not allow for the logo to appear on a color background.

Is this still true?

Where do the guidelines say this? I looked at the Wikimedia visual identity guidelines and couldn't find anything about the WMF logo at all for this.

@Isarra: There is this: https://wikimediafoundation.org/wiki/Visual_identity_guidelines#toc-branding ... It does not seem to prohibit background colors. Seems like the use on phabricator is acceptable though appearing next to the phabricator wordmark might not be in compliance with the "equal emphasis" rule.

Another suggestion, I've created a "full version" of the colored favicon (maybe this could be usefull, requested by another user):

Change 222351 abandoned by 20after4:
Add svg logo for Wikimedia

https://gerrit.wikimedia.org/r/222351

Change 220671 abandoned by 20after4:
Add x2 image of wikimedia logo for phabricator

Reason:
the logo has already been addressed in another patch which already merged.

https://gerrit.wikimedia.org/r/220671