Making sure pages still look good when Facebook inevitably goes down

I’m a technical guy, so this is a mostly technical post, but hopefully that’s why you’re reading it. At Bazaarvoice, especially in Labs, we do a lot of work with the Facebook APIs. This can be challenging, because Facebook isn’t exactly known for it’s great uptime or documentation, but it’s also very rewarding to be able to pull in rich social information so easily.

One of the original Facebook-related things that we did across a large group of clients (at least since I’ve been here) was to add the Facebook “Like” button to client’s product and category pages. The integration that Facebook gives is simple, and it seems easy enough, but there’s quite a lot of work involved in safely integrating the like button while still considering uptime, page performance and meta-data.

Most specifically, we quickly ran into a problem with Facebook uptime. Since the like button is essentially implemented via a cross-domain iframe, there is little information you can gather, and little you can do with JavaScript to try to watch things unfold. Things have certainly gotten better since the early days of the Like Button. Load times are better, and the entire Facebook infrastructure feels just a little more stable, though you might say that we felt that way as well the first time Facebook went down and left ugly error messages in the middle of many of our high-profile clients’ pages.

It was actually fairly interesting going around the internet the day that Facebook was down for a long period of time. I believe the issue ended up being a configuration failure, and Akamai was returning server errors, though I’m not sure they ever officially said anything. I do know that instead of Like Buttons showing up on pages, boxes containing big, bold, “service unavailable” messages were being injected all over the place.

fblikedown_png_scaled1000

This occurred on big and small sites alike, and there seemed to be nothing we could do about it. Well, as a company that serves as high quality, and as high quantity of customers as we do, it behooved us to try and figure out a way to let something like this fail more gracefully. So a meeting was born. I’m sorry to say to all the meeting-haters that a solution was also born that day too. One that I’m quite fond of.

We went through some of the code for the asynchronous injection of the FB Like Button. It seemed as if a URL was built, an iframe was injected, and then a size was chosen. Even though Facebook was down, people using the Asynchronous ‘injection’ version of the Like Button were still mostly affected. This is because this file is highly cached, and very popular. As long as someone had visited any site with Facebook integration (there are a few…), the script was likely cached and running regardless of the actual server status. Then, when the script finally decided to load in actual data, the iframe that it injected was filled with the resulting error.

This meant that we had to rely on things that we knew didn’t have to phone home to Facebook, or rather, that if something odd happened after phoning home to Facebook, then we’d know we’re on the right track. We took a look at the events that the Facebook SDK would fire and noticed that there was an event that happened directly after the iframe was injected into the site. There was also code that followed it to determine the correct height for the widget. So all we had to was set the initial height to 0 after the iframe was injected, and then allow the FB to set the correct height afterwards.

This worked great. If the inner-page of the FB Like iFrame never loaded the javascript that determined the height of itself (like when the server returns error messages instead of markup and code), then it could never relay the correct information to resize its height to the correct proportion. This meant that we could effectively hide the Like Button until we could guarantee that the server had responded with working code.

Here’s the snippet we used:

FB.Event.subscribe('xfbml.render', function(response) { jQuery('iframe#theFacebookIframe').css({ 'height' : '0' }); });

Again, this stops the Like button from ever appearing if the Facebook servers are down. It’s a nice solution for a problem that rarely happens, but is important to handle well when it does. I’d encourage you to consider not only third party security, but also third party uptime when talking to providers. Facebook, while extremely useful, has had a tendency to go under as soon as you think they won’t again. Your clients don’t end up caring why there are error messages on their pages, so it’s the duty of the league of implementors to tackle problems like this one, and make sure that none of their clients have issues.

Stop, collaborate and innovate: Engineering a company science fair

Many people are aware of Google’s “20 percent time,” and the number of innovations that have been produced because of it (Gmail, Google News, and AdSense to name a few). Several other companies have tried this before and after Google; one of the most famous examples of side-project innovation is 3M’s Post it Note. Software development companies are now emulating this model, holding hack-a-thons where flurries of innovation occur.At Bazaarvoice we’ve been holding regular Science Fairs every few months for well over the last year to allow our Engineering team to stretch their creative muscles. The format is simple; we schedule the two-day Science Fairs at times that are not likely to have a lot of conflicts with the regular release cycle, typically over a Thursday and a Friday. When the engineers arrive on Thursday, instead of working on the newest features in our evergreen platform, they get to choose what they want to work on. Teams of engineers (and designers) from across our Implementation, Development, Operations, and Support teams work together all day Thursday—often late into the night—and half of the day Friday to bring their ideas to life. After lunch on Friday the teams present their projects to a panel of judges and finalists, and winners are announced.

These types of events are an amazing addition to the company’s culture, and really help to drive new innovations into our products. Engineers walk away from the two days of coding with a new sense of empowerment, realizing just how much they can accomplish in such a short period of time. Additionally, many of the projects stretch the bounds of what our products can do already, showing us new areas for efficiency improvements, incredible new user experiences, or just plain fun new ways of looking at the same data.

Having done this for a year, we’ve learned a few things along the way about how to run a successful Science Fair. Here are my top three tips.

1. Get thematic

We’ve learned that providing some structure to the projects helps to give people direction. We’ve published a list of themes for the last two Science Fairs, and that has helped not only with the task of judging all of the projects by dividing it into manageable chunks, but has also been a way to help engineers discover projects that they are passionate about.

2. Don’t be afraid to show it off

Second, it is critical that participants be able to see as many of the projects as possible at the conclusion of the Science Fair. We still have room to improve on this, but including a Science Fair Open House the Monday after the fair provides everyone with a chance to see what their peers were able to accomplish.

3. Level set

Finally, it is worthwhile noting that you should not expect to get new features or products out of every event. It is much more valuable to keep the process very open and to allow everyone to enjoy themselves rather than feeling like they have to produce the next great thing.