Filed under: apps, press — kevin @ September 4, 2008

Context Optional has received press coverage for a number of the branded Facebook applications we recently launched, including a couple pieces in Inside Facebook and a piece this week in The Social Times:

Inside Facebook: Context Optional Releases New Facebook App-vertisements

Inside Facebook: New App-vertisements from Microsoft, Miller, and Absolut

The Social Times: The Booming Branded Applications Industry

Filed under: apps, facebook, marketing — kevin @ August 29, 2008

Context just recently launched engaging applications for five major brands:

Kraft One Minute Mogul: Oscar Mayer has a new line of delicious sandwiches – so good that apparently once you try them you’re hooked!  So Kraft and Ogilvy worked with Context to build an social game on the Facebook platform that encourages trial through coupons.  It’s a very innovative approach to tying online viral marketing to offline store purchases, and we’re excited to see how it goes.

Travel Channel Kidnap!: Travel Channel wants to use a Facebook application to drive traffic to their site, which is always a challenge (people love Facebook, why ever leave?).  So Travel and Rapp Collins worked with Context to build a social game where users kidnap their friends to far off places – and in order to escape the hostage must answer a question (then answer for which can be found on Travel Channel).  The app includes sophisticated Flash and heavy graphics to meet Travel Channel’s branding guidelines and has seen significant growth since it launched a couple weeks ago.  Try to escape!

Absolut Top Bartender: Absolut launched its Facebook page for Absolut Top Bartender.  In partnership with NBC, Absolut is sponsoring a series of 5 events in 6 key US markets - New York, Chicago, LA, Miami, San Francisco, Las Vegas - in a search for the best bartender.  NBC will film and distribute the real world competition, and all online activity - bartender registration, event organization and promotion, and voting for the best bartender - will be managed by Context using Facebook applications we built for Absolut’s page.

Miller Today I’m Toasting: Miller was looking to engage young people online in an interactive and social way.  To meet their goals, Miller and Digitas worked with Context to design and build a toasting application that celebrates everyday with fun random holidays.  The application is one of the first branded alcohol apps to launch on Facebook that uses Facebook’s age-gating technology, limiting interactions with the app to those over 21.  Did you know that today is Less Salt Day?  I’ll toast to that!

Microsoft Got Pies: Microsoft launched its fourth Facebook app with Context, this one called Got Pies to promote IE8.  IE8 includes a new web slices feature, which allows users to monitor content on websites via the toolbar.  The app allows users to create ’slices’ (in this case slices of pie) and share them with friends, as well as see updates to their friends’ slices via a ‘virtual webslice,’ and for users of IE8, monitor the most popular user-created pies via an actual web slice.

Enjoy!

Filed under: apps, facebook, marketing, press — kevin @ July 7, 2008

Over the weekend the San Francisco Chronicle wrote an article on brands moving onto Facebook - and started the article with reference to the Office Poke application we built for Microsoft:

Throw a stapler at a Facebook friend, courtesy of Microsoft Office. Become a fan of Victoria’s Secret Pink to discuss favorite bra colors…

The full article can be found on SFGate.com.

Filed under: apps, facebook — klep @ June 18, 2008

As you’ve probably heard, Facebook is making several changes to the Platform next month. The new user profile has won most of the attention, but the changes reach a lot further than that. Facebook is continuing their campaign to reduce app spamminess and app fatigue by making low-level changes that alter the way that users interact with and spread applications. We’ve looked at these changes in depth and are sharing our point of view with our clients and readers.

User Profile Functionality

The most visually noticeable upcoming change is the new user profile. Profiles are becoming more action-focused. A user’s current profile is largely made up of application profile boxes. We used to pitch profile boxes as one of the main reasons for building a Facebook app — Your brand can have a visual presence right on a user’s profile. We’ve discovered over time that despite this appeal, profile boxes are one of less importance than one would think. Facebook users are less likely to view their own profile as they are to view a friend’s. Our statistics and reporting engine has told us, with almost every app we’ve built, that the profile box itself draws far less new user interaction than feed items and user to user communication channels.

It’s a good thing that profiles aren’t the main driving force behind app usage, because they’re about to get much less prominent. Most apps currently focus their efforts on the “wide” area of a user’s profile (who wouldn’t want more space to use?). In the new profile design, the main profile page doesn’t have a wide area for applications — there is only a narrow column that is now limited in height. Only a handful of apps are displayed there; the rest are placed on a separate overflow “Boxes” tab. The upshot is that apps should focus more on their narrow appearance and be prepared to be relegated to the less-traffic’d Boxes section.

