An article appeared on Mashable last week disclosing some of the details about Bebo’s new Open Application Platform; a subsequent article revealed that Bebo’s platform supposedly supports the entire F8 Platform, including FBML. Since Mashable is incapable of actually linking to the actual article that it covered, or anything other than other unintelligble Mashable articles, I have taken the liberty of providing you with a link to Bebo’s original press release.

I blew off the news as yet another empty Web 2.0 promise, but when the guys from ADOOGA asked me to look into porting my most recent Facebook application, “Contest of the Day”, I decided to take a closer look.

After half an hour of perusing the site I still have no idea how to create a developer account

Having never used Bebo before, my first step was obviously to sign up as a regular Bebo user. Great. This new Bebo account sure looks nifty. Not like I’ll ever use it since I don’t even know any body who uses, let alone has heard of, Bebo. Step 2 is to create a developer account; easy, right?

Wrong. I’ve looked through the developer documentation and exhaustively searched throughout it but I still can’t figure out how in the hell I create a damn developer account. Apparently a number of Inside Facebook commenters experienced the same problems that I have; Inside Facebook author Justin Smith said that a link to create developer accounts “should be up by tonight (12/12/2007.)” As of writing this (shortly before 12/20/2007,) Mr. Smith still has not posted a link yet. Hmmh.

The Future of Facebook Applications and Bebo

All of the hype-blogs ranted about Bebo’s Open Application Platform as though it was some sort of game-changing event that would add more momentum towards Facebook’s F8 platform and hinder the adoption of Google’s OpenSocial platform.

However, as all of those hype-blogs dutifully noted, Bebo will still add full OpenSocial support sometime in 2008.

I suspect that the move to support the F8 platform was made out of a need to draw more funding. Perhaps it was also to capitalize the rich breadth of available Facebook applications which could potentially add more functionality to Bebo’s network. Bebo, in my opinion, offers a rather bare service compared to the richness of MySpace or Facebook.

As the Quantcast graph below shows, Bebo is a blip on the social networking radar screen.

(Click for a larger Graph)

Bebo’s move to support Facebook applications is perhaps an attempt acquire new users, perhaps former Facebookers who are already familiar with a number of applications that may be ported over to Bebo’s platform eventually. Bebo needs all of the help it can get, whether it be funding or new users.

Technorati : Bebo, Facebook, Facebook Applications
Del.icio.us : Bebo, Facebook, Facebook Applications

Alright, as promised, it’s time for me to reveal my first published Facebook application: ADOOGA Contest of the Day. I’ve started several applications and built many of them to 90% completion, but Vanderbilt’s coursework usually found a way to interfere with my production schedule and forced me to table release until later.

The last 10% is always the hardest part, after all.

What Does ADOOGA Do?

ADOOGA is an online firm that specializes in syndicating brand-based online contests.

• If you’re a film maker and you want to find an online contest to submit some of your work;
• if you’re a programmer and you want to put your skills to the test in a competitive project design contest;
• or if you’re a creative type of any sort and you want to earn some revenue in a sponsored contest,

then ADOOGA has a contest somewhere in its database that may help you earn some winnings by virtue of your creative capacities. That’s my elevator pitch on what ADOOGA does. You can learn more about their organization on ADOOGA’s about page.

What Does ADOOGA Contest of the Day Do?

ADOOGA Contest of the Day is a pretty simple, unintrusive Facebook application. It downloads the seven most recent “Contests of the Day” from ADOOGA and enables you to share them with your friends by publishing the contest into your mini feed.

The application doesn’t put anything on your profile page and it doesn’t publish any content without your consent.

If you’re one of the creative types that I outlined earlier, then you might enjoy getting instant access to ADOOGA’s premiere contests via your Facebook account.

How Did I Build It?

While I’m not going to write a highly detailed post on how ADOOGA Contest of the Day is constructed given that ADOOGA owns the intellectual property, I’ll quickly iterate over some of the technology I used:

• ASP.NET
• Facebook.NET - FBML implementation
• XSLT 1.0 - Used it for generating FBML output (yes, you can do that with XSL)
• XPath/XQuery
• FBJS - Used it for modal dialogs and Facebook’s handy AJAX library

I was tempted to use Mock AJAX, but it proved to be unsuitable given the method I utilized for producing the FBML output.

Go ahead and check out the application and let me know what you think!

Time to make good on my promise for some new Facebook-related content this week.

I’ve spent the past two weeks grinding away on an Facebook.NET-powered Facebook application that relies on the FBML approach for user interfaces and it’s finally finished.

Over the next couple of weeks I’m going to share some wisdom I accrued during the course of this last development cycle.

Use User Controls for FBML/UI Reuse

Custom server controls are often unnecessary for a lot of the needs of typical FBML-powered interfaces in Facebook.NET. They can take a while to program and given how rapidly the FBML standards are changing, they will require a large amount of maintenance. In addition the HTML writer classes don’t support the FBML markup.

User Controls, on the other hand, offer a cheap, robust way to reuse user interface elements without any additional coding.

Example 1:

A quick example of where a user control might be necessary is the stylesheet element.

One of the drawbacks of FBML is that you can’t import external stylesheets into your FBML elements, thus you have to hardcode any custom CSS elements into those lovely <style> tags that we are so found of.

It’s bad practice to copy and paste the style sheet from page to page; we want to maintain the stylesheet from a single location, which is why we have external stylesheets to begin with.

Obviously, we should stick the stylesheet into a User Control and insert that tag on pages where we need stylesheets. You can also use MasterPages and Themes to potentially resolve this issue, but in my experience, User Controls offer the most flexibility.

Here’s a quick bit of sample code:

FacebookCSS.ascx

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="FacebookCSS.ascx.cs"
Inherits="Controls_FacebookCSS" %>
<style>
p, body{
font:10px/12px arial, helvetica, sans-serif;
color: #022e37;
}
a:link{
text-decoration: none;
}
a:visited{
text-decoration: none;
}
a:active{
text-decoration: none;
}
a:hover{

text-decoration: underline;
}
</style>

Web.config (relevant sections only)

<pages>
<controls>
<add tagPrefix="fb" assembly="FacebookNET.Web" namespace="Facebook.Web"/>
<add tagPrefix="fb" assembly="FacebookNET.Web" namespace="Facebook.Web.IFrame"/>
<add tagPrefix="FBNet" tagName="FacebookCSS" src="~/FacebookCSS.ascx"/>
<add tagPrefix="FBNet" tagName="FBJS" src="~/FBJS.ascx"/>
</controls>
</pages>

