Starbucks Card Mobile is the first example of mass-adoption of a mobile wallet, and you should expect to see this happening much more, and soon, due to use of near-field communication (NFC). You likely already know NFC; if you’ve ever paid by holding a credit card a few inches from a swipe machine, then you’ve seen this technology at work. Visa is currently testing this technology in smartphones. How easy is it to pay by phone? Very. Watch and see.


Breaking Down a Barrier

This technology, a blending of new tech and old behavior, seems like it might be for the early adopter only. But let’s look at some stats:

• Smartphone penetration in US mobile users is already at 33% and growing rapidly
• Ebay is reporting 1 mobile transaction every second. This isn’t just for small purchases; this includes Ferraris
• Apps like Foursquare and Groupon have already gotten consumers comfortable with incorporating a phone into a point-of-purchase experience
• In a survey by NACHA and PayPal, 27% of people said P2P payment through mobile (via banking services or PayPal) was important to them

Increasingly, consumer are used to their phones as a part of their shopping and transactional experience. More importantly, we want shopping and payment to be as easy as possible; a mobile wallet solves a clear consumer problem.

Why This is Good For Brands

• Loyalty: For a brand like Starbucks that has frequent repeat purchase, creating a payment app is an easy way to track consumer behavior and spending. I look forward to seeing how this translates into retail locations with lower-frequency purchases, like clothing stores
• Ease of Purchase: Gilt and Groupon have capitalized on the beauty of one-click purchase on mobile, using stored credit card information. Mobile reduces barrier-to-purchase and, for better or worse, removes a consumer from the experience of handing off actual money
• Go Social: You can integrate all sorts of things into a mobile purchase, including a geo check-in or a push-to-social update

How do you use mobile payments? What do you wish you could pay for with your phone? What concerns you about these developments? Let us know.

The below advice is equally applicable to mobile web or a native (iPhone, Droid, etc.) app…

If you don’t jump on the wave, you aren’t in the game.

Ok. So, you aren’t in the game, you have no mobile offering, it’s not on your road-map, nor do you have any idea where to start. Don’t despair, keep reading & K.I.S.S. (Keep It Simple, Stupid).

1) Plan your mobile offering.

When planning what to include in your initial mobile effort, keep it simple.

Start by choosing the most important, mobile relevant content. A mobile experience is not intended to repackage all of the information a standard web site contains. When in doubt ask yourself: “Would I NEED this function while out on the street?”. If not, hold back. You’ll get plenty of opportunities to reflect and add more functionality later (see #5).

2) Think about your customer’s experience.

A mobile experience should be optimized for reduced screens size and limited bandwidth.

A great implementation of this is American Airlines (aa.com). Their mobile site is visually simple and has very few graphics, which means a fast load time (6 seconds via 3G). The functionality they present is targeted to what their customers need when en-route to and at the airport. Above the fold are all the links I, as a traveler, am going to be most interested in.

Compare this to Frontier Airlines, which doesn’t offer a mobile optimized site. Navigation requires pinches and zooms in order to interact with the page, and essential functions are not in BIG letters on the home page.

Another big strike – repackaging their standard website with lots of graphics, and not considering limited mobile bandwidth, means it takes over 60 seconds for the page load (via 3G).

When designing and building your mobile offering keep screen size and data connection speeds in mind. Additionally, ask yourself this: When your customers are engaging with your mobile offering ‘on the street’ what will they want or need? Maps (where are you located?), yes. Hours of operation (are you open?), yes. The latest 1080p video of your CEO presenting at a conference, save that for the your traditional website.

3) Observe customer behavior.

Web analytics are a part of any solid web strategy. You can leverage web analytics to evaluate where your users are coming from, how they move about within your site, conversion/checkout rates and perhaps most importantly at what points/pages they decide to leave.

Mobile is no different. There are plenty of robust (and free) analytics platforms out there regardless of whether you decide to do mobile web or native apps. Solid metrics will help you understand how your customers are engaging with your offering, thus letting you know where to concentrate your efforts moving forward.

See this post: “7 Solutions for Tracking Mobile Analytics” for additional info on mobile analytics offerings.

4) Solicit customer feedback.

Ask your customers what additional functionality they’d like to see in your offering, they’re bound to give you lots of good suggestions.