There is, however, a new feature available to applications that wish to manifest themselves on profiles. An app can optionally be capable of having its own full tab. Apps with tabs have much more functionality available than profile boxes provide. Profile boxes are a cached, static view of an application. A full tab has more interactive possibilities. The downside is that users must explicitly create a tab for an application, and there is likely to be a limit on how many they can create. The decision for a brand creating a Facebook app is whether the relatively small number of users who will grant your app a full tab is worth the added cost of a developing a full tab view. Our recommendation is to wait until we get a sense of how users are interacting with this new feature.

Feeds

Feed items are also being re-evaluated, with completely new APIs for developers to use. Optimizing the design and utility of a feed item has always given us an opportunity to make an app viral by knowing what works. The new functionality further recognizes the importance of building feed items that are relevant, flexible, and have appropriate calls to action. Users will be able to choose a one-line or short version of a news feed. In a trend that is seen in other new features as well, an app will be able to request special user permission for a more flexible full feed item.

Sessions

Apps are often judged by how their number of installs (or often by “downloads”, which is a misnomer). Facebook shied away from this measure early on. When the Platform first launched, they revealed the total number of users as a public statistic, but soon changed it to “Daily Active Users”, a measure of engagement instead of reach. App developers didn’t exactly follow suit — an install was still the holy grail of user interaction. Once a user installed an app, a large number of permissions were automatically granted, including accessing profile data, sending notifications, and emailing users directly.

Facebook has encouraged developers to allow users to get a taste of an application before requiring them to install. Public app pages appear in search results and feed items are more likely to show up in news feeds if they point to public pages. Despite these two big incentives, most developers still decided to require users to install their app even to do basic interaction. Now Facebook is forcing the issue — an app will not be able to require installation initially. Instead, it will require a much ligher app login, which will grant some permissions but not the full set of permissions granted by an install. Apps must then decide at which point in the user flow they should offer to promote the user to a full install.

Our take is that this is good for the platform, so it’s largely good for brands as well. Users will be less likely to worry about what an app will do on their behalf if they have this simple no-obligation way of interacting with the app. It does, however, change some of the long term decisions for the app. Many brands are looking at apps as a way to conduct a campaign that eventually turns into an email list. Instead, it’s to their advantage to continue to engage those users on Facebook by introducing new content or campaigns. Ultimately, it will be easier to get a larger number of brand impressions, but more difficult to get long-term users. That’s why we’ll make sure that every app is compelling enough that users will want to go to the full install.

Other Upcoming Changes

There are less-discussed or less-defined changes coming. Apps will be able to post new items to a user’s personal information section (with the user’s permission). For example, a branded app for a soft drink might ask users which flavor is their favorite. Their profile would be edited so that in addition to their favorite quotes and favorite movies, it would display their favorite flavor. There are also visual design changes that give apps some new functionality with a lot more room to display their content.

Existing Apps

Apps that are built on top of Context Optional’s Social Application Server will continue to function, unmodified, with the new features. Since permissions are changing, some individual application features may change in behavior (for example, apps that email users would have to be modified to ask permission). We are actively testing our apps with the new features and we’re also encouraging our clients to talk to us about how they can leverage the new features to their benefit.

Filed under: apps, marketing — kevin @ June 15, 2008

People often ask about the differences between widgets and applications. Widgets are typically stand-alone pieces of embeddable code. Widgets are great for viral marketing, as users can cut and paste code from a widget to embed on their own site or blog. Widgets were all the world had until May of 2007, when Facebook launched their Platform, and applications were born.

Applications tie into the social communication channels of the host social network, such as Facebook, MySpace, hi5, or Bebo. Typically applications can’t be cut and paste outside of the host social network, but within the network applications are very easy to share. Applications allow for more interactivity, as they operate as full websites within the host environment.

Some typical differences between widgets and applications-

WIDGETS	APPLICATIONS
Widgets are primary for self-expression	Applications are about being social and communicating
Widgets are stand-alone	Applications are integrated into social network platforms
Widgets live anywhere and work on any site	Applications are at their best when deeply integrated into the host site
Widgets are easy to grab and share via embed code	Applications are easy to share via communication channels inside the social network
Widgets leave brands exposed to user-generated content	Applications typically have control of the full-page where the application resides
Widgets are typically small bits of content that act as teasers to lead to other content	Applications are at their best engaging and all encompassing, not requiring a visit to another site for a full experience
Widgets spread when users grab code and post the widget on their own page	Applications spread through sharing within friend networks (typically 5-10x more viral than widgets)
Widgets are best when the focus is on photos, video, music	Applications are most successful when focused on friends, text, interactive games, and interesting content

Filed under: apps, facebook — klep @ June 12, 2008

We sent Kevin to Graphing Social Patterns East in DC mainly so that we could throw a tiki party in his absence. Imagine our surprise when he ended up giving a terrific presentation on Viral Marketing and Advertising Strategies for Social Networks that got a great audience response and was featured on the front page of slideshare.net!

