What I found most interesting about the new feature was its endlessness.  If you do “Like” a Recommended Page you are not sent to its landing page, but stay on your home News Feed.  Within seconds, the “liked” page fades away and is replaced by a new band, movie, brand, etc. that you’ve loved for years.  If you get tired of “liking” every pick Facebook throws at you, you also have the option of removing a recommendation.  In which case, a new winner pops right up.

I find this perpetual perfectness of picks to be addicting, and I don’t think I’m the only one. This is great news for page managers of any kind.

Before this change, Pages were only able to recruit new ”people who ‘like’ this” through person-to-person interaction.  You had two options:

1. invite your friends to a page you “liked”
2. notice a page your friend “liked”–either on your News Feed or on their  personal profile.

If you didn’t have a friend who had already “liked” the page, you would not be able to “like” it yourself unless you searched for it.

By adding Recommended Pages, “likes” are now generated through what could be called public-to-person interaction.  The pages recommended to you are not only things your friends “like”, but also pages specific to your current likes and interests. These pages are decided by the actions and overall behavior of Facebook’s 400 million users. Recommended Pages are in-your-face, accurate, and seemingly infinite.

What does this mean for businesses, bands, and celebrities?  It means an influx of “likes” from a demographic most suited to liking your product, music, or career.  It means customers and fans more likely to be influential brand advocates. Most importantly, it means constant, incredibly-targeted marketing that doesn’t cost you a dime.

How much of an effect do you think Recommended Pages will have?  Do you find them intriguing or annoying?

Preface

In part 1 of this tutorial we walked through obtaining an oAuth 2.0 access token from Facebook via an iPhone (or any iTouch device).  If you wish to go back and review the oAuth 2.0 process in some detail HERE.

Facebook Login and Extended Permission Dialogs

In the second part of this tutorial I’ll show you how to leverage my pseudo-API to:

• Login to Facebook using oAuth 2.0
• Request extended permissions for your mobile application (photos, videos, publish stream and offline access)
• Get your profile data
• Get your friend list
• Get your feed
• Post to your feed
• Post a photo (via a local image (UIImage) not a url)
• Get metadata
• Delete a feed post (via a Post)
• Get search results
• Get (and display) the author’s avatar

Convention

There are 2 APIs being talked about in this tutorial. To avoid confusion, I’m going to refer to them consistently as Facebook’s  ‘Graph API’ and my ‘pseudo-API’*.  Facebook’s Graph API is the stuff we’re interacting with via HTTP Get and Post calls.  The pseudo-API is the Objective-C/iPhone code that’s facilitating the interaction.

*-I call it a pseudo-API if for no other reason I haven’t proven to myself it supports 100% of the Facebook Graph API functions.

An aside about my API design philosophy:  I could have written the pseudo-API to be much more robust and feature rich, with exceptions, logging, auto-magical json parsing, full featured functions like ‘getMyWallFeed’, etc.  However with robustness and features comes complexity and dependencies.  I kept everything aside from the absolute core functionality required to read/write data from/to the Facebook Graph API out of this implementation.  In short, I’ve left it primitive enough that anybody should be able to extend/wrap it easily, if they see fit.

The pseudo-API has only 3 classes.  The core functionality lies in the FbGraph.m file.  The other two classes support this core class.  FbGraphFile is used when uploading a file to Facebook.  FbGraphResponse is, I would hope, self-explanatory.

We’re going to skip over the steps required to create a Facebook application.  I covered that in Part 1:  iPhone, Facebook, oAuth 2.0 and the Graph API.  A Tutorial.  If you completed part 1 of the tutorial, you can use the same Facebook application without modification here.

Sample Code:

http://github.com/reallylongaddress/iPhone-Facebook-Graph-API

Creating the FbGraph Object

Before we can interact with the Graph API, we need to make a connection to it. And before we make a connection to it, we need a FbGraph object instance.  We do so like:

self.fbGraph = [[FbGraph alloc]initWithFbClientID:client_id];

Where:

FbGraph *fbGraph;