We already know how they’re using your offering (via #3 above), now you want to know what WOULD they use. Your customers want you to succeed and appreciate being heard. Listen to them, not just what they say, but what the *mean*. They’ll help guide you to what they will use.

5) Iterate, Iterate, Iterate.

Yes, ‘iterate’ is a buzzword. Yes, ‘iterate’ is over used and abused. However, when it comes to building an engaging mobile experience, it’s 100% essential.

In step #1 above I advocated launching with only what you need (Minimal Viable Product, another hot buzzword). Now, after you’ve launched, after you’ve dissected the analytics, after you’ve reviewed your customer feedback….then, add features that make sense for your mobile audience.

One key point when it comes to iteration: You don’t need to add all of your new great ideas all at once. Prioritize them, add one or two, re-release, iterate again.

In Closing……
It’s not too late to get in the game. In fact, the game is just starting to get HOT.

I’ll leave you with one of my personal development mantras that fits this situation perfectly:
A) Get it done.
B) Make it better.

Happy Coding…….
Dominic

When Facebook Places launched, I was very cautious about using it. I feared backlash for a constant stream of useless check-ins. With Foursquare, there is incentive for me to check in at each new location, because I can get tips and deals. That kind of a check in is why Foursquare exists. Facebook exists for a wide variety of socialization, from content sharing to rants to extended comment strings. If you add into the mix that I am, say, at 7-11, lunch, dinner, or the gym, I’m just flooding my newsfeed with content that doesn’t produce much of a conversation, even if it might let someone know I’m near.

Curation: Share a Story

This then means I need to curate my Facebook Places. Here exists the problem: When I start to curate my check-ins on Places, I am choosing to tell a very specific story. I’m a fan of visual storytelling. I like to show pictures of concerts, delicious meals, afternoon bike rides, etc.. So the question is, what kind of non-visual story do I want to tell that is still worthwhile to my friends?

I asked everyone at Room 214 to send me a screenshot of their Places check-ins so I could get a sense for other people’s stories. It’s worth noting that the only people who currently have access to Places are iPhone users or smartphone users who choose to go to Facebook mobile (a less-than-ideal situation). Perhaps due to this restriction, on average 1-2 friends checked in each day. That’s certainly not a lot. So where do people check-in?

• Restaurants. Far and away the winner here.
• Sporting events
• A few schools, dentists offices, a gym, and airport and an animal shelter

So far, not enough people seem to be using it to give me any information that’s useful, either on an individual or aggregate level. It’s not, in my opinion, any more interesting than seeing a regular check-in in my newsfeed letting me know that someone is close to where I am. Facebook, however, never fails to launch services that annoy and then delight. Say this service hits full mobile rollout, how does this have potential to actually be beneficial to users?

• Like Foursquare, it helps to identify hotspots based on your location
• As it’s already tied to (what is likely) your largest online community, and one with a high daily usage, you can get timely location information on all your friends
• Should they roll out the ability to see trending, you could actually identify user movement and hot spots, internationally

Facebook’s success has taught us that we all like to share, often for the sake of sharing. So will people use Places, if given access? High potential. For me, the question is about etiquette. Will people start to check in everywhere? Will these be like the “I ate a sandwich for lunch” or “My Farmville pig has gout” posts? I hope not, but with a high rate of mobile use, Facebook well-poised to make Places the new status update. I await a widespread rollout, and wonder who I will have to block from my news feed.

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

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!]

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.

Direct from the Google Help Center, here’s what the ads look like: Mobile ads contain two lines of text, with a limit of 12 or 18 characters per line, depending on the language in which you write your ad. Your destination URL appears on a third line if you choose to enter one. If you select the option that allows customers to directly connect to your business phone, a Call link will appear next to your destination URL. You can also set daily budgets and establish scheduled marketing messages.

The big advantage could be for advertisers looking to draw in local customers. For example, people who are on the road traveling and looking for a restaurant, hotel or service. David Utter from WebProNews.com commented on Google’s strategy: “We know that Google and its competitors have been actively engaged in a battle for dominance in the local search arena. It makes sense to corner the mobile search market for advertising if possible.”

Businesses purchase the ads through the Adwords interface, and must have either a mobile web site for pay-per-click ads, or a toll-free phone number for pay-per-call ads.

Now that mobile phones are fully integrated into mainstream America with over 200 million subscribers, mobile phones are and will continue to be an important place to deliver advertising.