developers

When we build Facebook applications we always start with a spec.

A spec is a document that details the complete application user flow and provides the technical details necessary to put together a functional back end and stay with Facebook’s ever-morphing application terms of service. Basically it’s like a blueprint for your house.

We’ve talked with some clients who want to work from another Facebook application instead of first doing a spec.

I get the logic: “Here is a complete application that is already on Facebook. We know it conforms to the terms of service (or is not yet shut down) and we know how popular it already is. Why do I need to pay money to have someone write out the functionality when they can just look at it in action?”

Aside from the obvious possible pitfalls of simply cloning someone else’s application, ranging from possible copyright issues to opening yourself up to getting bashed the reviews, you’re only looking at half the picture when you’re using an application.

While the user flow is important to every application, it’s equally (if not more) important to have a complete framework for what the app requires technically. The plumbing, if you’ll allow me to continue the construction metaphor, needs to be planned out before you start nailing planks of wood together.

Welcome to our community! If you like what you see, you may want to subscribe to our RSS feed!

For all you developers out there who’ve seen the insides and outsides of the Facebook developers site so many times that you might as well live there, you now have a chance to tell Facebook…everything about you as a developer.

Pete Bratach posted on the developers blog about a half an hour ago asking for feedback about their developers site through this survey. The survey asks such self-critical questions as:

• Are you profitable on the platform?, and
• If yes, how much revenue are you generating per month?

OK, OK, to be fair, they do spend about half the survey asking you to rate, on a scale of 1-3-5, different aspects of their platform. And there’s a field where you can offer yourself for an interview.

So if you’ve got feedback to give, hop on over to the google doc and fill ‘er out.

Aspiring iPhone developers are getting rejection letters by the thousands. Meanwhile, developers who have made it into the beta program are reporting that the shallow integration leaves next to no opportunity to build anything meaningful. Update: Developer Craig Hockenberry has a very interesting perspective on one of the major issues at stake in the debate.

A few months ago at Community Next, Mitch Kapor was bemoaning a similar problem with regard to the Facebook platform. It appears that at first pass, most developers are going to be dissatisfied with the options available to them on any platform.

This is symptomatic of one of the fundamental tensions Kapor described in his talk: platforms want to open up slowly and test the waters. Developers want to do everything right away. In the end, smart people usually find a way to work around platform limitations and go on to build cool stuff.

That said, there is a right way and a wrong way to engage with developer communities, and it’s safe to say that Apple isn’t doing a great job. At the risk of driving everyone nuts with another Mark Zuckerberg / SXSW post, I’d like to hold the Facebook team up as an example of how to start doing things right.

After his much-lambasted keynote interview, Zuckerberg made the decision to appear at the Facebook developer garage the following afternoon. During the Q&A, I noticed that he was more at ease onstage than we’ve ever seen him. Perhaps it had something to do with the fact that he was in his element chatting informally with geeks.

Whatever the cause, he was positively ebullient — by Zuckerbergian standards, anyway. Afterwards, he made himself extremely accessible. And since then, he’s been giving out interviews left and right, which has earned him some — IMHO, undeserved — scorn from Valleywag.

If Facebook keeps this up, they’re going to become a poster child for how to interact with developers. Of course, I don’t expect Zuckerberg to pull a Steve Ballmer anytime soon. Running up and down a stage screaming “Developers! Developers! Developers! Developers!” doesn’t really strike me as his style.

But as we watched his eyes light up while answering our questions about the site he has built from the ground up, many of us in the room gained a deeper understanding of his passion for and commitment to the platform. As I told him afterwards, that was the moment when a many of us decided, “this Zuckerberg guy isn’t evil.”

At base, what this really means it that for platform owners to maximize developer engagement and productivity, they need to overcommunicate, demonstrate passion, and offer inspiration. That doesn’t mean that they need to tell developers what to do.