MasterPage.Master

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" EnableTheming="true" %>
<%@ Import Namespace="Facebook.Service" %>
<fb:FacebookApplication runat="server" ID="FacebookApplication"
ApplicationName="Facebook.NET App" Mode="Fbml"
EnableDebugging="true" EnableAjaxScenarios="true"></fb:FacebookApplication>
<fb:fbml version="1.0">
<FBNet:FacebookCSS ID="FBCss" runat="server" />
<FBNet:FBJS ID="FBJS" runat="server" />
<fb:dashboard>
<fb:action href="Default.aspx">Home</fb:action>
<fb:action href="About.aspx">About</fb:action>
</fb:dashboard>
<div class="primary_container">
<asp:contentplaceholder id="ContentPlaceHolder1" runat="server">
</asp:contentplaceholder>
</div>
</fb:fbml>

Although this tip is somewhat simple, it will allow you to design your FBML application as though you were using an external stylesheet, although you’ll be editing a .ASCX file instead of a .CSS one, I suppose. Regardless, this will serve as a fine substitute for external stylesheets.

Developing Facebook applications is a trying and frustrating experience for many developers, myself included. My most recent frustration was getting an item to publish to the user’s mini-feed/friend’s newsfeed using Facebook.NET.

Publishing frustrations aren’t isolated to just Facebook.NET; they extend to a lot of Facebook.NET developers out there. Here’s what I’ve learned about how to publish to a Facebook user’s mini feed:

Use the Feed Preview Console with Caution

The Feed Preview Console is a handy tool for figuring out what your published feed items may look like, but it needs to be used with caution. Why?

A number of HTML elements that can’t be rendered in the news feed via the Feed.publishTemplatizedActioncall can still be rendered using the Feed Preview Console.

I learned this the hard way; I had a feed template that included a number of <hr>, <br>, and <p> tags and the Feed Preview Console rendered it without a complaint. However, when I attempted to publish that template I received a number of 360 and 362 errors from Facebook’s REST servers.

The Feed Preview Console will not let you know if you have gone past the character limits for the title and body sections of your news feed items. In short, the Feed Preview Console must not be used for validation of your feed templates; it should only be used for getting an idea of what your feed items may look like.

This brings me to my next piece of advice.

Read the Feed.publishTemplatizedActiondocumentation VERY carefully

So the Feed Preview Console published a handful of invalid templates without any warnings; what I should have done is read through the documentation for the API call more carefully. Here are the tidbits that you may have missed:

• In the title_template parameter

  1. The title_template can only contain 60 characters, excluding markup tags. It’s unclear if the 60 character limits includes the value of {actor}. I’ve actually asked this question on the talk page of the Feed.publishTemplatizedAction on the developer’s wiki.

  2. The <fb:name>, <fb:pronoun>, <fb:if-multiple-actors>, and <a> tags are allowed. No other tags are allowed (despite what may render in the Feed Preview Console.)

• In the body_template parameter

  1. The <fb:userlink>, <fb:name>, <fb:pronoun>, <fb:if-multiple-actors> <a>, <b>, and <i> tags are allowed. No other tags are allowed (despite what may render in the Feed Preview Console.)

• Applications are limited to calling this function 10 times for each user or Page in a rolling 48-hour window.

  This means that you can only call this function 10 times within 48 hours for a given {actor}. I read on the developer’s Facebook group that test accounts are not subject to this restriction; however, this is not the case. I am currently receiving error 343 using my test account, which is the “maximum calls reached” error code; it’s not listed in the documentation for Feed.publishTemplatizedAction.

  “error_code”:341,”error_msg”:”Feed action request limit reached”

• Facebook must be able to issue HTTP requests to any images that you include in your published feed.

  Unfortunately this didn’t occur to me until hours into my debugging; Facebook uses a proxy-caching system in order to help maintain scalability, which I described in my New Facebook Application Form Demystification article. The images I was trying to publish were protected behind windows authentication, thus Facebook couldn’t request them, thus my publish attempt failed for yet another reason.

Don’t Rely on Facebook.NET’s Service.Feed.PublishTemplatedStory for Validation

Long story short, you need to validate the data yourself before you hand it off to the Facebook.NET Feed service; Facebook.NET doesn’t validate the data, that responsibility falls on you. Here are some quick validation tips:

1. Make sure you don’t have any single quotes (tick marks) in your JSON-encoded array; this will invalidate the array’s integrity.

2. If you haven’t provided validation of user input already, then make sure that you use Server.HTMLEncode any data that has been provided by the user. The point of using the HTMLEncode is not to protect against malicious HTML markup; it’s to prevent benign input that uses characters like double quotes, tags, and so from being discarded as they can break that array’s integrity.

Facebook.NET Hides Messages Returned by Facebook

Facebook.NET hides all error messages returned by Facebook, an issue which makes it nearly impossible to debug. I went and hacked my Facebook.NET and added a function called Service.Feed.PublishTemplatedStoryResponse, which returns the FacebookResponse object gathered by Facebook.NET.

I posted an issue on CodePlex asking for FacebookResponse support in the future so we can debug our applications properly, but for now we’re going to have to rely on either guess-and-check debugging or we’re going to have to hack Facebook.NET, like how I did.

If you have any additional information on Feed.publishTemplatizedAction, post it here or on the Facebook Developer’s Wiki Talk Page for Feed.publishTemplatizedAction.

I was asked a couple of questions by Allan Hoffman, the “tech jobs expert” at Monster.com, regarding Facebook application development for his piece, “So You Wanna Be a Facebook App Development Star?”. It’s a great read if you’re looking for a great introduction to Facebook applications, and towards the end Allan uses a quote by me regarding the subject of Facebook application monetization.

I don’t mean to pat myself on the back, but I think it’s a great article. Check it out here.

I should have a piece out later today (after I get some sleep and fly back to San Diego) on entrepreneurship, but I apologize for the slow week; I’ve had a lot of papers and exams this week at Vanderbilt so I’ve been a bit behind on my blogging activities, but I’m on vacation next week so I should have most of that behind me.

Just a quick post for today, but a valuable one nonetheless. I have mentioned before how I prefer developing Facebook.NET applications using the Iframe method of implementation, namely because I didn’t think it was possible to debug FBML implementations on the localhost.

Cameron, an AjaxNinja reader, found the following comment on Nikhil’s blog, which explains how you can debug FBML on the localhost:

JustinM
Posted on 10/22/2007 @ 7:14 AM
Manjit,

