≡ Menu

A gentle criticism of F8

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. 

{ 2 comments… add one }

  • Brad Templeton February 29, 2008, 4:44 pm

    Everybody of course will want their app to be the exception. Now you make a case for fcc, and I think facebook events is a very justified exception, be it written by FB or not.

    So they could set up a board of exceptions, and then people could apply for one. The board could review the app, and judge if it obviously should have a higher limit. Or it could judge it does not get a higher limit but was a reasonable request. Or it could judge that the application clearly didn’t understand the rules and in that case give it a _lower_ limit to avoid having everybody submit their app for an exception.

    Another option would be to let users do a “forceful reject” of a feed item or notification, and punt those apps (even if facebook written) to a lower quota. So just ignoring hurts your quota only a little, while saying “go away” hurts it a lot.

    (Of course this could cause app wars, as developers of one app deliberately use and reject its notifications. You could also punish users who get forceful rejections, though people would just create bogus accounts for this)

    But I am not sure you are that special, because notifications are a big thing, they get emailed to me.

    So for example it is appropriate to notify me if I am invited to a conference call for work etc. But if it’s just a “hey, you might find this cool” then it should not be a notification. If it’s a “We’re doing a demo call to promote our app” it should not be.

    If you’re inviting lots of people to squawk boxes who are ignoring it, you should indeed be cutting back, for example.

  • Alec February 29, 2008, 6:02 pm


    I’m really not in favour of boards and exceptions. If there was a provision for different categories of apps to be able to use the API in different ways, then that might work. But boards and exceptions really aren’t scalable solutions.

    The root cause of this problem is that requests for users to take action that originate from within the app and requests for users to install the app are indistinguishable. If there was a distinction between these two categories invitation, then that might go part way to resolving the issue.

    I also think that the measure of allowing users to more easily block apps that they don’t want to hear from (already implemented) will likely cure the worst of the spammy apps.

    re: notifications and requests coming from FCC, we’ve never been able to invite large numbers of people to a call. We worked around the restriction by allowing people to invite members of a group, and then we encouraged people who WANT notifications to sign up for the group. Heaven help us if the calls ever become super popular, though, because then we’ll run into the restriction that prevents you from sending email to groups that are larger than 1,000 people. The only time I ever invite a specific individual to a Squawk Box is when I feel that that individual might have a valuale contribution to make. I simply can’t afford to “waste” a real invitation on someone who might not show up.

Leave a Comment