Kevin’s presentation covers the background rationale behind bringing brands to social networks and explains the different strategies for successful social marketing campaigns. It’s even better with Kevin’s comical and engaging delivery, so contact us if you’re interested in bringing your brand to social networks.

Filed under: apps, facebook — klep @ January 30, 2008

Over the last several weeks, Facebook has gradually announced major changes that all point to a new phase in the Platform’s life. While some developers bemoan some of the more restrictive changes, I think they are more likely to help developers that write good applications.

Restrictions on Cross-App Promotion

The new year introduced the first subtle shift in how Facebook dealt with spammy applications. Previously, Facebook would announce new caps on viral features that were easy to abuse. Hard limits were put on notifications and requests, for example. With the January 1st announcement, Facebook took a more proactive approach in looking at how specific spammy applications were circumventing these limits and making more complex changes.

The problem they were addressing was that companies that try to cross promote applications were treating a user installation as a license to send notifications and feed items regardless of whether they applied to that application. For example, a user would install a movie app and suddenly be receiving notifications and sending feed items about completely unrelated apps. The users were being treated as extra spamming capacity.

Facebook’s changes to prohibit such behavior is a big win for applications that are useful and compelling on their own. By cutting down on overall noise and providing users with more assurance that installing an application will not immediately result in random things appearing on their profile, the acquire-users-at-any-cost apps lose a round to the useful apps.

Limiting Profile Boxes

I’ve heard two explanations for why Facebook is forcing users to choose a subset of their applications to show on their main profile page. The stated reason was that users appreciate the simplicity and cleanliness of Facebook, and applications were creating clutter. That may be so, but why not let users decide whether or not their own page is cluttered? If apps are just an ugly nuisance, why have them at all?

More likely, there was also an element of performance issues on profile pages with many applications. Facebook caches profile boxes on behalf of the application — a major advantage of the Facebook platform over OpenSocial. However, once you have 20+ applications on your profile, you have a huge page. Since the profile boxes are cached, the app developer has nothing to lose by including lots of graphics and text. Facebook pays the bandwidth cost, and it seems they were growing somewhat tired of that.

The upshot, regardless of the reasons, is that this has caused us to re-think the profile box and its purpose. Now that apps are competing for space on a user’s profile page, it forces app developers to really think carefully about what goes there. Instead of creating a profile region that simply shows the user’s status with the app or tries to get their friends to add it, the apps that will retain a place on the profile will give a more interesting set of interactive options for both the owner and the viewer. The change has also made us question whether profile regions are always applicable. There are certain classes of applications that may no longer want to bother with a profile box if the odds of being relegated to a secondary page are high.

Restrictions on Misleading and Passive News Feed Items

Along the lines of the deeper spamminess controls described above, Facebook also announced some further abuses that would be prohibited. Apps were misleading users into interacting with them by implying that they had a “message” waiting. The word “message” is no longer allowed, and I look forward to seeing what synonym of message is banned next. To be honest, I thought it was a joke when this was announced — why the word message? I’m guessing that there were some very specific misleading feed items that they wanted to block by issuing a blanket policy, but my hunch is that this particular change won’t solve the problem for long and instead we’ll see Facebook enhance the Registered Feed Items system so that they have control over individual apps sending large amounts of feed items.

Similarly, passive feed items (”Frank was kicked in the face”) are now a no-no. The tricky part of this is that if the action actually happened (a friend of Frank’s used the app to kick him), the feed item is legit. Abuse of this style of wording, however, has restricted the feature so that feed items can only be sent on behalf of the person interacting with the app (”Joe kicked Frank in the face”).

I can’t really put a positive spin on this loss of functionality, except that it means less noise in new feeds. The real shame is that all good Facebook apps are about people interacting, and now you can only send feed items when each user explicitly performs their part of that interaction.

Batched API Calls and JavaScript Client Library

Facebook continues to show technology leadership with the Batch API and JavaScript API. These innovations both show that Facebook is responsive to the different ways that developers want to interact with the platform. Unfortunately, there’s a lot of confusion about the JavaScript API right now, but I think that’ll settle down once people realize that Facebook did not just join OpenSocial!

Application About Page

As one of the first developers to take advantage of the Pages API (for our project with OpenTable), I was pleased to see that application About pages are now Pages with a capital-P. When the message went out announcing it, I thought somebody made a mistake and sent out a draft by mistake — the announcement started:

Starting tonight, we are converting Facebook Application About pages to use the Facebook Pages infrastructure and format.

It sounded like waaay too big of a change to happen with mere hours notice, but the transition went smoothly. I think Pages got ignored during all the hubbub over Beacon, so I’m glad to see them become more prominent. As Pages get more use, we’ll see more utility-like applications for Page authors to promote and construct their pages, much like our own SuperShare application, which I wrote in a few hours after a friend expressed his frustration over the tiny little “share” button on Facebook.