Yes you can debug locally with fbml apps. What I did is get a free dynamic dns (gotdns.com), port forward port 80 (actually in my case port 8080, as some other machine is using 80) directly to my development laptop that has IIS running (Vista Ultimate, note the Application Pool may need to be set to “classic”).

Then made a local dns entry in windows\system32\etc\hosts file to have the dns entry point to 127.0.0.1 for resolving url’s that point directly to my site (images). Everything works fine.

While I haven’t tried this yet (I’m still developing my applications in IFrame), I may give it a go if I keep running into an annoying post-back issue that causes my application to force existing users to re-add it.

Nice find, Cameron!

Update

I received a couple of emails from Cameron this morning; apparently this Dynamic DNS solution isn’t as easy as it sounded initially:

Having been running into issues the the DNS redirect solution.

1. You need access to your WIFI access point to complete the port
   forwarding.
   This rules out mobile workers, ie. coffee shops
2. host file will need to be updated every time your DHCP server assigns
   a new IP
3. I have been able to get past the above two but have had some issues
   discovering the IP that points to my default gateway’s IP.

Hope this helps with your article. I will send any other suggestions
that arise.

Thanks for the great feedback!

A week or so ago I wrote yet another post full of Facebook application development tips (and believe me there will be several more to come), and I mentioned using Facebook test accounts to assist in development. After a week or two of actual using the accounts extensively I must tell you that they are not all they are cracked up to be.

Why do we have test accounts in the first place?

Facebook enabled developers to create test accounts namely to spare the developer’s friends from becoming guinea pigs for new application development, as this blogger argues. However, test accounts fall far short of eliminating that burden upon the friends of developer’s entirely.

Reasons why Facebook test accounts suck

1. It’s another freaking login you need to keep track of to manage a Facebook account. You need to create yet another new, real Facebook account, complete with a valid email address. I already have two Facebook accounts, one for managing my professional contacts and carrying out all of my Facebook application development and another account for managing my high school and college friends.

   I originally chose to separate my accounts simply because I wanted to be able to easily separate professional and social contacts; to put up a wall between them, so to speak. I’m not so bothered by the fact that I now have a THIRD Facebook account to help me test, but I had to put this point on the list as it is an obvious irritant associated with creating a new Facebook account.

2. You aren’t supposed to interact with regular Facebook users with a test account - Ok, so if I have an application designed to INTERACT WITH OTHER USERS, then can’t some of this behavior be construed as a violation of the test account terms of service? Fail.

3. You can’t friend users with a test account If I have a brand new, fresh test account and I need to have X number of friends in order to test a feature (like if I want to see my friends’ recent activity) then a test account simply will not suffice. Fail.

4. If you’re building an application in developer-only mode, you can’t even use test accounts because you can’t add them as developers, because that’s a violation of the terms of service. Say goodbye to developer-only mode if you want to use test accounts.

In short, these Facebook application test accounts are a waste of time, and don’t bother using them until Facebook provides some additional, unique incentive (like debug messages) to use them.

1. When making service calls in Facebook.NET, leave the “field” specification null - I was working on building a server-side control for creating a user “Baseball card” for one of my pages and I needed to download just the user’s full name and the url to their square profile image but I kept running into the following two problems:

   • Agonizingly slow query times and
   • The User object returned by the UserService was null, even though I had specified the field values correctly.

   However when I changed the field value to null, like how Nikhil himself did in his Facebook.NET example, specifically where he called

   <script runat="server">
private void Page_Load() {
ArrayList ids = ...; // User IDs populated from ids posted by the multi-friend-input element
string fbml = ...; // Build a greeting to place on the user's profile

   // Use the Facebook profile.setFBML API to update the user's profile
fbApp.Service.Profile.SetFbml(fbml, null);
}
</script>
   Here’s an image illustrating where I placed a null value for my specific circumstance:

   

   Now are there some performance costs for not narrowing down the fields? Yes, but they’re negligible if you ask me.

   The greatest amount of overhead in communicating with the Facebook API for a single user’s profile is making a round trip to Facebook’s servers, not the size of the record returned.

   If there’s some fix that allows me to limit my input using field specifications in Facebook.NET services then I’ll run it in a new article.

2. Get a Facebook Application Test Account - On October 3rd Facebook announced that developers would be able to convert accounts into Facebook Application Test accounts. I know one of the issues that I dealt with when I first got started developing my application was constantly deleting items from my news feed that my application produced (until I figured out how to disable it!)

   Having a test account makes the issues of hiding testing content from your everyday friends a non-issue, so go ahead and make one.

   You should probably create a new, normal Facebook account first before you try to convert an existing Facebook account into a testing account, because interacting with normal users via a test account is against the terms of service and will result in account termination.

3. Improve Response Time with Facebook Modal Dialogs by 99% - Although this developer is making his application using PHP, his problem of slow modal dialog is solved by using FBJS (Facebook JavaScript.) So take note: don’t try to reinvent the wheel; use some of the tools provided by Facebook’s environment.

4. Experiment with Facebook JavaScript (FBJS) - I found an article when I was perusing Technorati the other day about how one developer built an entire dynamic application using only FBJS and I was astounded. As it turns out the application hit some major problems down the stretch but regardless the concept is cool. FBJS merits some experimentation on our parts as developers. Don’t just slap it in there for the sake of slapping it in there, though. There are some use cases, like the one I just mentioned about modal dialog, where FBJS can improve performance; we should look for and publish more cases.

5. Create “Debugging” and “Live” Versions of your Application - The age-old software engineering concept of versioning rears its head. I was reading through some of the notes from Dave McClure’s Graphing Social Patterns conference and I noticed that someone had mentioned this very idea. The idea of maintaining a development version and a live version seems obvious but in case it’s not here’s why you should do it:

   • Making live changes to an application that is serving potentially millions of Facebook users at any given time is a terrible, terrible idea.
   • If something goes wrong with your changes or modifications to your application and a ton of your users see that crappy Facebook application error page, how are you going to be able to roll back to a “stable” version if you just uploaded over the only other copy? Whoops.
   • Facebook users are very fickle and do not tolerate bad applications. You can be sure that you’re going to lose users if all of your users encounter errors for a duration of time while you attempt to repair the application.
   • Performing changes on a debug or development version of your Facebook application will prevent these nightmares from occurring.

   So there you have it.

That will do it! If anyone has some tips they’d like to submit or some questions, please leave them in the comments below or use AjaxNinja’s contact form to mail me.

It’s about time for an update on Facebook Application with ASP.NET, using Nikhil Kothari’s Facebook API wrapper for ASP.NET, Facebook.NET. If you want to read about why I’m using Facebook.NET instead of the Facebook Control Toolkit then click here.

