Page MenuHomePhabricator

Allow installs to change or supplement the "Phabricator" icon
Closed, DuplicatePublic

Tokens
"Like" token, awarded by carlos.prado.vsys."Love" token, awarded by benjumanji."Like" token, awarded by rodbegbie."Like" token, awarded by cameronsparr."Love" token, awarded by johnny-bit."Like" token, awarded by nemobis."Like" token, awarded by GOPalmer."Like" token, awarded by qgil."Like" token, awarded by r0bbie."Like" token, awarded by allan.laal.
Assigned To
None
Authored By
epriestley, Dec 7 2013

Description

Current State

We now support changing the Phabricator logo (that is, the image with the text "Phabricator" in the upper left on every page) via the config option ui.custom-header

Config ApplicationUser Interfaceui.custom-header

This should probably get nicer with a nice file upload control right there that resizes and some stuff. We also need to fix a caching issue so the logo won't flicker; see T4214#98401 for a temporary workaround. Here's a screenshot of the current user interface with a customized logo.

Discussion

We once supported custom logos, but I removed support in D3101 before doing a bunch of iterations on the header, since it would have broken them anyway.

We've received some user requests for brand skinning ("I want Phabricator to look like my company's tools") and see some use of this in the wild (e.g., Blender). Users also used the custom logo support when it existed, although there wasn't much pushback when it was removed. I don't think this feature is hugely important, but it comes up every so often.

The major concerns I have with implementing it are:

  • (Product) Although I don't feel very strongly about this, it is nice to have branding in the UI. I think @btrahan feels a bit more strongly than I do. Installs are obviously free to change this locally, but conceptually this feels a little mushy to me.
  • (Technical) Originally, these images were served in a pretty hacky way. We should serve them properly. I think the new Files "builtin" support gives us most of what we need to do that (e.g., get them shipped over a CDN (T2382) with the right headers once we have support), although dirtying caches may be a little bit involved. We also can't reasonably sprite these today, and it would be very complex to develop the required infrastructure. Another possible approach is to use data: URLs (T3300). We could also do this via file uploads, which might be cleaner, but we don't currently have Config support for it.
  • (UI/UX) The header has separate desktop and mobile states. We need to plan around this if we offer customization.
  • (Ease of Use) The old logo required a small sprite with active and inactive states, and had an unusual (non-rectangular) shape. (The current logo doesn't have these issues.) It would be nice if users could just hand us any file of the right size (or any file, period, at some point) and we'd do the right thing. This is probably a given with the less-messy modern header.

One thought here is that maybe we can let users add a logo, rather than replacing the Phabricator logo? So, with a custom logo, you'd get:

MyCompany > Phabricator

...in the header. I'm not sure how practical this is (we're limited on space on mobile), or how acceptable it would be to installs that want to do company branding, but it might generally be cleaner and fix some of the constraint problems. This would also fix the issue that a bunch of company blogs have, where you click "CompanyName" in the header and get sent to the blog's root, not to the company's homepage. That said, I don't know if this is really an issue with Phabricator, and it would mean the "Phabricator Home" link target is no longer in the top left.

I think the pathway to getting this built is:

  1. @chad: Come up with a desktop/mobile look for "Phabricator + Brand" which fixes as many of the concerns above as possible (e.g., ideally a single rectangular image without a required hoverstate and with as few alpha channel concerns as possible, where the same image can always be used on desktop and mobile, and ideally ideally fitting it into crumbs if that seems like a good idea).
  2. I can drive all the technical stuff once we have a mock, it's not a super huge mess but not completely trivial either.

Related Objects

Event Timeline

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

This process isn't user friendly, and I don't think we'll close this out until it really is. Feel free to leave feedback here.

Yeah, we specifically plan to make changes in this vein eventually:

  • The web UI will give you an "Upload File..." dialog instead of requiring you to go look up a PHID.
  • The web UI will resize the image you upload and/or reject images which have the wrong size instead of letting you get a bad result by mistake.
  • We'll set the policy and cache information correctly without manual work, instead of needing to go digging around in the database.

We probably won't revisit this terribly soon, though.

epriestley removed epriestley as the assignee of this task.Feb 27 2015, 12:48 AM
btrahan updated the task description. (Show Details)Feb 27 2015, 4:40 PM
chad added a comment.Feb 27 2015, 4:43 PM

Been thinking if we go back to the rainbow logo, no one will want to change it maybe?

Rainbow logo was pretty fabulous.

