Live data from Hacker News

I’m done building Facebook apps for clients

ryanwaggoner.com

11–20 of 77 posts

Re: I’m done building Facebook apps for clients

#11
post #3

I recently ported my app back to the old Javascript API; I wish I could say that it was for the superior older documentation, but it was actually because the new API randomly stopped returning my calls from time to time. All of the big moneymakers' apps are built on the older stuff, so I figure when it breaks, it gets a bit more love. The documentation is still shoddy, the Bing-powered documentation search is abysmal…

More than once, when I searched the documentation, the top result was a link to the very search page I was on.

Re: I’m done building Facebook apps for clients

#12
He's right on the money. The documentation is horrible. The 1 app I wrote that used the Facebook APIs convinced me never to do so again. Even the simplest things required hours and hours of effort, mostly by trial and error, just to figure out the important details that the documentation left out.

Re: I’m done building Facebook apps for clients

#13
I like how Twitter has versioned their API, and I wish Facebook would do something similar. With 500+ developers and deep knowledge of backend changes, they should be able to handle the minor discrepancies instead of off loading that burden to platform developers.

Re: I’m done building Facebook apps for clients

#14
post #3

I recently ported my app back to the old Javascript API; I wish I could say that it was for the superior older documentation, but it was actually because the new API randomly stopped returning my calls from time to time. All of the big moneymakers' apps are built on the older stuff, so I figure when it breaks, it gets a bit more love. The documentation is still shoddy, the Bing-powered documentation search is abysmal…

Part of their new 'commitment' to developers (Facebook apparently created an internal Games team several months ago) is a stated paradigm shift towards more and better documentation, but it seems so at odds with the way things are currently done that I'm pretty skeptical.

It does seem as if someone over there is aware that the current situation is pretty awful, at least enough to say "we're working on it".

Re: I’m done building Facebook apps for clients

#15
I found at times that I got more info from the depreciated wiki than any form of new documentation they had up, and my use case was pretty damn simple, just implementing a half decent usage of facebook connect which runs with SSL and plays nice with a modified wordpress user system.

I found myself at times resorting the trawling through js source to find how I could use certain button images that were very simple in the old version.

I feel your frustration and am glad I don't really have to do much in the facebook space at the moment.

Re: I’m done building Facebook apps for clients

#16
post #13

I like how Twitter has versioned their API, and I wish Facebook would do something similar. With 500+ developers and deep knowledge of backend changes, they should be able to handle the minor discrepancies instead of off loading that burden to platform developers.

The Twitter API is excellent in comparison, I guess in a way the newer Facebook API drew a lot of inspiration from it. Problem is it was rushed out and judging by the article and comments left here not much has happened documentation wise in the last 3 months or more since I last touched it.

Re: I’m done building Facebook apps for clients

#17
I think the issue Ryan mentioned with FB is a general issue these past several years with more than just FB's API and documentation. Everyone seems to be more sloppy these days. People call their processes agile, throw in a task manager, throw tasks into it willy nilly, and call that process.

Hiring a tech writer and sending your lead dev to scrum school won't help either. You need to value good work at work. If you're too busy worrying about how to skim by with less money or worried about losing your employees, you're too distracted. Work with fewer people, get less done, but make sure you do it right! Why do people need a primer on this? It is just common sense.

Re: I’m done building Facebook apps for clients

#18
post #9

I think they do this on purpose - rapidly changing apis, and having poor or overly verbose documentation is a way to weed out all but the largest development companies, thereby reducing support costs, and allowing partnerships with the big companies that survive. It's right from microsoft's playbook.

Instant personalisation helps to give this impression, that they are working very closely with bigger players who can get regular contact with those at Facebook to know the API inside out and get notified of changes as soon as they happen.

Re: I’m done building Facebook apps for clients

#20
Their iPhone Facebook Connect documentation is beyond atrocious. What little there is was written by someone who, besides not being a non-native English speaker, also does not care about getting things right.

Several people have mentioned how bad the documentation is, but nobody has provided examples. In case anyone from Facebook (or "facebook" as it's sometimes called in the docs) reads this and cares, I'm putting some examples from the docs below.

The problem with having mistakes in the docs, is that as the reader notices more and more mistakes, they begin to have less and less confidence in everything that is written there. Once the documentation is suspect, every word in it is suspect.

Here's an example of a sentence lifted from the docs: "i whose fields and values can be inspected and accessed."

Yes, that was the entire sentence, if you can call it that.

How about: "Application can implement these interface to handle them."

Seems like a small error, but a more important message is given to the reader: You cannot trust this document.

Just to preempt an obvious reaction, yes, you shouldn't trust any document, but there are levels of trust, and this kind of grammar makes the trust fall quickly to a very low level.

Another one: "The FBSessionDelegate is a callback interface that your application should implement: it's methods will be invoked when the application successful login or logout."

Same message there. You can't trust this.

Then there are the code examples. Here's their example of how to use something the docs call a stream.publish flow:

NSMutableDictionary* params = [NSMutableDictionary dictionaryWithObjectsAndKeys: apiKey, @"api_key", nil]; [facebook dialog: @"stream.publish" andParams: params andDelegate:self];

Ignoring the bizarre inconsistent use of spaces after colons, this example gives no clue about what else should be in the params object in order to make a publishable post. I could look it up on the Facebook developers (sic) site, but that data can't be trusted either since it changes so frequently and so little care is given to getting it right.

Post reply on HN