I’ve spent a lot of time developing my Facebook application this weekend and I have a few additional pointers that I’d like to throw out for any Facebook.NET developers looking to get started:

1. Use Steve Trefethen’s Visual Studio.NET starter kit for Facebook.NET - This starter kit is a handy package for jump starting a Facebook.NET application from scratch. I’ve written most of my Facebook application using Steve’s starter kit as a foundation (I ditched my botched FBML attempt and re-did the entire UI as an iframe.)
2. Develop and debug your application as an <iframe> application - Take it from me, developing an FBML application is a pain in the ass for the following reasons:
   • FBML is very strict
   • Your FBML applications have to be run off of a server that Facebook can connect to, so a lot of your localhost debugging options disappear if you are behind a firewall like me.
   • FBML obfuscates any HTTP error messages, thus it can be very hard to track down and locate error messages when something goes wrong. I actually developed a great solution to this problem but still it was just easier to switch to an iframe.
   • Facebook’s Stylesheets can mess with your graphical elements a lot when you develop with FBML; using an iframe gives a clean slate (but you also have to try and then create your own styles that mesh well with Facebook!).
   • You can always develop and test the core of your application as an iframe and then embed it into an FBML wrapper later as an <fb:iframe /> element.

   I could go on all day about how much easier it is to work with iframes than FBML, and I may even write an entire post about it, but if you need just one reason, then it’s this: you can debug on your localhost effortlessly with iframes, and not at all with FBML.

3. Use strongly-typed references to Master Pages in all of your .aspx files - In my 10 Hot ASP.NET Tips and Tricks for the week of 9/28/2007 article I mentioned an article on master pages. In the subsequent code sample for the article I linked to you can see where the author uses strongly-typed master page references to access controls on the master page via the .aspx pages. If you use Steven Trefethen’s starter kit then you need to implement some sort of strongly-typed reference in order to access the Facebook Application control which will then give you access to the Facebook Application service. All of my .aspx pages connect to Facebook via the master page’s control, and it saves on a lot of code duplication.

4. Use <fb:FacebookHyperLink> extensively - One of the problems I had with my <iframe> approach was that my ASP.NET links would all point to my localhost url rather than translate correctly to Facebook’s url.

   For instance if my application’s home page were hosted at http://localhost/default.aspx and I wanted to go to my “invite friends” page, invite.aspx, clicking on a link that uses traditional ASP.NET relative-architecture (~/invite.aspx) would land me on http://localhost/invite.aspx, but where I really want to go is to Facebook’s translated address http://apps.facebook.com/myapp/invite.aspx.

   <fb:FacebookHyperLink> takes care of this translation for you automatically, and it even adds the correct target property so you can navigate properly via <iframe>. This will save you from a lot of headaches.

5. Use the FBML Test Console - If your application sets a box on a user’s profile page, which requires FBML, then you need to make sure you thoroughly test your Facebook application’s FBML output using Facebook’s FBML test console. You will not be able to test FBML rendering on your local machine as there are no desktop tools available for FBML. In addition Facebook changes the FBML standards frequently so even if there was a tool available it would become out of date in relatively short order.

I’ll have some more tips and some code samples available this week as my development continues. I hope you find these helpful.

I had the pleasure of attending the Facebook Application Developer’s Garage in San Diego, California on August 23rd. It was hosted by Rodney Rumford of FaceReviews at Microsoft’s local office space in San Diego.

For a brief bit of time we talked with one of the main F8 designers whose name I forget; I bluntly asked him via Skype why ASP.NET wasn’t supported in Facebook’s Thrift release and the answer was, plainly, that Facebook’s internal development team is committed to open source and has no experience with it (noobs).

The big thing that the entrepreneurs and developers wanted to discuss was how to properly monetize a Facebook application. One of the most popular posts on AjaxNinja, as of writing this, is my August entry on The Challenges of Facebook Application Monetization, which I recommend you read.

I lead the panel on Facebook Application Monetization and I came away with a lot of great ideas and a lot of feedback on bad ones.

First, the bad news:

• Contextual ads are an utter failure
• Getting your application noticed has become increasingly difficult; active marketing campaigns have to be undertaken in order to promote a Face book Application; adding it to the directory simply is not enough anymore.
• Simply trying to get as many users as possible and then slapping some AdSense garbage on the canvas page will not work, either.

Basically, the “rock star engineer” approach of “get millions of users then figure out how to make money” will prove worthless in 99.9% of all Facebook applications, even popular ones.

You can be the fortunate recipient of a lightning strike (YouTube is the best example of a lightning strike) and get bought out by some monalithic corporation wtih deep pockets, or you can stop doing the same stupid things that all “rock star engineers” do and come up with a business plan from the start.

The idea of leveraging contextual ads is foolish; for one thing, you can only get ads like AdSense to work on an <fbml:iframe> built within the canvas page, and unless you have an application like What I Did Today where all of the updates occur on the canvas page, your users will rarely see the canvas page.

Don’t leverage millions of penniless students. Target niches that are willing and able to pay.

In the meeting there were a handful of business developers and executives, people who really understand the business end of running a company. However, the majority of people were developers like me; the business developers shone the light of truth on the entire Facebook Application Monetization Dilemma in a way that was so profound that I was literally mad at myself for not realizing it.

I forget the gentleman’s name, but here is my paraphrase of the sheer brilliance he shared with us foolish developers:

You guys are all worried about trying to grab up as many users as possible; you’re all worried about just getting huge numbers on your Facebook Application summary pages.

What do all of those users do for you if all of them are part of a demographic that does not spend money, like college and high school students, who constitute by far and large the most sizable portion of Facebook’s user base?

Instead of chasing after a bunch of students, why don’t you tailor an application to a niche within Facebook that has deep pockets, that can and will spend money?

I was literally mad at myself for not having thought this first; like many young developers and entrepreneurs, I got sucked into the “gold fever” prospect of staking a claim with a killer Facebook application without any regard to who was going to use it and whether or not they would spend money!

So the moral of the story is, build your applications with a money-capable niche in mind, and try to serve their economic interests.

The “deep pockets” you target don’t have to be Facebook users; they can be companies and organization with an interest in using your application as a promotional tool.

Use your application user base like marketing real-estate

The big Facebook Application networks like Rockyou and Slide use “Facebook Application Readership Real-Estate” to effectively market their own Facebook Applications, but if you develop one successful application, no matter how stupid it is, there is a good chance you can leverage your real estate to help promote someone else’s applications for profit.