And

NSString *client_id = @"123145257717248";

The client_id should be YOUR Facebook application id.  I’ve left my application ID in here for no other reason than the tutorial code will work ‘out of the box’.

The login process

Now we have our fbGraph object instance, we’ll want to ask Facebook for a login screen.  Additionally we’ll need to let Facebook know the extended permissions we’re requesting for our app.  Here’s the code to do that:

[fbGraph authenticateUserWithCallbackObject:self andSelector:@selector(fbGraphCallback:) andExtendedPermissions:@"user_photos,user_videos,publish_stream,offline_access"];

There are 3 major things to note in this line (found in oAuth2TestViewController).

1)  We’re asking the fbGraph object to initialize the authentication process by calling the function: authenticateUserWithCallbackObject

2)  We’re setting a callback object (self) and a callback function (fbGraphCallback).   This object and function will be called upon completion of the oAuth authentication process.

3)  We’re requesting extended permissions:@”user_photos,user_videos,publish_stream,offline_access”

When this function is called, the pseudo-API will find the root application window**, stick in a UIWebView, and ask Facebook for a login screen (passing along your client_id and requested extended permissions):

NSString *url_string = [NSString stringWithFormat:@"https://graph.facebook.com/oauth/authorize?client_id=%@&redirect_uri=%@&scope=%@&type=user_agent&display=touch", facebookClientID, redirectUri, extended_permissions];

**-There’s a second authenticateUserWithCallbackObject function that allows you to specify a specific view you wish the login screen to be anchored/rendered in, if you don’t want it to render within the root view of your application.  Look at the FbGraph class for further details.

Note the ‘display=touch’ parameter.  It tells Facebook we’d like a login screen optimized for an iPhone/iPod touch screen.

Now that the process is started the UIWebView will render the login window that Facebook has returned to us.

After you’ve successfully authenticated to Facebook, you will be presented with a second screen with an extended permissions request dialog.  2 things to note here:  First, all permissions are unified into a single step.  Second, after you’ve approved the permissions, you won’t have to complete this step or see this screen again (so long as you don’t revoke the permissions).

Under the Hood of the Authentication Process

There’s some http redirects involved with the oAuth 2.0 (User-Agent flow) login process.  The FbGraph object is a UIWebViewDelegate, one of the functions associated with this delegate class is: webViewDidFinishLoad.  This function is called several times during the authentication process.  When the URL contains “access_token=” we’re golden.  We’ve successfully logged into Facebook.  When the pseudo-API sees this string, it parses out our oAuth access token, stores it to a class level variable, removes the UIWebView we inserted and finally calls the callback function we defined, returning control to your application.

The Rest of the Pseudo-API

The core of the pseudo-API is about 250 lines of code (including whitespace and comments), which is very little indeed.  This is possible because the Facebook Graph API does everything via simple HTTP Gets and Posts.  In fact, once you’ve figured out how to do Get and Post with the Graph API, you’ve pretty much figured out everything.

If you’re familiar with the current Facebook Connect implementation, you’ll immediately notice Graph API is immeasurably less complex and more consistent.

So, I could go through and explain how everything works in painful (and highly repetitive) detail…but I’m going to peace out, let you read over the code, dissect it, add some breakpoints and get your hands dirty.

FYI:  There is very intentionally very little UI in the app. Rather than having you, the reader, have to figure out my UI conventions as well as Interface Builder, I’ve kept it simple and dumped most all output to the debugger console.  The code is simple, the pseudo-API is simple, the Graph API is simple……

I hope you take a look at my pseudo-API and agree, it’ simple…that’s the idea.

If you find this post useful, if you include this code or the concepts you learned here in an app, if you extend this into a more full featured API….I’d love to know!

Happy hacking.

Dominic

ddimarco@room214.com

@dominicdimarco

Sample Code:

http://github.com/reallylongaddress/iPhone-Facebook-Graph-API

I opened Facebook this morning and as 10,000 others did in the last hour, saw and clicked on the talking mint. I was kicked over to a “Like us” landing page and clicked the like button.