I was easily able to get it to display a logo image that I uploaded to the files app. However, I didnt like the result. I followed the same process to configure an alternate image but it doesn't work. It accepts the setting and saves the correct PHID, but when the page is rendered, the inline css still points to the old image. It's not related to caching because I cleared my browser cache and I also cleared php cache and restarted nginx. If I remove the custom logo from the config, it goes back to default. Though when I add any other PHID to be the logo it displays nothing at all in the logo area (b/c the image it tries to show doesn't exist).

cleared php cache

How did you do this? If it was anything other than "by restarting php-fpm", try doing that.

nevogd added a subscriber: nevogd.Mar 4 2015, 12:54 PM

We had a similar experience, set the initial PHID for an image file, didn't like the result and then used the same process to change the image. The PHID changed, but the old file was displayed. I think we found the image was cached in the phabricator_cache database, after clearing those caches the new image displayed.

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

$ bin/cache purge --purge-all

We should also probably put the PHID in the cache key.

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

$ bin/cache purge --purge-all

We should also probably put the PHID in the cache key.

I can confirm that the purge command resolved the issue. Thanks!

chad moved this task from Design Complete to Backlog on the Design board.May 7 2015, 4:36 PM
chad moved this task from Backlog to 2015 Redesign on the Design board.

D13040 makes this not blocking of the Redesign.

So the current behavior is exactly the opposite of what I expected - changing the "logo" changes the "PHABRICATOR" wordmark in the header but leaves the eye image. Hmmm... I would think it better to keep phabricator but replace the eye.

chad added a comment.Jun 11 2015, 6:36 AM

You want less space?

20after4 added a comment.EditedJun 12 2015, 2:31 PM

@chad: No, we just want a way to nuke the "eye" logo.

I suppose a custom css tweak would probably make the most sense, even if it does mean merge conflicts down the road.

I agree with @20after4: We would also like to insert our organisation's logo instead of the "eye". Replacing the text alone feels insufficient.

I think that Phabricator should be "white label" software that anyone can take and quickly configure so it looks like it comes 100% from their own organization. That way, new users won't have any idea they are using Phabricator, and will instead think their own organization has some sweet tools, or in the SaaS competitor case, that SaaS competitor A really builds some great software!

Just kidding. That sounds like a terrible idea for the long term success of Phabricator.

qgil added a comment.EditedJun 12 2015, 3:18 PM

We call it "Wikimedia Phabricator" and our community talks about "Phabricator". Therefore [Wikimedia logo] + "Phabricator" makes sense, while "[What is this spooky eye?] + "Wikimedia" will create more confusion than the vanilla Phabricator header. I think the perceptions in other communities using Phabricator will be similar. All of them know their own logos, and all of them will recognize "Phabricator".

btrahan lowered the priority of this task from Normal to Wishlist.Jun 12 2015, 4:06 PM
In T4214#120376, @qgil wrote:

We call it "Wikimedia Phabricator" and our community talks about "Phabricator". Therefore [Wikimedia logo] + "Phabricator" makes sense, while "[What is this spooky eye?] + "Wikimedia" will create more confusion than the vanilla Phabricator header. I think the perceptions in other communities using Phabricator will be similar. All of them know their own logos, and all of them will recognize "Phabricator".

Strong hypothetical words about what will happen when folks experience Phabricator with white label features. Nice to hear about how things worked out without those features though.

qgil added a comment.Jun 12 2015, 4:24 PM

What I didn't explain is that this Phabricator header was one of the most contentious topics among some of our most experienced volunteers and some of my managers too. They were happy to fork the header and assume the cost of maintaining the local code. I calmed the discussion by promising that one day this will be fixed. So yes, communities care about their logos.

PS: if my story encouraged you to lower the priority from Normal to Wishlist, maybe I should have done something different on my Friday afternoon. :)
PS2: The "spooky eye" is not an hypothetical expression, I'm just quoting. In any case, as of today it doesn't compete with the popularity of the "Phabricator" wordmark.

pulkit removed a subscriber: pulkit.Jun 12 2015, 4:26 PM
chad added a comment.Jun 12 2015, 5:11 PM

Previously, we had one logo (eye + wordmark). On mobile, the eye was hidden leaving just the workmark. This was because of space constraints. In allowing installs to change the "logo", it made sense to have that be the workmark, which would appear on mobile. Eventually we resolved the mobile header and reclaimed that space, showing again both the eye and wordmark. I can't guarantee this will last depending on how Spaces plays out. If we add switching into the header, we might go back to hiding the eye on mobile. This is why we're currently replacing the wordmark.