This is one instance where leveraging makes sense, simply because cross-promoting another application of perhaps a similar nature is much more targeted than AdSense. There’s a good shot that if a user really likes an application that they’d be willing to at least try adding some of the other ones recommended by that developer; call it brand trust or loyalty.

One of the things Rodney emphasized after the event was the notion of networks of applications competing for real estate with each other; the idea of a few major players buying out applications for the sake of readership real-estate adds yet another interesting dimension to the entire Facebook application puzzle.

A word of thanks to the Facebook Application Developer’s Garage: San Diego participants

I’d like to extend a word of thanks to Gary Gil of Podclass, Woody Pewitt of Microsoft (who gave a great presentation on Facebook.NET), Alex Shah of FaceDouble, Ryan Denny of BYU, David Levine of the Harvard Business School, Rodney Rumford of FaceReviews, and anyone else I met whose name I forgot. I learned a lot from all of you.

If I missed any of you, you should add me on Facebook.

Coming Soon:

I finally get my proper ASP.NET work station returned to me in working order tomorrow and I will resume work on my Facebook application, which I am going to publish the full source code to and I will explain the monetization model behind it, should it work worth a damn. Expect results within two months.

So I attended the Facebook Garage - San Diego meeting on Thursday night and I was incredibly inspired by the panel there. I led a panel on Facebook Application Monetization, which I have written about on this blog before, and I learned a lot from some of the other developers and entrepreneurs present at the event. I will be writing about that shortly.

After the event on Thursday I was utterly inspired to get off my duff and complete my Facebook Application. My application is ridiculously simple and I have a monetization model for it, but for the most part I’m writing the application because it is something that I find amusing and I’d use and develop it even if no one else did.

Today I want to vent my frustration with the Facebook Developer’s Toolkit, the Microsoft-endorsed .NET Facebook development platform built by Clarity Consulting and why I’m switching to Nikhil Kothari’s Facebook.NET. I wrote about both the Facebook Developer’s Toolkit and Facebook.NET in a previous entry where I listed all of the available .NET SDK’s for Facebook application development.

The Needs of My Application

Before I get into how the Facebook Developer’s Toolkit failed to fulfill my needs, let me run down what my needs are in the first place:

• Communication with a SQL back-end - like 99% of applications out there, I need some place to store my data. Currently I have an AWESOME data layer built using the methods I described in one of my recent entries on how to design an awesome data layer in ASP.NET.
• Very small data footprint - To give you an idea of just how small the amount of data I need is, my SQL database consists of only two tables.
• Very simple interface - My interface consists of a single form accessible via the canvas page, and if I feel like trying the fake-AJAX stuff that Facebook is building in, maybe I’ll implement it on the profile page too.
• Sets FBML on the Profile - Yes, this application needs to be able to publish to the Facebook user’s profile page area.
• Publishes items to the News Feed
• Uses FBML instead of iFrames - I have a VERY simple interface and the amount of time it would take me to develop an iframe equivalent for some of the features that FBML offers made the choice for me; I need to use FBML.

Now I’m not doing anything spectacular in terms of the technological demands of my Facebook application, but the Facebook Developer’s Toolkit made it hard for me in the first place.

How Facebook Developer’s Toolkit made things Difficult

Before I begin, I need to tip my hat to AjaxNinja reader vjeran, who warned me in an email that the Facebook Developer’s Toolkit was full of bugs and not to use it. If only I had listened.

• It’s not clear what the CanvasFBML class actually does - One problem I ran into right away when I started testing on my live website was that I ran into a ton of incorrect signature errors on my post-application add page. There were no other additional details other than that. When I investigated into the issue on the discussion page for the Facebook Developer’s Toolkit, I came across the first piece of bad news, which is that the subclassed pages do not connect to Facebook automatically. Why in the hell am I giving the subclass members access to my API key and Secret key then? For fun? In short, I have no idea what the base class does, it’s not well documented, and if it doesn’t handle Facebook REST authentication under the hood, then there is no point in me having it. QED.
• There is no method-specific documentation - The title pretty much says it all. There just isn’t any documentation for most of the methods, even IntelliSense documentation. I had a little adventure figuring out how to set the user’s profile FBML using the Facebook Developer Toolkit, and even after I found what I think is the correct method (setFBML(string)), I’m still not sure if it works because I can’t get my FBML application to properly authorize with Facebook still.
• Basically, forget developing FBML apps with the Facebook Developer’s Toolkit - I developed a small iframe application a while ago over at the AjaxNinja labs, and it worked fine as an iframe app. However, developing a full-fledged FBML application is a nightmare that I wouldn’t wish upon my worst enemies. A lot of it is guess work, desperate Google searching for answers, and translating PHP examples into ASP.NET.

Why I’m switching to Facebook.NET

Facebook.NET has even less documentation than the Facebook Developer’s Toolkit. However, it does have a VERY good FBML example, which the Facebook Developer’s Toolkit does not have. I think the Facebook.NET platform is abstract enough that I could flexibly design my own FBML application intuitively, which I was unable to with the Facebook Developer’s Toolkit.

If I ever get this application finished (I was hoping to have it done already), I will be posting the full source code online and I will be documenting some of my own tips and tricks on how to do Facebook Application development properly in ASP.NET.

There is a new problem on the horizon for budding Facebook Application Developers like myself: the average Facebook user hates us and wants us to cease and desist.
In a previous article on Facebook Application Monetization I mentioned that one of the challenges facing monetized Facebook applications is the phenomenon of “Facebook Application Fatigue.” To recap:

Facebook users want a limited number of apps visible on their profile page. This means that your application will not only be competing with applications within similar domains, but your application will also be competing for precious real-estate space on every individual user’s Facebook profile page.

What is Facebook Application Fatigue?

Short Version: Most Facebook applications are useless clutter developed by people who have no idea what Facebook is about. The users themselves recognize this and have grown to resent having to dig through a mess of visual diarrhea just to find their friends’ walls.

Long Version: 99% of Facebook applications have one or more of the following attributes:

• Aesthetically unpleasing
• Useless gimmick
• Provides content totally unrelated to Facebook’s purpose as a communication tool
• Does not work as intended
• Difficult or awkward to use
• Profoundly stupid
• Identical to another, already popular application

You can come to the conclusion that given that there are 3000 facebook applications out there then it has become a bit tiresome for Facebook users to find decent applications in the midst of so many bad ones.

Facebook Application Fatigue is not “fatigue” in the sense that Facebook users are exhausted by the saturation of Facebook applications; they aren’t tired of using Facebook applications at all!

