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

The Predictions

It seems that everyone was buzzing last week about the major themes of the Consumer Electronics Show (CES). Mashable wrote a blog post identifying what they felt were the key trends of the show, and we at Room 214 decided to test their theory, which said tablets, gaming (like Microsoft’s Kinect and Nintendo’s 3Ds), connected technology, 4G phones, and all things Android platform would be the biggest themes. I went to Crimson Hexagon, one of our social media research tools, and took a look at the conversation from last week.

In over 500,00 posts (82% of which came from Twitter), people discussed these topics fairly evenly. It’s worth noting that you can’t exactly split Android and tablet conversation, as Android tablets, like the Motorola Xoom and the Microsoft Streak, drove a huge volume of conversation. While we can see slight variations in overall theme, the above only really shows us that connected technology, in the home, car, etc., wasn’t as big, so let’s take a look at key language themes by day.

The Reality: January 6th

On the 6th, a presentation slide with information about Microsoft’s Avatar Kinect leaked and the Twittersphere erupted. Sony’s seemingly endless stream of product announcements drove high volume, and the general tablet conversation, a dominating theme for the whole show, honed in on the Xoom Tablet.

The Reality: January 7th

The 7th was the day of 4G Smart Phones, more tablet conversation (this time including the Microsoft Streak), and video. Even though Apple wasn’t really present at CES, some mockups of the iPad 2 shell showed up. The power of Apple buzz still blows my mind: even though Apple didn’t actually showcase or reveal anything, these mocks drove iPad keywords high enough to drown out other conversation of products actually being released. Bravo, Apple.

Interestingly, video showed up as a theme across the entire event, as video was incorporated into a wide-ranging set of products, from Toyota’s in-car Entune system to Microsoft’s Surface V2 hands-on video….thing.

So it looks like Mashable, and a lot of other sources that guessed key themes, were mostly right. And while tablets only got mentioned slightly more often than a few other key trends, when you analyze the specific language, you see that tablets were an anchoring theme throughout. Just a few key things were missed: video technology, and the overwhelming power of the Apple brand.

A recent comScore study found that viewers who watch online-only TV or a mix of live and online desire TV to be flexible to their needs:

• 75% “selected online over TV because they were able to watch the show wherever they wanted”
• 74% “selected online because they were able to watch the show on their own time”

Through DVR, Cable and Satellite providers have allowed us the ability to watch TV on our own time, while still placating the demands of individual networks. But while DVR and on-demand have changed the way we watch TV, they are a half-step in innovation. And these innovations are being surpassed, daily, by an ever-growing list of internet-based products and content delivery systems.

Let’s call this internet-based TV New TV. New TV is a bit complicated. It’s an infant. While Hulu and Netflix have widespread adoption, the use of technology like Boxee, Apple TV, XBox, etc. is still reserved for early adopters, mostly because it takes a lot of configuration to get just what you want, and you really can’t get everything (see: NFL).

Cable and satellite companies aren’t dense; they know their current model of TV will have to innovate, or else. Comcast launched Fancast, which is a re-skinned Hulu with some additional features, like On-Demand listings. AT&T U-Verse integrates with X-Box 360, and U-Verse Mobile allows you to watch a few shows. AT&T recently announced that U-Verse customers who subscribe to HBO or Cinemax will be able to stream content from these channels online, which means they can also get it through their X-Box. With the exception of this latest announcement, non of these attempts have been particularly innovative, and the press around each is overshadowed by ongoing legal battles between cable companies and, literally, any new device or service that brings consumers TV via internet.

As New TV is still cumbersome for the uninitiated, cable and satellite companies don’t exactly have a fire under them. Yet. But now that Netflix, which boasts over 16 million members, is offering a streaming-only subscription model, the average tech user has easy, simple access to a total New TV experience. The current battle between Level 3 and Comcast over this change in Netflix suggests, to me, just how hard the cable companies are going to fight back, instead of figuring out how to better provide solutions that are more relevant to our current consumption patterns. As I said at the beginning of this article, consumers have some serious demands about entertainment. And a lot of innovative companies are trying to figure out how to meet those demands. Didn’t we watch a similar battle happen when major newspapers went digital?

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

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:

[download id="3" format="1"]

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:

[download id="3" format="1"]

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.

It’s not a surprising statement, either. What is interesting, however, is that this statement is becoming relevant for consumers in all age brackets. 78% of consumers say they trust peer recommendations. We’re all easily influenced by each other, meaning that information sharing in social media is very valuable.

