Disabling your Twitter background image cleanly

Something that’s frustrating me with the Twitter API is that there seems to be a useful piece of information missing when querying the API for a users settings. There’s a few different ways of pulling this info but http://twitter.com/users/show/ldnstreetlife.xml is as good as any for the purpose of showing you what I’m talking about. The feed contains all the users profile information so we can quite nicely replicate their design in our own app except one vital piece – there is no mention of whether or not the background-image has been disabled. Yes the “profile_background_image_url” node contains the url to the image and the “profile_background_tile” is a boolean which tells us whether or not to tile that background image, but there is also a third option offered in the Twitter design settings which is to disable the background-image altogether, and the API fails to report on this. The problem is it can really make the design look crappy on an account with the background image disabled:

It’s a simple oversight by the API team and one that I’m sure is a dead simple fix when they get around to addressing it. I tried hitting up a couple of the Twitter API coders directly on Twitter with no luck, so I just recently submitted it as a bug http://code.google.com/p/twitter-api/issues/detail?id=370.

In the mean time I wanted to come up with a way to address this issue in my app. More than anything I myself have the background-image disabled in my settings so when I look up myself in my own app it’s ugly. The obvious simple solution was to throw in an exception for myself, but that doesn’t really fly with me.

The second idea I had was something way more complicated. Firstly I’d need to copy over the twelve theme settings into my app. Then I’d be able to cross-reference the users background image with their background color to see if they were using a default image with a custom color. If that were the case it would mean the user had personalized their background color but not their background image, and therefore it was highly likely that the background image had been disabled. At first this seemed like quite a clever idea, it certainly worked in my case where I had disabled my background image and personalized my background color but my background image still remained as one of the default themes. But what if a user had at one point uploaded their own image and then decided to disable it? In that scenario their disabled background image would still be displayed. And then there’s the perhaps more unlikely, but still possible situation where a user has kept the default background image enabled but changed the background color. In that scenario the background image would wrongly not display in my app.

Third time lucky was the obvious, and the one that I settled on as a viable solution while we wait on the API team to amend the feed. It’s basically just to upload an invisible image as your background image in the Twitter display setting – an invisible image being either a transparent gif/png or an image matching your background color (which would obviously be harder to maintain in the long run). I created a 1px x 1px transparent gif and it worked great:

It’s not an across the board solution, it only works if each individual user takes a moment to update the background image in their settings. But for the time being it works great for me, it no longer looks like my page is broke in my own app, and I’m sure the Twitter API team will have this issue resolved in no time. If you also have your background image disabled in your Twitter profile go ahead and re-use my image so you don’t run into the same problem: http://s3.amazonaws.com/twitter_production/profile_background_images/6355571/transparent.gif

One Comment

  1. [...] There seems to be a property missing from the Twitter API. If you choose to have NO background image, then the API still returns the default image. There is no property to tell you if the image is disabled. More can be read about the issue here (including a simple workaround). [...]

Leave a Reply