I then agreed to install the mentos coupon app (and let it have access to my friends and profile information). After that, I was sent out of Facebook to SmartSource coupons which for security and fraud prevention wanted to run / install a java apple, promising coupons afterward.

Coupons may or may not print. Around this point I began to remember the portion of behavioral economist Dan Ariely’s ‘Predictably Irrational‘ that dealt with the lengths people are willing to go to for “Free.” “Free” is like a bug zapper for consumers. You may know better, but it’s not likely you’ll be able to stop yourself. These free Mentos were becoming more and more of a bother. I flipped back to Mentos Facebook wall to see how excited everyone else was about their free mentos…

The Mentos page admin seems to be on top of the situation, changing the profile picture over to a text explanation of the expiration date (there was also confusion about the coupons expiring yesterday instead of a month from now.) While writing this post, 10,000 more users have “liked” Mentos. How far would you go for free candy?

Throwing money into the abyss?

I was quite excited when Kiva first opened its (virtual) doors. Kiva harnessed the power of storytelling, as well as ease of online payment, to help online individuals make a difference they felt connected to. I was equally excited when I watched the rise of crowdsourced funding in the startup world. I believe there is value in this. I know some people who argue that it’s just like buying a lottery ticket; you’re putting in money with no real chance at return. I like the idea, however, of supporting projects that I see as having social value but are not in the non-profit sector.

Small money to big money

So I gave money to Diaspora, the damn-the-man Facebook rival that got some attention this spring. A small part of me wanted the t-shirt that came at the $25 donation level so I could sport it like an indie band shirt. A large part of me was simply excited by the fresh-thinking college boys who were going up against a giant. At $25, I wasn’t in for much, so I committed. It turns out that 6,478 other people felt the same way. The project came it at 2006% of its original goal.

Let the crowd decide

Diaspora utilized Kickstarter, a website that allows startups to raise funding through micro-payments. Here’s why I think Kickstarter has it right: The model is set up so that, if a startup hits its goal, donors are charged. If it doesn’t hit its goal, the assumption is that the idea isn’t strong enough to fund, and no donors are charged. Neat. It takes the wisdom of the crowd and applies it to projects.

So now this idea is hitting public radio. Why is this so incredibly cool? Because individuals can pitch stories, multiple individuals can provide funding, and then a professional produces it. Many ideas are pitched, only the good ones get funded, and we all enjoy a better public radio. To me, this is huge incentive to fund. I’d certainly prefer to give money for a story than to give money for an NPR tote bag.

By any measure, the World Cup is a pretty big deal. 2010’s games will land among the most watched sporting events in history. This time it’s not just about eyes on televisions, though. The last time the world cup came around, Facebook had about 7.5 Million users. Twitter was less than three months old with 500 users. This time? Twitter is peaking at ~3,000 tweets per second when goals are scored.

The experience for the non-attending fan is far richer than before. Aggregators like tweetbeat add context and commentary while watching matches (especialy with the sound off). Location-based networks are helping to bring fans together in the real world. I set off on a rainy Satruday morning to catch the first U.S. match vs England. Foursquare let me know which bars and restaurants the largest groups of people were gathered at and which teams they supported. I ended up at the Drafthouse, which happened to have the biggest U.S. crowd.

For matches during which I’ve been away from televisions and computer, I’ve been using the new version of Hot Potato. This service offers threaded discussions with people who are having the same experience as I am. I was happy when notifications (SMS or Push) became available for sports scores; I’m even happier now with my fully interactive experience. Although the games are taking place 9,000 miles and 8 time zones away, I’m having a better time than I’ve had attending other sporting events in person. [Go USA!]

I recently caught up with Gary for a podcast, and am sharing a condensed version of our discussion with you as part of this post. Additionally, I’ve included my “Top 5 Things to Know” based largely on my experience and discussions with Lauren Maynard, who works with the tool almost daily as Room 214’s Director of Research.

Social-Media-Monitoring-Podcast-With-Crimson-Hexagon