At any rate, if we're going to do white boxing, I'd rather properly plan it through and through, not just a header image. (as in, it'd get sprinkled various places like login screens, etc).

+1 to what qgil says.

It's not a big deal for us at the moment (at least not to the point where we can be bothered to do anything about it right now), but if we were to see more usage of our public instance, we would probably be forced to do something, and the target would definitely be the logo. Having it say "Phabricator" up top is not a big deal - but the logo would be. Having our logo up top would let people know at a glance that they are still on our Phabricator (easy to get confused, especially for those of us who move between multiple instances).

In T4214#120383, @qgil wrote:

What I didn't explain is that this Phabricator header was one of the most contentious topics among some of our most experienced volunteers and some of my managers too. They were happy to fork the header and assume the cost of maintaining the local code. I calmed the discussion by promising that one day this will be fixed. So yes, communities care about their logos.
PS: if my story encouraged you to lower the priority from Normal to Wishlist, maybe I should have done something different on my Friday afternoon. :)
PS2: The "spooky eye" is not an hypothetical expression, I'm just quoting. In any case, as of today it doesn't compete with the popularity of the "Phabricator" wordmark.

I have no idea how this got prioritized above "Wishlist" as while its an item that people "care" about but it doesn't yield any strategic benefit from the upstream perspective. Empirically, we have shown that despite angst in a given community not having these features it is not a strong blocker for Phabricator adoption. Hypothetically, folks have argued that white labeling features will have a non-negative impact on future Phabricator growth as well as improve the experience of their local installs; apologies that I don't want to risk future Phabricator growth in a higher priority fashion on a theory where the theorists have clear bias to simply improve their local situation. That said, "wishlist" doesn't mean never.

This got raised to "Normal" so we could brand Phacility on admin.phacility.com

In T4214#98858, @chad wrote:

Been thinking if we go back to the rainbow logo, no one will want to change it maybe?

I was thinking along the same lines. That is, perhaps one way to mitigate this issue would be to use a less creepy and off-putting default image? To me, the eye is really bad.

Maybe in someone else's culture, it works for them, and I'm fine with that. What I'm not fine with is having this image hardcoded into the user interface. Looking at D11886 and T7165, it seems even sillier not to have this customization option.

I think that Phabricator should be "white label" software that anyone can take and quickly configure so it looks like it comes 100% from their own organization. That way, new users won't have any idea they are using Phabricator, and will instead think their own organization has some sweet tools, or in the SaaS competitor case, that SaaS competitor A really builds some great software!
Just kidding. That sounds like a terrible idea for the long term success of Phabricator.

In my reading, these types of comments are just an exhibition of some deep personal insecurity about your product. Great features, a clean user interface, an easy installation process, modular infrastructure, helpful technical support and documentation, and more are what give any product a competitive advantage. I don't think having a mandatory logo does.

Empirically, we have shown that despite angst in a given community not having these features it is not a strong blocker for Phabricator adoption.

"Not a strong blocker for Phabricator adoption" is not a reasonable standard for feature inclusion or exclusion. I understand and appreciate the consequences of technical debt and feature creep, but in a case like this, another question you have to consider is: what kind of horrible hacks will my users deploy in order to do this anyway?

Replace the eye image on the file system with something else and re-generate some sprite? Use custom CSS injected somewhere in a PHP file? Maybe some server-side include after the page's HTML is put together?

And in my experience, each of these horrible hacks that site administrators feel compelled to implement have predictably negative consequences, such as reducing the likelihood of performing a future software upgrade.

If we look at other software packages, logo customization is pretty standard. Even here there doesn't seem to be much argument against the idea. Which brings us to why I'm following this task at all...

For Wikimedia's purposes, as far as I'm concerned, @qgil has had his chance to get upstream to fix this. It's starting to get to be the time when we pick a horrible hack and maintain that for now until this task gets resolved.

Although I like the name Phabricator, and I am not so fond of the logo, I don't think anyone should fault the upstream for their priorities, and the fact that you need to keep your options open, to maintain design flexibility, that is totally reasonable.