Enter this:

What you are looking at are screenshots of Google Buzz mobile. Not only can I see who near me is buzzing, I can see where they are. If someone is in a location I’m heading towards, I can see what they are saying. In this case, one person has just told me that the Florentine’s at a local coffee shop are more expensive than at CU Business School.

Real-Time Reviews

As more people adopt buzz, the aggregated conversations in one location can paint an incredible real-time picture of what is happening around you, based on the opinions of other people. Is your favorite restaurant out of their nightly special? Did someone have terrible customer service at the running store you’re headed to? All of this information is immediately accessible, in addition to being timely and relevant.

Large User Base

Geo-location services are by no means new. Consider, though, that Gmail’s active monthly user base is rumored to be around tens of millions (compare that to Foursquare’s 350k and MyTown’s 1mm total users). Add that to the fact that buzz is an opt-out rather than opt-in feature, and we’re likely to see a much higher adoption rate.

It’s Google

I’ve had a few debates about this since Buzz launched Tuesday, and I continue to argue this: A lot of people use Gmail. Through Gmail, a lot of people who aren’t early-adopters have tried out new Google products like docs, calendar and wave. Because these people have an established trust for what Google can bring into their lives, they’ll be willing to try out Buzz, much more so than they’d be willing to try out a similar product from an unfamiliar company. And as our designer Andy Stone pointed out, Google’s “Do No Evil” policy has also helped build trust within a distrusting consumer group.

It’s Social

Now the medium that we (or at least, I) need most on a daily basis to communicate is directly connected with a sharing function that isn’t tied to a type of content (ie Yelp for reviews, Foursquare for tips and frequency). Buzz is just thoughts.  I, for one, am going to share, and I’ll share whatever is on my mind. Freed from the constraints of types of reviews, I think we’ll soon be seeing a geo-tagged map of candid consumer thinking.

Good, Bad, Viral

This is great for the way your brand engages with individual consumers. Fast Company already took a look at user-targeted advertising through Buzz. You may soon be able to target individual consumers based on very individual habits, an act which can help build relevant and meaningful relationships, one person at a time. It also means you need to monitor and play an active role in the buzz (Buzz?) going on around your company. You can respond to any comment that is public, so any time your brand shows up on a map, you should be there to discuss. More importantly, you should be there before the discussion starts, letting us know what’s going on in your kitchen, your factory, and your main conference room.

Take, for example, Bonnaroo’s decision to let individual bands announce their presence in the 2010 lineup (along with individual announcements through MySpace). It took resourceful individuals to piece together the entire lineup, and the news spread like wildfire. What if you had a single person in your brewery Buzz about your latest creation, rather than announce it through press release? Which one would spread faster? Which one would spread organically?

Google Buzz has the potential to create huge buzz, both positive and negative. So get to using it. I am.

Lately, Facebook has seemed to be in a transition phase (half stuck between becoming a Twitter competitor and sticking to their roots). While it is hard to say what sort of functionality they are aiming for at Facebook., they are certainly giving us a look at the future.

FriendFeed brings a lot of brain power into the mix. Now that Facebook has acquired the know-how, there are a lot of things they can be doing to improve my experience.

Include a real-time search of status messages.

Facebook needs to become more open. I want to search status messages and see what people are talking about up to the minute. This is a no-brainer.

Be my one-stop internet identity.

This means Facebook has to adopt the aggregation qualities of FriendFeed. I want to be able to connect my Facebook with my FriendFeed, my blog, and my Brightkite. I don’t necessarily want to publish posts from all of those networks, but I want Facebook to recognize all of those networks as me. If someone connects with me on one network, I would like for them to be able to visit my Facebook profile and get a more complete sense of the person I am.

I want to easily link/mention my friend’s profiles in my posts.

There is no easy way to reference a friend in a status update on Facebook. On Twitter this is as easy at including someone’s handle. I would like to be able to type a friend’s name and have it appear as a link to his profile in my status update. Even better, if Facebook would allow us to aggregate our profiles from other networks we could easily use a Twitter handle or another username to mention each other in posts. Those links could all head to our Facebook profile pages, making them much more useful and relevant.

Make Facebook less messy.

Here is where the FriendFeed team can really make improvements. In Facebook, there are so many different places to interact with other users that it gets confusing. I think it reduces the amount of quality interaction.

Let’s say you see Dave’s status and you want to respond. You can:

1. Post a comment on his status message, but risk the annoyance of getting notifications every time a user you don’t know also comments on that status update.
2. Head to Dave’s profile so you can comment on his wall.
3. Start a chat with Dave to continue the discussion
4. Send Dave a mail message

Let say you choose to post on Dave’s wall and now he sees your wall post. He can:

1. Comment you back on the post you put on his wall
2. Head to your profile and post his response on your wall
3. Start a chat with you
4. Send you a mail message

Now lets say Dave is a total noob (which is the case for a lot of Facebook users). He accidentally posts his response in another status update. All of a sudden this conversation has gone from a status update, to one person’s wall, to the next person’s wall, back to a status update. Needless to say, the entire process has a lot of room to be simplified.

There are things I like about both sites, and by taking the strengths of both FF and FB, perhaps they can mash together a new social media super-power.

What do I like about Facebook?

Facebook is where I can find most of the people I know personally. It is less scary and more acceptable to a wide range of users because you generally connect with more people that you know in real-life. This is partially why they have been acquiring so many new users. The problem is: Facebook has not entirely kept up with the way people communicate and connect, leaving them with one foot in the past, one foot in the future, and an interface that is equally as stuck in-between.

What do I like about FriendFeed?

All of my internet identities are pulled into one convenient location that is very intuitive and easy to use. The problem is: The average user doesn’t know as many people on FriendFeed and is less inclined to spend time there, even though the interface is way better.

End of discussion. Continue with normal life using Google maps, search, and documents etc.

But today, I saw this: http://www.BingTweets.com and I realized the possibilities.

Your web searches are more powerful because you are able to cross reference them with real time results from Twitter. Your Twitter searches become more powerful because you have a web search that allows you to dive deeper into the topic. Things like deciding where to eat, or finding the latest news on a Twitter topic are incredibly simplified using Bing Tweets.

Average search process to find mexican restaurant in Boulder using Google:

1. Search “Mexican Food in Boulder” – (Here are the results: http://snurl.com/nljyx)
2. See list of 10 Restaurants.
3. Let out a big hungry sigh, and sift through reviews for each restaurant.
4. Weigh the good reviews vs. the bad reviews. Ponder meaning of life.
5. Possibly click on link to Yelp or City Search and continue researching there.
6. Narrow the list down to 2 or 3 locations.
7. Ask friends/coworkers/Twitter friends where to eat.
8. Follow friend’s advice and finally pick a place to eat, hopefully before dying of starvation.

Average search process to find mexican restaurant in Boulder using Bing Tweets:

1. Search “Mexican Food in Boulder” – (Here are the results: http://bit.ly/293g8r)
2. See list of 10 Restaurants, and a scrolling list of Tweets about “Mexican Food in Boulder.”
3. Read this tweet: “Efrain’s tonight – the BEST Mexican food in Boulder, by far, esp. the chile verde.”
4. Get directions from the web-search
5. Go to Efrain’s. Stuff face with delicious mexican food that was recommended by someone on Twitter.

By my very scientific process, Bing Tweets gets you there in three fewer steps.

All joking aside, real-time search has the power to revolutionize the way web search works. As Twitter becomes more popular, search engines will have to take its activity into account in results. Why? There is simply no better way to find out what people are talking about at this very moment than to look at Twitter topics.

As Facebook makes it’s user’s updates more public and open (and hopefully searchable) those results will also be a valuable source of up-to-the-second information.

Bing Tweets is one of the slickest real-time search engines I have seen to date. It is something that I can be excited about, and it will certainly move a few of my searches away from Google.

If at all possible don’t be JohnHucksCliffs on Delicious and JohnnyRockStar onTwitter. Try to keep your identity consistent across as many platforms as you can.

Sometimes that’s easier said than done. Being graced with a common name like James Clark can have its benefits. For instance, I can pretty much go to any major sporting or entertainment event, walk up to the Will Call window and say, “Tickets for James Clark please”, show my ID and I’m in. Now I won’t admit to doing this, but for those of you with common names it’s a plus.

But in the social media world it’s a pain in the…..

A common name, be it personal or a corporate, is often difficult to come by for a username ID. So prior to setting up personal or company profiles, plug potential ID names into UserNameCheck.com and see what is available and what is taken.

Our recommendation is to make sure you’re covered on the bigger sites:
Delicious, Digg, Flickr, Friendfeed, MySpace, StumbleUpon, Twitter and YouTube.

So in case you’re interested JohnHucksCliffs is very available: