Source: saunderslog.com

Inside Facebook reports on the recent changes made by Facebook in how developers can use "requests" and "notifications".  In principle, these are welcome changes designed to combat invitation spam, and when combined with the recent ban on forced invitations, they should make the experience of the Facebook platform better for everyone.

Requests are the ubiquitous invitations that every Facebook application sends.  They can be used for any kind of communication which demands a response from a user, and are commonly used by applications to invite friends to install the application.  Notifications, by comparison, demand no response from the user.  They simply appear in the users notifications list.

Previously, users of an application could send up to 20 requests and 40 notifications in a day.  Under the new rules, the allocation of requests and notifications is dependent upon the proportion which are ignored or answered.  An application which sends too many requests that aren’t responded to will find the number of requests it can send reduced.

iotum’s FREE Conference Call application can be thought of as an event coordination application where the event takes place on a conference bridge.  As such, we created the application to consciously mimic the Facebook Events application, because we wanted a familiar experience for users.  The Events application uses requests to invite users to events, and so do we.

There are some differences, however.  Facebook Events is an application which is installed by default in the users profile.  Our application isn’t.  Therefore we also use requests to invite others to use the application. And that’s where the problems start to become apparent with Facebook’s new rules.  Requests in our application have to do double duty — inviting friends to use the application, and inviting users to participate in events.

Not all of our requests get answered, primarily because users prefer to answer those requests in many different ways.  We allow requests to be responded to via an iCal response (so the meeting is automatically inserted in the users calendar) or via email, as well as the RSVP that the request demands.  It’s not uncommon for 80% of the requests we send to be ignored.

As a result, our request allocation, which was a problem when capped at 20, is now dramatically lower.  It has been varying between 5 and 8 allowed per day, which makes it exceedingly difficult to organize anything but a very small meeting.  Now, we’ve implemented various workarounds, such as "sharing" an invitation in email with groups and friends.  But honestly, these are oddball extensions and workarounds, and different from the experience that users expect.

By contrast, a Facebook event can invite as many people as the organizer wishes.  It’s not uncommon for 80% of invitations to an event to be ignored, similar to what we experience with our application. But there is no penalty for ignored invitations to a Facebook event.   Facebook developed applications don’t play on the same playing field as third-party applications.

This will remind astute readers of another platform player, Microsoft. Dogged by charges that it unfairly advantaged its own applications, the ill will created between Microsoft and its developer audience was so intense in the 1990’s that the company ultimately ended up in court on anti-trust charges.  Whether true or not, tbe perception that the company treated itself differently from other developers was very harmful.  Facebook isn’t Microsoft, obviously, but the value of having a good relationship with the developer community can’t be understated. 

To be clear, I’ve no wish to see a return to the days of invite spam that this new measure was designed to combat. Those were bad days.  I’m simply asking that Facebook view future changes to the platform through this lens:

Could Facebook deliver their own applications using the APIs they give to developers, and within the rules they have imposed on developers?

If the answer is no, then perhaps there is a more developer friendly solution than the one being contemplated.