Podcast Show Notes
1. We discuss the original intent of Crimson Hexagon’s technology, and Gary references the “disaster” of attempting to use documented practices for extracting meaning from large volumes of textual content.

2. Gary discusses how Crimson Hexagon overcame the challenges associated with common linguistic analysis by developing something I have come to refer to as their “proportional estimate” methodology.

3. I ask about the accuracy of data and validation methodology. Gary explains in detail.

Note: Gary sometimes refers to posts, tweets, blogs, etc as “documents.” Between his knowledge of the subject matter and natural train of thought, you may find yourself needing to listen to certain sections more than once. The last two minutes of the podcast, when he talks about people/messages basically saying the same thing over and over again, are my favorite.

The Top 5 Things You Need to Know about Crimson Hexagon
I’d like to quickly preface this by saying Room 214 is a tool-agnostic agency. My objective is not financial compensation from Crimson Hexagon for saying nice things about them or even selling their offerings.

It is instead to evaluate, recommend, use and help optimize business intelligence and social media monitoring tools from any number of technology providers my agency deems praiseworthy. This is the best way we know how to continue matching effective solutions to our clients’ requirements (ok, end of my pitch).

1. Crimson Hexagon Accounts for Consumer Variation

Consideration of varied language use is important because it can vary greatly by consumer segment. For example, 12 year olds and 45 year olds might describe something they love very differently, but at the core their statements are both saying, “We love this” or “We are going to watch this.” Identification and categorization of both types of conversation is valuable.

2. Crimson Hexagon Research Enables a Thesis

Using the same set of keywords, and assuming a given volume of subject matter, a question can be asked and subsequently answered. Example: For a TV show, questions ranging from intent to view to sentiment reaction can be answered. Most tools require manual sorting through piles of posts based on keywords and inferred trends. Crimson Hexagon can factually and correctly capture trends pertaining to the question being asked within a given set of posts.

3. Crimson Hexagon Enables the Training of Their Algorithm

We have been at this kind of work (leveraging social media business intelligence and monitoring tools) for about three years, so can appreciate that many of these tools are essentially in their infancy. Still, it wasn’t that long ago we joked about providers needing to activate the “army of midgets” behind the Wizard of Oz curtain in order to get calibrations/adjustments done due to poor data filtering or off-target monitoring.

Today, one of our favorite things about Crimson Hexagon is the ability to make their tools work more effectively without the need to give them a call. This is a huge time saver, allows us to better optimize the tools for relevant results and positions our analysts in the driver’s seat when it comes to delivering value.

4. Crimson Hexagon Helps Narrow the Research

The first steps of keyword refinement are made easier with Crimson Hexagon’s visualizer functionality. The visualizer helps us understand how to better narrow a search, and may even reference items that might be missing. This has made our process more efficient, providing automated assistance towards cleaner, more targeted results.

5. Crimson Hexagon Understands Customer Service

This might sound cliché, but we are all basically in the customer service industry (living in the “thank you economy”). We have somewhat of a unique partnership, but it doesn’t detract from the fact that Crimson Hexagon responds to us very quickly. We’ve had other “partners” that didn’t. This makes a huge difference, because the more we use their tools, the more we need to work through nuances. They have consistently demonstrated a willingness to help refine searches, take feedback and give tips and insights with respect to updates.

Perhaps We Are The Others

Key takeaway here? They don’t care. I have a lot of friends in education, consulting, finance and various non-profit work and, thus, I have very few friends who interact with social media for business purposes. What I’ve found is that, while these people may have updated their privacy settings in the last few months (as have the majority of users), they are largely unconcerned. While they may check Facebook multiple times a day, they see the service as a positive fun-only experience. Those of us in marketing, social media, and tech see it as a something much greater and, therefore, believe that changes in privacy have far more impact on our own lives.

Case and point: My social media self's finely-tuned privacy settings.

