Welcome to the jungle

Since Big Prize Giveaways took off in September/October of last year, we’ve been almost exclusively developing Facebook applications of some sort, whether they’re for Page tabs, canvas pages or external Connect “Login with Facebook”-enabled sites.

The platform has changed; almost to the point where it’s completely different today than it was just 9 months ago. In today’s landscape, changes to web services and APIs are inevitable: first versions are designed and implemented hastily, with newer versions having better organization and technology. Normally, changes like these are announced, with timelines, transition plans, and, if all goes well, overall improvement to the service. After all, the point is to make things better for developers using your service, right?

Starting with last October’s changes announced via the Facebook Platform Roadmap, the Facebook team has been adding, updating and removing features from the platform left and right. But I’ve noticed several disturbing trends: the Platform has become more complex, less reliable, and and less predictable. These trends, if they go unreversed, are enough to start making people move off the Facebook platform (see the recent Zynga scare for an example). Here’s some things Facebook can do to make things better for developers.

  • Make the Live Status page suck less. A couple weeks ago I was working on an app and ran into some issues. I narrowed it down to a call I was making to the Facebook API, so I went over to the Live Status page to check and see if anything was down. I was greeted with the “Facebook Platform is Healthy” message.

    There’s only one thing more frustrating to me than working with a broken third-party API: checking the so-called “status” page and being cheerfully informed that the API isn’t broken, when it clearly is. And this isn’t just a case of “haven’t gotten around to updating it yet”; through days and days of brokenness, that “Facebook Platform is Healthy” message remains.

    Another thing that drives me crazy about that page are those graphs on the side. There’s no scale; you have no way of knowing whether that errors graph shows 1000 errors/minute or 10,000,000. The only reference you get is yesterday’s data, which is useless if you’re of the cynic-but-realistic opinion that the platform is broken every day. Additionally, the graph is such a broad scope that even if one or two functions are causing errors, they’re likely to be drowned out in all the background noise. It’s kind of like looking at a population graph of the entire world and expecting to see a blip when an airliner crashes with 200 people on board. The scope is too big to figure out if anything’s wrong.

    So how do you fix it? First, lose the broad scoped graphs and add mini-graphs showing each major function call, and plot it against the number of total calls as well as yesterday’s numbers. Add graphs showing the average Facebook canvas page load time. Add graphs that show the average response times over the last 24 hours plotted against the mean for the last week and last month. As for the actual status updates, make them real, make them timely and make them accurate. Allow subscription by SMS and syndicate to a Twitter account, and maybe even set up a bot on the #facebook IRC channel.

    Ultimately, the live status page just needs to be what the name is: live or close to it, and indicative of the actual status of the Platform.

  • Get rid of the useless page at facebook.com/developers. Right now, going to that address takes me to what I guess is supposed to be a helpful mashup of the developers blog and all your apps, with the live status way down the page below the list of apps. It’s a horrible design: the left column, the one with the blog, is about two screens for me, while the right column, with the super-long, horribly designed list of apps is at least ten pages long. That’s right: there’s about 8 pages of whitespace that’s completely useless.

    I understand that not everyone has 80+ apps that they’re managing on that screen, but for those of us who do, arguably Facebook’s most loyal developers, this is supremely annoying not only for it being a page that is barely functional as it is, but also because it’s completely unnecessary. Clicking any one of your apps will take you through to another list, this one at least somewhat more useful, with all the same functionality, minus that oh-so-useful developers’ blog and the live status widget (which, to be clear, are both available elsewhere). Why do we need the intermediate page? Facebook should save themselves a redesign and just scrap that page entirely.

  • As for the next page, make it suck less. I’ve stated that this page is better than the page preceding it, but not much. This page lists all your apps in alphabetical fashion on the left side of the screen and gives you an options box and a bunch of vitals in a large information box on the right.

    If I have a long list of apps, I need to be able to organize them in better fashion than “alphabetical list”. Seriously, hundreds if not thousands of software programs have solved this in some fashion: using folders, groups, search-as-you-type made popular by iTunes, anything to help make that list a little easier to navigate. There’s also no reason that if I have a long list of apps, I should have to scroll down to find my app, click it, then scroll all the way back up to see the information box.

  • Announce changes. Please. I understand that Facebook is a company that moves fast, so fast that they seemingly have no time to test, no time to document, and no time notify developers. But it’s a rule of the Internet that once your site gets to 500,000,000 active users, you’re now officially a business and you need to act like one.

    And look, I’m all for innovation, and I’m not asking for a huge lead time. But a couple weeks ago, for example, Facebook pushed a change that affected most of our applications without letting anyone know. On a Friday afternoon. We didn’t find out until Monday morning that a change had taken place, and had to scramble to work around the issue. It wasn’t even a case of the team fixing a bug before leaving for the weekend – functionality was changed (in this case, removed), not restored to the previous working state.

    My understanding is that Facebook is pushing code nearly every day. If asking that changes be announced is too much, can we at least know when a change has been pushed so we can check for errors or potential problems? This is literally a 5-second process to post a tweet or update that live status feed, but knowing when changes were made would greatly help.

    And once we all get used to that, how about for all non-critical bugfixes, we institute at least a 2-hour notice (with the critical bugfixes still requiring a notice as the change happens), and no non-critical changes can be made until after 6 PM PST (except when announced)? The notice would include what bug the fix addresses, or what feature this new push is adding. This way, developers would know when changes are coming and have enough time to react gracefully.

    Ultimately, this is part of the software lifecycle that every big application eventually reaches. Imagine, by comparison, that Microsoft pushed an unannounced Windows Update that made all .NET 2.0 applications incompatible with Windows Vista. People would be ticked. On the other hand, if Microsoft did the same thing but announced the change a couple months in advance, people would still be ticked, only less italicized because at least they could have time to try and move up to 3.0+ or upgrade their operating system. This part of the software lifecycle may not be as fun as the “innovate so fast your hands hurt” phase, but it’s necessary and needs to be part of Facebook’s culture.

  • Unify the documentation. Right now, there are the wiki and the static pages. The static pages are fairly new, so it’s unfair to expect them to be complete yet, but right now they serve as a tutorial, something you reference when you’re trying to learn. This was a great approach for about 48 hours, but after that, we’ve read the tutorial; we just need to look stuff up.

    This is where the wiki comes in, but there’s no direct link from the documentation home page, so it’s unclear what Facebook’s final intentions are with this. But if you’re going to keep the wiki open, at least keep it relevant. Many of the articles on the wiki say something along the lines of “this is about to change — April 2010″.

    My suggestion here is to get rid of the wiki altogether (official documentation in the form of a wiki is just lazy, to me), and adopt a PHP.net-like documentation setup, with individual pages for each major function, use-case and algorithm, and allow users to comment with code samples and questions. It’s important here to keep the developers involved in not only updating the documentation when needed, but also responding to comments and questions.

  • Hire someone (or two) whose sole job it is to interact with the developer community. A lot of times, the #facebook channel on freenode is the best way to get at the Facebook developers, but that’s a understandably a longshot because the developers have a lot to do, and sifting through the noise of questions that should be answered elsewhere (“my friendz account got banned help me plz :(” is my personal favorite) is probably not the best way for them to spend their time. Nonetheless, having someone on that channel often enough to answer questions as well as serve as a conduit to the rest of the Facebook team would be a more effective way of communicating with the community. For all it matters, this could be the same guy documenting when changes go out, when the live status changes, etc. But there needs to be a consistent voice and a consistent place to ask questions.

It’s not insignificant that Facebook’s platform isn’t quite three years old. The platform has seen such tremendous growth and now is so integrated with Facebook.com that it’s hard to remember when the platform wasn’t out there, but three years ago, it was still in just the planning stages, and so it’s understandable that the second-most popular API platform out there is having some growing pains (the number one API platform is, too). But the way to a developer’s heart (and loyalty) is to make things easier, clearer, and more predictable. Hopefully Facebook makes at least a few of these changes. It’d make my life a whole lot less frustrating.



Originally posted on Cleveland, Curveballs and Common Sense on June 9, 2010 at 8:30 AM. Post text content © 2010 Jimmy Sawczuk. All rights reserved.

Comments