Facebook Application Fatigue is a prejudicial reluctance against trying new applications, because users are protective of their profile real-estate and their time.

To summarize, due to the large amount of Facebook Applications (I’d almost call it saturation), users are now demonstrating and increased amount of selectiveness when it comes to choosing which applications occupy their precious profile space.

Many of the hardcore Facebook users played around with several applications shortly after the onset of the F8 platform release. That was at the end of May; here in August we must acknowledge that those users have grown accustomed to a small subset of applications available to all users, and the exploratory period has come to an end.

Most long-time Facebook users are not going to just poke around the application directory and simply add new applications for the sake of adding them anymore; that time has come and gone. Facebook is all about communicating an image of yourself to your peers, and unless someone creates a truly captivating, innovative, or better F8 application, no one is going to adopt it on a whim.
The Causes of Facebook Application Fatigue

• Chicken and the Egg Problem - In economics a networked service is defined as
  

  any service which increases in value with each additional consumer or user of the network.

  Any networked service is going to suffer from the initial chicken and the egg problem: if we establish the network, how in the hell are we going to get enough users to use it to make it valuable to most users? If you can come up with an easy answer to that question then you’re going to be a wealthy person one day. How does this relate to Facebook applications? In my previous post on monetizing Facebook applications I broke down all successful Facebook applications into three categories: peer-to-peer communication services, interest publication services, and peer-to-peer relationship services.

  • Peer to Peer Communication Applications - This class of applications suffers the most from the chicken and the egg problem; for instance, in order to use the Graffiti application to draw on someone else’s wall, both you and that person need to have the application installed. Competing with a well-established application in this area is very difficult; almost 7 million users have Graffiti installed, and thus that application is significantly more valuable than any other applications that allow you to draw on someone else’s wall, even if those other applications are better or easier to use.
  • Peer to Peer Relationship Applications - These applications still suffer from the Chicken and the Egg problem but not in all instances; for instance, the application Top Friends does not require that your peers use it, because Top Friends establishes a relationship via the expression of user preferences as to which friends appear first on the user’s profile; it does not require two-party consent. However, the Likeness application, which compares how similar you are to other users of the application, very much suffers from the C&E problem as both the comparer and the compared are required to have the application installed. Bottom Line: If both parties have to have to application installed, you have a C&E problem.
  • Interest Publication Services - Since these applications are merely a publishing service for making readers of your Facebook profile explicitly aware of your preferences in regard to books, movies, interests, music, or activities they by definition do not require multiple users in order to have value. However, if you developed an application in which you compared users with similiar interests, you would then run into the C&E problem. The bottom line holds true.

  So how does the C&E problem rear its head for Facebook users? If the application requires two parties to use it in order for it to achieve something of value, then users will naturally gravitate towards the service that most of their friends use. This makes it very challenging for new entrants into the domains covered by services that suffer from the C&E problem.

• Profile Clutter Problem - If every user went and added hundreds of applications like how they did on Mashable it would be an utter disaster for Facebook. The profiles would be so bloated and visually offensive that no one would be able to read it and discern any useful information about his or her Facebook friends. Although the Mashable example is extreme the concept holds true: users do not want their profiles completely overloaded with obnoxious amounts of garbage. Thus Facebook users are going to exercise cautious discretion as to what applications do or do not get added to their profile real-estate; many users have already made those decisions and are satisfied with their current handful of applications.
• Over-Exposed Application Invitation Problem - Invitations to try out new applications are incredibly over-exposed; rather than being viewed as an attempt to experiment with some brand-new state of the art technology, they are viewed as annoying intrusions into the average user’s Facebook experience. I have yet to accept an invitation to try a new application, because if I tried all of the invitations I have ever received, I wouldn’t be able to do anything on Facebook other than try out new applications!
• Weary of Fads and Gimmicks - Applications such as Pirates, Ninjas, and other similar ilk are viewed cautiously by some socially savvy users and professionals as they do not want to have a paper trail to link them to specific fads that may be viewed skeptically by some of their friends. If you think this is true, go ahead and sign up for Pirates and try inviting any of your Professors to the application; I guarantee you the vast majority of them, even the most active Professors on Facebook, will not add them for sake of not being taken by their peers seriously. Facebook can be used as a powerful professional tool, and many applications such as Pirates diminish Facebook’s value as a tool, thus many users who might even find the Pirates vs. Ninjas fad amusing will not install them. Many application designers neglect the fact their applications are a direct reflection of the users who install them.
• Protective of Facebook Time - Many Facebook users are guilty in their own eyes of spending “too much” time poking around on Facebook; this is especially true of college and high school students. Facebook users are aware of their wasted time and some of them are loath to try new applications simply because they view it as another time sink, but this time it’s an opt-out time sink. Many users will simply choose not to install an application simply because they do not want to spend any more time on Facebook than they feel they have to already.

In the near future I will be starting some discussion ways to design application that work around Facebook Application Fatigue. In the mean time, please share your throughts!

Also, for your reading pleasure, check out the Facebook Application Extreme Stress Test from Mashable.

The Challenges of Facebook Application Monetization

• Contextual Advertising Does Not Work
  Steve O’Hear, a social networks and Facebook blogger for ZDNet, brings to light that Facebook suffers incredibly low click-through rates for advertising campaigns (0.04% per 1.4 million impressions) thus ruling out the lazy-man’s monetizing option, contextual advertising campaigns like Google AdSense.As though abysmally low click-through rates weren’t enough to deter one from employing AdSense Jawad Shuaib the author of the most prominent monetized F8 application, “My Favorite Books,” writes:

  Part of the reason is that Facebook does not allow developers to embed JavaScript within their code; hence making it difficult to enable Google Adsense for the content. Moreover, as is the case with MySpace, contextual advertising is not targeted enough to earn sizable revenues.

  I’ll be the first one to thank Facebook for sparing us from a barrage AdSense bulk on all of my friends’ pages.

• Facebook Users are Suffering from “Facebook Application Fatigue”
  When I began telling some of my fraternity brothers and friends that I was developing a Facebook application, the first thing I got was a long groan and something along the lines of “not another %^#@ing Facebook application!” Apparently, this is not just a phenomenon localized to Vanderbilt students; a handful of bloggers are reporting the very same frustrated sentiment.Facebook users want a limited number of apps visible on their profile page. This means that your application will not only be competing with applications within similar domains, but your application will also be competing for precious real-estate space on every individual user’s Facebook profile page.I will be doing a post dedicated to the causes of “Facebook Application Fatigue” in the very near future.