Check out the stats from this poll on people’s opinions on internet privacy. It showed that people were neatly divided, with 45.96% feeling the right to privacy should be absolute and 42.28% thinking that privacy is our responsibility, not our right. I would love to take a similar poll and break it down by profession, and then perhaps by hours spent on social media tools.

In The Words of Garth Algar, “We Fear Change”

David Armano, via the Harvard Business Review blog, points out that Facebook isn’t about privacy anyway; it’s about agility. The site was created to rapidly adapt and always entice, and it does that well. Quit Facebook Day was a failure, partially driven by the fact that it was on a national holiday, but partially because a majority of people can’t be bothered. Facebook works for them. As it is our job in social media and marketing to scrutinize Facebook’s every move, these changes create a flurry of posts, Tweets and heated debate. For everyone else? Facebook changes, a few people complain, we all adapt, the change becomes a part of our life, the cycle starts over. And really, let’s be honest: how else would you know when to send birthday ecards?

I don’t want to downplay the importance maintaining a transparent privacy policy; I think Facebook has learned their lesson on that one. However, I do think it’s worth remembering the view of life from outside the social media bubble, how fast Facebook evolves, and how quick we are to forgive and forget.

NOTE: The source code for this tutorial is still linked below, however the FULL Facebook/iPhone Graph API can be found here:  http://github.com/reallylongaddress/iPhone-Facebook-Graph-API

The new Facebook Graph API looks to be the cat’s meow, the bee’s knees, the coolest thing since sliced bread. Ok, that’s a bit much… but it is a whole lot more powerful, easier and cross-platform consistent than the previous plethora of Facebook APIs.  The Graph API was announced at Facebook’s F8 conference just over a month ago.  At the time of release, I was surprised no iPhone SDK was made available. I fully expected that at least an unofficial SDK as well as full blown tutorials would be out en-mass by now, but to no avail.

Not nearly patient enough to wait for an official SDK or iPhone API from Facebook, I asked Google how to “Facebook oAuth 2.0 iPhone” and was disappointed with the results. It turns out, there are very few, woefully incomplete examples of how to authenticate to Facebook via oAuth 2.0, from an Objective-C / native iPhone application. The best implementation I found was a pseudo API, however I don’t care for it since it uses the old Facebook Connect authentication scheme, then implements the graph API on top of that layer.

Adding insult to injury, there was lots of news last week about the Android Graph API but no love for the iPhone:

“Facebook’s mobile development team soft launched a Facebook SDK for Android, bringing functionality that was previously only available on the iPhone to the Android platform. It gets better: Facebook gave the Android platform a de facto exclusive on two of its newest initiatives: Open Graph APIs and OAuth 2.0.”

– Will M, Allfacebook.com

Aside:  My theory on why there’s not iPhone/Objective-C API is:  That functionality is going to be directly (and deeply) integrated in the forthcoming iPhone OS 4.0 (June?).

All of that being said, I slashed, burned and figured it out.  Here’s the result, a very simple end-to-end example of how to connect to Facebook via oAuth 2.0 on the iPhone.

Part 1: Connecting to Facebook with oAuth 2.0 on the iPhone

Part 2 of this series will cover how to interact with the Graph API.

NOTE: You can go to http://graph.facebook.com to play with the Graph API, directly in your browser.

Assumptions and requirements:

• Facebook: You’ve installed the Facebook Developer Application.
• iPhone: You’ve installed the iPhone Xcode SDK installed (I believe most any version will work) and have a some level of knowledge about objective-C, Interface Builder, etc.

Facebook Setup

• Go to the Facebook developer App and install if you haven’t already
• Once you’ve installed Setup a New Application
• Next you need to configure a few app settings:
  • BASIC tab: enter an Application Name
  • AUTHENTICATION tab: un-check and leave everything blank
• Save changes.  Save yourself some frustration and make note of the Application ID now.

Sample Code:

iPhone Setup

Open up the Xcode project. There’s only 2 functions at play here:

viewDidLoad

This function is called as soon as the view has completely loaded.  It then asks the UIWebView to begin the oAuth 2.0 authorization process by sending a request to:

https://graph.facebook.com/oauth/authorize?client_id=your_facebook_app_id&redirect_uri=http://www.facebook.com/connect/login_success.html&type=user_agent&display=touch

(NOTE:  display=touch, we’ll get back to this in a bit)

webViewDidFinishLoad

This function is called several times throughout the login process execution. These multiple web view finished calls have to do with server redirects within the oAuth 2.0 process flow. We’re only interested when the requested URL contains:

access_token=

And the associated obj-c code to identify when this occurs is:

NSRange access_token_range = [url_string rangeOfString:@"access_token="];
if (access_token_range.length > 0) {

Then, this code extracts the oAuth token out of the URL we received back the Facebook oAuth servers:

int from_index = access_token_range.location + access_token_range.length;
NSString *access_token = [url_string substringFromIndex:from_index];

iPhone Configuration

In oAuth2TestViewController.m update the client_id variable with your Facebook Application ID:

/*Facebook Application ID*/
NSString *client_id = @"YOUR_FB_APPLICATION_ID";

Running the App

Once you’ve pasted your Facebook Application ID into the right place, you should be able to run the application straight away.

When you first launch the simulator oAuth2TestViewController it will automagically initialize the oAuth login procedure via the webView object. Barring any errors or configuration issues, you should get a Facebook login screen optimized for an iTouch device (NOTE:  thus the display=touch we made note of above). Finally after you’ve logged in you’ll see your oAuth access token in the Xcode debug console.

Sample Code:

That’s it. No bells & whistles, no buttons, no Interface Builder, no UITableViewControllers; just the bare minimum required to get an oAuth 2.0 token via an itouch device from Facebook.

In part 2, we’ll interact with the Graph GETing from and POSTing data to it, using a pseudo-API.

Find me here: @dominicdimarco

NOTE: (5/27/2010 11:09 AM MST) The original post has been updated incorporating feedback from comments below.

A Complicated Journey

When a brand creates a piece of information, that piece has a twisted, convoluted and often times unexpected set of adventures across the vast world of the interwebs. Once upon a time, this was the simple vision for the internet.

40 years later and things are not so simple. Interesting information about a brand can be shared on blogs, Twitter, Facebook, Youtube, email, Buzz, text and a wide variety of other places. From those individual social spaces, others can share, reshare, and create additional information. Individuals with no inherent interest in your brand can stumble upon it by reading tangentially-related stories on blogs. And now we’ve got the Facebook Like button, which lets individuals trace their way through the web by means of their friends’ interests.

It gets very messy, very quickly. You have to know what to track and where to start looking in order to determine what kinds of people, places and spaces are hotbeds of activity surrounding your brand. Knowing this information, you can then create sticky and relevant content and properly support communities that have the highest propensity to make content viral.

How To Make Sense Of It All

You need to figure out what it is that you need to know in order to better understand groups and places of influence.

• What content gets shared most
• Where it goes viral
• What types of content are best fit to specific mediums
• Types of sharing (ie a few individuals share a lot vs. many individuals share a little)

Above is a snapshot of a dashboard from Meteor Solutions. We placed a bit of Meteor’s code on a client’s website. It allows us to anonymously track how individuals are choosing to share content from this website. We can see what days had the most visitors from shared links, where those people came from, and what kind of content they liked (shared) the most. It also allows us to find out where the content is being shared, potentially uncovering message boards, Facebook communities, etc. that are important influencers for our client.

Untapped Influencers

There are also plenty of sources that aren’t coming directly to your own website, but could be. Here’s a snapshot of a Syomos MAP search on “shade-grown coffee”, which gives me insight into influential message boards and forums surrounding this topic.

It’s Never Static

Whether you like it or not, this work is never done. Key communities will change. The types of content most often shared will change. To build a following, you can’t just monitor for the crisis situations; you need to monitor for the most beneficial situations too. We use a host of tools to go about tracking conversations, content sharing and overall feedback, but that toolset changes constantly. I’d love to hear anything you’ve seen useful. I’d also be happy to talk more about what we use. Drop me a line.