Zuckerberg — rightly, I think — demonstrated great reluctance to tell people what kinds of applications to build. But platform owners need to say, “Together, we are going to build something amazing! What’s more, it’s going to be fun! Developers of the world, to me! Now, here’s how this is going to work…”

Apple has every right to take baby steps with the nascent developer community forming around the iPhone. But in the process, they can make the road less bumpy for themselves by offering an unprecedented opening of the kimono.

I’m not holding my breath — it is Apple, after all. But even a statement as simple as, “we want to take it slowly because of x, y, and z,” would be sufficient.

A recent post on the Facebook Developers blog explains that application developers will soon have to contend with a new notifications system designed to cut down on application spam.

Under the old system, all applications could send a user up to 40 notifications a day. Under the new system applications whose notifications get more click throughs will get more notifications to send. Those whose notifications are frequently marked as spam will get less. In short, it’s like Akismet for notification spam.

This is a relatively huge development in making Facebook more user friendly once again. I’ll be excited to see how it actually works in practice, and how developers react — both in attitude and in tactics.

I know a lot of App developers have designed their applications to require that users invite some number of friends to the app before all (or even any) of the features in the application will be unlocked.

This is one of those strategies that works according to the data, despite the fact that it’s clearly more antagonistic. If you’re just looking at the numbers, it seems like developers have to make a choice: ingratiate themselves to their users and retain a smaller number of loyal installs, or annoy their users and get a far more viral spread.

Alec Saunders recently threw together some rough data that supports the gut feeling you already have: forced invites aren’t liked by Facebook users.

I think the choice you make as a developer should depend largely on what type of app you want to develop. I mentioned in my earlier post that there are at least two fundamental different approaches to building facebook applications:

1. Building an application as a product or service
2. Building an application to promote your existing product or service

At this point, it should be obvious where I’m going. If you’re trying to build an application that needs to support itself on ads or other revenue models, and you need a large if transient audience, I’d say that forcing user invites is the way to go.

If you’re trying to build an app to promote your brand, you should take pains to make sure that the way you market the app (not just the way it works) reflects the image you want potential customers to walk away with. I think that means holding off on the forced invites.

According to both Mashable and The Social Times today, MySpace has finally announced that they’re going to be launching their own developer platform on February 5th. From Mashable:

Earlier this evening, I spoke with Amit Kapur, who the company is also announcing has been promoted to Chief Operating Officer and will oversee the platform. While MySpace may be a little late to the platform party, it’s clear that they have been closely watching developments in the space and will be addressing many of the growing pains that chief rival Facebook has dealt with from the get-go; most notably privacy, monetization, and data ownership.

And additionally:

This means that unlike Facebook, where we have dozens of ad networks competing for inventory on applications, MySpace may play an active role, presumably utilizing its large ad sales force to help developers get premium revenue.

I think that MySpace is being really smart in their approach to the platform. It’s clear they’re not the first players in this game, but they’ve really paid a lot of attention to where Facebook is fumbling, and it seems like they’ve keyed in on the issues with monetization, assuming that they can attract developers with simpler (and they hope more effective) revenue models.

That’s true in a lot of cases, but I think that development on all of these social platforms going forward—Myspace, Facebook, and Open Social—will see a rise in applications designed less to be standalone, moneymaking ventures and designed more to replace the advertising and exposure that are already trending down in TV and other traditional media.

In other words, I’m not sure that application developers going forward will be looking first to monetize their apps. It may be something that they choose to do, but I think a forward-looking platform should design tools to help maximize brand exposure.

We just posted a sample Facebook Application Spec on our Parnassus Group site.

Developing an app spec can mean a lot of different things to a lot of different people. When we draw up Facebook Application Specs for our clients, what we deliver is a document that any competent developer should be able to use to build your application with few or no hanging questions.

In other words, it’s a complete blueprint.

If you’re hiring someone to create a Facebook App Spec for you, you should make sure that both parties are clear on what you’re going to be given: is it going to require some refinement on your part, or is it going to be something that you can hand off to a developer?

I’d recommend checking out our sample spec for an example of what you should expect.