• Large Number of EntrantsThere are nearly 3000 published applications available for Facebook users so it has become very difficult for great Facebook applications to get noticed. It is no longer just enough to simply “add” a Facebook application to the directory and wait for the users to come rolling in; you have to actively reach out to Facebook users and get them to adopt your application willingly.This is especially true given how long the wait delay is on the Facebook Application directory.In order to get users, you are going to have to make your application stand out above the competition. No one will adopt it simply by virtue of its existence.
• Most Facebook Applications Fail to Create Additional Value Facebook is not a “content” service so much as it is a “communication” service. People do not log-on onto Facebook to read RSS feeds, get the latest weather, look-up movie times, and such, as those services are not inherently conducive to Facebook’s function as a communication medium.Applications such as iLike (favorite songs, music videos), Graffiti (MS Paint tool for wall posts), and Video (upload home videos and tag your friends in them) are all popular examples of applications that are conform to Facebook’s original intent.The problem with most application designers is they view user-service interaction as “content” production. The fact of the matter is, Facebook is not user-service interaction, like how Google is, but it’s all user-user interaction with the service acting as a communication link. When a user lists his or her music or film preferences on Facebook, it is for the express purpose of communication those interests to his or her peers, not so random people on the Internet can look them up and say “Oh hey, I like Boondock Saints too!”

Designing a Facebook Application with Monetization in Mind

• Remember Facebook’s Ultimate Purpose - Communicate!
  Avoid the traditional downward spiral that most Facebook application developers fall for - FACEBOOK IS NOT ABOUT CONTENT. It’s about communication. Here are some ways that you can design your application to perform a “communication” versus a “content” service:
  1. Design your application to publish interests that currently are not served adequately by Facebook or other existing applications. My Favorite Books is a great example of such a service; it is essentially an upgrade to the existing “books” section on Facebook. iLike on the other hand publishes song and music video preferences, which weren’t available on Facebook at all prior to the F8 release.
  2. Design your application to create innovative forms of peer interaction that are not currently available to Facebook. Graffiti and Honesty Box are both new ways of communicating to your friends on Facebook. Honesty Box allows you send receive and send anonymous messages and Graffiti allows you to send and receive graphical messages; neither of these services were available before.
  3. Design your application to establish unique relationships with other Facebook users. Top Friends and Greek Family Tree are examples of popular applications used for establishing relationships between groups of users; while Top Friends publishes generic relationships, Greek Family Tree focuses on specific Greek organization hierarchies between older/young siblings.
• Release a High Quality Application Tomorrow Versus a Medicore One Today
  Facebook users are fickle. It comes with the territory of catering to college and high school students. Users pick up and dump Facebook applications all the time; just because iLike is the number one song and music video application today does not guarantee that it will be that way in three months. An application that is
  1. Easiest to use
  2. Occupies the smallest amount of profile space
  3. Provides distinctive communicative value
  4. Is easiest to install and set up
  5. Provides the highest quality of service

  will prevail over the competition so long as those points remain intact. So don’t rush your application for the sake of “being first.” Instead, take as much time as you need to “be the best.”

• For Interest Publication Services: Find Referral Services to Sell Related Products
  The key to My Favorite Books‘ profitability is its incorporation of an Amazon.com referral system. If you’re browsing a friend’s Facebook profile with the application installed, you can follow a link to purchase any of the “favorited” books from Amazon.com, and in the process, earn the My Favorite Books developers a 4% commission on the sale.This is a very simple and easy model to follow. Just find a good referring service for your domain and use affiliate links on all of the interests.
• For Communication Innovations: Charge a Small Usage Fee or Subscription
  This is the model that Facebook employs to for its Gift service; charge a $1 fee for a small graphic of a “gift” to appear on someone else’s page? Well if you have a million users give each someone one gift each, you have yourself a pile of cash.Facebook application developers should not shy away from charging people to use the service; if you charge a reasonably low rate (like $1 per gift), that will not deter people away from using it. If I were the developer of Honesty Box, I would have employed this from its inception. The notion that the entire Internet economy should be supported by AdSense and Amazon.com referral links is wrong. In addition by making your service exclusive to paying users, you will help keep your costs down.Make sure you incorporate a free demo to a number of users during your initial opening, or keep a free, limited version of your service around for the sake of enticing users to users to your subscription or free based service.
• Get Relevant Sponsors
  If you run an application dedicated to sharing your favorite Entourage quotes or Lost theories, getting a sponsorship advertisements for either of those shows is a no brainer. Users who have that app would probably be interesting in clicking on an advertisement for either of those shows; the hard part is getting the ads in the first place!

If you have any suggestions, please leave them here. I have more ideas on monetization ideas but they’re just so good that I need to keep them for myself :p. Stay tuned for when I release my own application in the upcoming months

Application Name:

This is the name you want to give your application; I obviously chose to name mine “AjaxNinja Labs.” Your application name will appear everywhere, for instance, if you add a sidebar URL for your app, the name will appear under your list of applications like this:

Facebook side navigation bar with my application (AjaxNinja Labs) at the bottom

In short, your application name is ubiquitous; it will appear EVERYWHERE your application can be found. Pretty straight forward.

Support Email:

This is your support email address for your application… Should absolutely be an address where you or one of the other developers can be contacted. This is a required field, but for the sake of avoiding spam, I have blurred out my email address.

Callback URL:

This is where things start to get confusing; a callback URL is meant to be the root directory, WITH THE SLASH INCLUDED, of the content for your facebook application on your server. For my application, the root directory is that of my labs area; this callback URL is crucially important as it is your end of the Facebook application service. If this URL is not provided correctly your application will not work.

Facebook call back URLs work essential like proxy servers, including caching. The reason for this? Obviously Facebook doesn’t want applications with crappy hosts diminishing the results for its users, so it caches FBML (Facebook Markup Language) output and checks periodically for updates. Here is a diagram of how Facebook proxying and call backs work:

Note: I do not know how the Facebook caching algorithms work or how often they request updates from your source.

Canvas Page URL:

As you may have seen in the diagram above, the canvas page URL is simply the Facebook virtual directory pointing for the content in your application. This value can be totally arbitrary as long as the URL is available and 7 characters or longer.

FBML or IFRAME:

I strongly recommend using the iframe option, simply because it allows you to design a website under the hood that behaves and acts like a normal website. However, using a FBML markup file instead of a native .ASPX, .PHP, or .HTML file will allow you to use a lot more native tools for facebook and it will render faster. If you’re concerned about taking on major performance hits, FBML is the way to go. If you’re more interested in keeping things simple, stick to an iframe.