Maybe a good solution would be to offer a clean(er) integration point for adding a few lines of custom css, without causing merge conflicts. Essentially a blob of css that can be configured without hacking any files in the core (to avoid risk of merge conflicts). Bonus points if the custom css gets properly optimized and cached but really just spitting it out inline within the page <head> would be good enough for a simple customization. It would still be less than ideal but it would be cleaner than arbitrary hacks. It would be easy to make it clear to downstream users that we are still implementing an unsupported hack and upstream changes might break the custom css at some point. But when that happens it probably won't be very hard to update our hacks to compensate for upstream changes.

For Wikimedia's purposes, as far as I'm concerned, @qgil has had his chance to get upstream to fix this. It's starting to get to be the time when we pick a horrible hack and maintain that for now until this task gets resolved.

@MZMcBride: I agree that it is probably time to hack away. We already changed the favicon and I'm really glad we did. It looks nice and makes it easy to see which tab belongs to each phabricator instance.

I will look into it and try to come up with a minimally invasive way to add a couple of lines of css.

It shouldn't really cause us to avoid upgrades - I am committed to (almost-)weekly upgrades of phabricator. It might just cause me some headaches when the upstream does a redesign. I say we take this discussion back to the wikimedia phabricator instance though, no use cluttering this task any further than we already have.

chad removed a subscriber: chad.Jun 15 2015, 5:36 AM

+1 to qgil's suggestion. Our logo looks like this:

And this is how our Phabricator is currently branded:

However, I would much rather it branded like this:

This is how Wikimedia Phabricator is branded as well. The tool is not "Everalbum", it's "Phabricator". The all-seeing eye icon doesn't convey that, and I'm not entirely sure how its presence helps spread Phabricator (which seems to be the concern around a custom logo feature). If the goal is to ensure users know they're using Phabricator, spelling the name out seems like it would accomplish that better.

beng added a subscriber: beng.Jul 29 2015, 10:08 PM

I strongly recommend a standard panda icon be shipped as a recommended alternate icon.

chad added a subscriber: chad.Jul 29 2015, 10:34 PM
In T4214#128906, @beng wrote:

I strongly recommend a standard panda icon be shipped as a recommended alternate icon.

I have awarded you some Flimsy Cardboard for this participation in Phabricator.

I thought I'd mention one other thing, since apparently the holdup on this issue is concerns over Phabricator branding. No-one on our team knows what Phabricator is called—they call it Phacility because that's what's in the URL. Allowing customization of the square icon instead of the "Phabricator" text would resolve that issue.

With as much opinions as participants or more, it's important to focus on what user wants to achieve and what Phacility wants to preserve.

All users are concerned with ensuring that their staff/contributors/users know that they are in good place, namely - within environment they want to interact with. Theoretically one look at header should be enough to say "You are in good place, carry on". Most people on this thread would be content with preserving "PHABRICATOR" wordmark, while exchenging "Spooky Eye" with company/organization logo. It does seem veeery consistent.

Phacility wants to maintain brand identity (which is VERY important) - this is very good sign. Currently design is very distinct, looks great etc, and if You enter any recent enough instance of phabricator it looks & feels like phabricator, despite any and all customizations - this is also very good for brand. Some have swapped out PHABRICATOR wordmark, wikimedia has spooky eye swapped out and this instance + phacility instances have wordmark.

I'm not opiniating any way but wikimedia looks best out of those customized - it maintains wordmark while having nice, identifiable organization logo placed. In one of instances i'm administrating due to branding constraints I have weird "[eye] [brand icon] [brand name]" that does not look good ;) best would be in that instance "[brand icon] [brand name] PHABRICATOR" as expressed by owner... However generall consensus is that if "[brand icon] PHABRICATOR" woulb be possible, then that would be preffereable.

rodbegbie added a subscriber: rodbegbie.
srijan added a subscriber: srijan.Nov 24 2015, 8:17 PM
chad moved this task from 2015 Redesign to Backlog on the Design board.Dec 4 2015, 2:16 AM
urzds added a subscriber: urzds.May 17 2016, 6:42 PM
benjumanji added a subscriber: benjumanji.

Would definitely like the ability to swap out the eye via config à la wikimedia install.

Are customizing styles and retaining the Phabricator brand altogether mutually exclusive?

I don't think so. Not if you take the approach letting the user add customizations to a baseline which is not editable from the config iface.

So you would ADD your logo to the right or left of the all seeing eye. You would ADD a custom footer above or below whatever Phabricator likes at the bottom of the page.

MS used to do this with the title bar in IE. I think it was something like IE for so-and-so-company.

As a user that sort of thing and some color tweaks would be perfectly adequate for me.