What’s the Real Goal?

Several months ago, I was talking to someone who invests in Facebook-related companies and I casually mentioned how it seems that Facebook releases these small changes that sometimes seem inconsequential, but when you look back a while later, you can see that there was a goal that it was all building to. He asked me for an example and I felt dumb because none came to mind! But now I’m vindicated because I think when we look back at a January full of tweaks to feed items, profile changes, and new APIs, we’ll see that the real goal was in bringing the Platform out of its “let’s acquire users as rapidly as possible” phase and into “let’s really build interesting applications” phase. As a Facebook developer, I couldn’t be happier about that direction.

Filed under: apps, facebook — klep @ November 8, 2007

Working creatively with APIs is one of the things that makes software development fun. APIs exist mainly to allow third parties to add functionality to software that the original authors don’t have the time, interest, or creativity to do on their own.

Most APIs are built to limit functionality, or more kindly, at least to encourage certain types of functionality over others. For about a year, I wrote software that worked with the iTunes API, which can be summarized as follows:


getTrackTitle();
getArtistName();
play();
pause();
stop();
nextTrack();
previousTrack();


The iTunes API was clearly designed by committee. A bunch of people reserved a conference room with the noble goal of designing a way for other programs to interface with iTunes. They ended up talking about all the things that they had to prevent other applications from doing. Most likely, the concerns they enumerated included usability, security, piracy, loss of control, loss of revenue, and ongoing support.

As a result, most applications that use the iTunes API are glorified remote controls. The deeper integration that you see in products like our SpotDJ Classic and iLike are, put simply, total hacks. We used the APIs in ways that it was neither designed or intended for. As a result, we spent a lot of time futzing with undocumented hacks and less time building great new features.

When I start looking at a new API, I generally begin with two things. First, what do the sample apps do? Second, what are the API calls? Most of the time, this gives me a pretty good sense of what the designer intended. When the Facebook platform was released, it only resulted in more questions. The reference app for developers was called “Footprints.” It was an app so simple and uninteresting that I don’t even remember what it did. It largely served to educate developers about Facebook’s novel approach to developing add-ons for a web site — specifically, a REST-based API to obtain information from the service with a custom query language and a homegrown markup language to leverage the existing user interface and functionality of the site. The documentation was sparse, and completely unwritten in some points. It failed to answer basic questions like “What is a ‘wall’? How do people invite other people to use my app? What’s the best way to do X? Is it okay to do Y?”

Whether by design, through evolution, or just happy coincidence, the Facebook API inspires rather than limits. Instead of sitting down and making a list of use cases that they wanted to prohibit, the Facebook developers most likely listed the different parts of their system and brainstormed how to expose them to developers. I’m sure that examples of possible applications were discussed, but the smartest move was recognizing that the truly valuable applications were the ones that Facebook itself hadn’t yet thought of.

When we work with clients on Facebook applications, one of the approaches we use, either internally or with the client, is to focus on a particular part of the API and brainstorm ways that it could be used for their application. Note that this wouldn’t work so well for an API like iTunes (”Let’s do something really unique with pause();!”) but it works quite well with the Facebook API (”What do feed items mean for a game?” “How can we use a profile action to encourage replay?” “How will users want to stay connected via the mobile API?”)

As the API has grown and thousands of apps have been released, best practices have emerged along with novel implementations that stretch the boundaries of the API and inspire developers to further explore what’s possible. At the same time, a developer community has built out documentation, frameworks, and guidelines that Facebook itself supports and encourages. As other networks release their own APIs or implementations of OpenSocial, it will be interesting to see which ones limit their developers and which ones take the less prescriptive approach and really foster creativity.

Filed under: apps — kevin @ November 7, 2007

Smarty Pants, the first trivia game for the Wii, can now be played on Facebook. Ok, sure, it doesn’t include all the questions and it doesn’t have all the fun dancing and hand-waving antics of the full Wii game, but it’s still addicting.

Try challenging your friends to a few rounds of questions and see who’s smarter! You won’t be able to stop. And don’t forget - answering quickly gives you more points, and more points means more more smarty pants for your profile!

Filed under: apps — kevin @ November 6, 2007

OpenTable launched an OpenTable Facebook application that lets Facebook users make dinner reservations directly from Facebook restaurant pages. For example, check out the restaurant page for Junnoon Restaurant - next to Facebook’s headquarters in Palo Alto.

In a couple steps users can quickly and easily make a reservation for Junnoon, and no OpenTable account is required (although you should sign up to earn Dining Points!). Also, reservations are automatically added to the news feed and shared with friends. We were excited to work closely with both OpenTable’s API and Facebook’s Platform team to get this application out in time for today’s announcement in NYC.

We hope you enjoy using the application!