Application Type:

This one is pretty simple; if you’re designing a desktop application that connects to Facebook for some operations, then check the desktop option. If you’re designing an application that can be run off of your website, then pick website.

IP Addresses:

If you have some security concerns regarding your application and you want to whitelist all of the allowed IP addresses making service requests, you can enter those IP addresses here. Most applications do not use this feature, generally speaking.

Can your application be added on Facebook:

If you want users to be able to add your application to their facebook account, then check the yes button. This means that users will be able to access the canvas page, add your application to their profiles, and post news feed items regarding your application.

POTENTIAL PIT FALL: If you are still in the development stage of your application, don’t check the “no” button because you want to prevent users from accessing your application, as this will also prevent you and any developers you are working with from testing the application as a user; check the “only developer’s may install application” checkbox further down the page to prevent normal users from tampering with your application in production.

Terms of Service (TOS) URL:

The terms of service URL is meant to be a link to a terms of service document hosted on your server; unless you’re trying to build a Facebook app where you can potentially run into some privacy issues, I’d recommend leaving this blank.

Application Icon:

First, every application should have an icon, period. Your icon will be shown alongside your application name in every instance the app name is displayed, so it’s important for establishing branding. The icon dimensions are 16 by 16 pixels and it must in the GIF format.

Post-Add URL:

This URL can be on your local hosting, and users are redirected from Facebook to here immediately after adding your application. I just goofed around a put a random link to one of my blog entries on there, but if you want to do something like send them to an instructions page, this is the place to do it.

Application Description:

Self-explanatory. This is the description that appears next to your application on the “About Application XYZ….” page.

Post-Remove URL:

Update from AjaxNinja Reader Harry:

When a user selects to remove your application they are not sent to the ‘Post-Remove URL’ as they have removed the application and so will have no further contact with it. A POST request will be sent to this address in the background however containing the uid of the leaving user.

Thanks, Harry for helping us clear up what the Post-Remove URL does!

Default FBML:

This is the FBML that will be visible in the profile by default. Example:

Default Profile Box Column:

There are two columns on any Facebook profile page: the wide one on the right and the narrow one on the left. Users can drag and drop your application on their profile to either column, but if you want to specify a default column you can do it here. Here’s what they look like:

Narrow Column:

Wide Column:

Developer’s Only Mode:

If you don’t want any noobs (normal people) messing around with your application while you’re still in the process of developing and testing it, check this button.

Side Nav URL:

This is an important one. If you want Facebook users who have installed your application to be able to access it via sidebar, you need to provide them with a URL so they can have a link on their sidebar. For many applications this link is the application’s primary entry point.

Nota Bene: Notice how I have used an internal Facebook link here… this is how I get Facebook to actually implement my iframe within a Facebook page.

Privacy URL:

If you have some custom privacy options that you’d like your users to be able to set, place a URL to that here. Again, it can be internal like my sidenav example or external.

Help URL:

If you have a help page for your users you can place a link to it (internal or external to Facebook, again) here. Although I have no idea where it actually appears as I have tried looking for mine.

Private Installation:

If you want to prevent information about your application from appearing on news feeds or mini feeds then check this box.

Upload URLs:

If you want to allow uploads in your application you need to fill out both of these fields. Frankly, I don’t know quite how the action field works, but the callback URL is just your local URL for handling the file upload.

Leave some suggestions, comments, or improvements!

Also, be sure to check out this sweet first facebook app tutorial on Tucows.

While I typically don’t like writing small posts, this one is too good to pass up.

Check out the article on Mashable!

Regardless, I’m amassing some reading materials for developing Facebook Applications, and while there are not a lot of resources out there for .NET specifically, there are some good tips in general. Here’s my list:

1. How to Write a Facebook Application in 10 Minutes
2. 5 Facebook Application Gotchas
3. 10 Things That Would Have Been Nice to Know When I Started My Facebook Application
4. Finding Sample Code for Facebook Applications
5. 10 Tips for Releasing your Facebook Application, and Maximizing Growth
6. How to Develop a Hit Facebook App: 29 Essential Tools and Tutorials - YOUR BEST HOPE

In addition, I wanted to follow up on my 10 GDI+ Resources for ASP.NET Developers post by adding that I found a really kickass custom server for automatically doing graphs and I will be including it in my Facebook application; it’s a custom chart control from the CodeProject, which you should check out.

I’ll be posting some results for my own Facebook Application within a couple of weeks, but I still have a ton of work to do on the data layer, business layer, and I haven’t even thought about the presentation layer yet, but that’s what these articles are for!

1. Click on the bottom right hand corner of any Facebook page and click the HELP link.

2. Once the help page loads, click on the SUGGESTIONS tab, because this is where you can make a SUGGESTION to FACEBOOK. Mashable is not the place to make a SUGGESTION to FACEBOOK because Mashable is, in fact, NOT FACEBOOK.

3. Write a polite letter and hit the send button; letting Facebook aware of your opinions without taking up readable space on the Internet, inciting idiots to paranoia, or readers with half a brain into fits of rage.

As though it were not bad enough that Living in First Life-certified Dumb Bloggers like Robert Scoble are obsessed with Facebook anyways, we now have to deal with the fallout from the Mark Zuckberg v. ConnectU guys trial. FUCK! But wait, it gets better! Now Mashable is drawing wood for a new web design company that focuses exclusively on Facebook Apps! THANK GOD! Maybe I’ll hire them to make my Facebook App! Had enough Facebook, how about we let the geniuses at TechCrunch tell us how to create our own social networks, just like Facebook, God of the Web 2.0 Universe!

Please, enough with the Facebook. Sure, I love seeing pictures of drunk college students as much as the next person, but for the love of God I do not want my Technorati page raped by Facebook fanboys again.

1. Facebook.NET - By Nikhil Kothari, author of Developing Microsoft ASP.NET Server Controls and Components
2. Facebook Developer Toolkit - Developed by Clarity Consulting and endorsed heavily by Microsoft; integrates very well with Visual Studio Express.
3. Visual Studio Starter Kit for Facebook - By Steve Trefethen
4. Facebook API Client Library for VB.NET - By Jay Lagorio; this is earliest implementation of the API that I had come across.

Also, be sure to check out the ASP.NET page on the Facebook Developer’s wiki… Even though its list of .NET controls isn’t as up-to-date as ours

On an aside, check out my first demo at our ASP.NET mobile laboratory, even though it’s just a simple test, I still thought it was pretty cool when I used my treo on it. I’ll be publishing more demos throughout the week on our lab page.