On Thursday, Google rolled out an update to its personalized home page service, iGoogle. Among other UI updates, the major new features were increased flexibility in what “gadgets”, the personalized “chunks” that make up an iGoogle start page, can do. This, in turn, allows developers much more freedom with what they can provide to the user through an iGoogle gadget.

Previously, gadgets could only occupy a small box that took up only a third of the screen. While this was okay for reading headlines or perhaps glancing at stock prices, it limited the usefulness of gadgets and the information that could be provided. For more detail, users would often have to click a link in the gadget that would take them away from iGoogle. While this is perhaps the proper use of a “start page”, Google may now see things differently.

Life is a great big canvas

Gadgets now offer a near full-size “canvas” mode, where the gadget is expanded to take up most of the screen. This allows more information to be displayed and makes the iGoogle page less of a start page and more of an aggregator - like an RSS reader, but with much more.

Speaking of RSS readers, any RSS feeds on iGoogle can now be expanded into a full-feed view, using a layout/interface not unlike that of Google Reader, their specialized RSS reader product. All of these enhancements are designed to help you get the information you want, without having to leave iGoogle.

Some good examples of gadgets taking full advantage of the new functionality offered by the new iGoogle include the GasBuddy gadget, which display a small labeled map of local gas prices in the “mini” mode, which expands to a fully-searchable map complete with a clickable legend in the full-screen canvas mode.

Google’s own products, such as the Gmail and Google Calendar gadgets, have also been updated to nicely take advantage of the new abilities. In canvas mode, each gadget expands to fill the screen with pretty much the same UI as their respective web applications. This makes accessing your various Google Account services easier and decreases load times.

Content and Money

Others include the Wall Street Journal’s gadget, which in canvas mode looks similar to a start page of its own. Interestingly, ads are shown in this mode, presumably from the WSJ itself. This highlights another important aspect of gadget development: Income.

This is really the crux of the iGoogle update, in my opinion. By allowing giving more power to developers and allowing more content to be shown on iGoogle, developers can have more flexibility with their creations. In return, Google is apparently willing to allow them to show ads so they can make money off of their creations, which clearly add value to iGoogle.

It’s hardly an original idea. Facebook has had their own applications platform for well over a year, with much of the same ideas. Facebook Apps are made by third party developers, and mostly run “within” the confines of the main Facebook site, keeping users on the site. In return, developers can also choose to run ads in their application to generate revenue. It’s a very similar model. (Facebook recently awarded some of the best apps through their fbFund initiative, with the promise of more money to come - perhaps Google will do the same? They’ve already done something similar with Android in order to spurn development)

Not so fast

Unfortunately, the changes were not all good. For one thing, the vast majority of existing gadgets haven’t been rewritten to take advantage of the full canvas mode. In all likelihood, many will not, since third party developers may do as they like. Gadgets that haven’t been updated will merely be displayed besides a huge “You might also like…” list of recommended/related gadgets when displayed in full-screen canvas mode.

Furthermore, some users have complained about the UI updates. In particular, the mandatory left sidebar now in place has caused some to lament the loss in screen real-estate. Previously, tabs were only shown on top if you had defined more than one; now the list of tabs, along with the iGoogle gadgets in each one, are shown in the sidebar no matter what.

Indeed, such a display might be superfluous if there’s only one tab. At the very least, Google should have allowed the sidebar to be collapsed or tucked away. (I won’t be surprised if they implement this change in the next few days, or already have it planned)

Also surprising is how Google rolled out the new version so suddenly, effectively forcing all users to adopt it. A better approach would have been to roll out a “beta” version (we all know how much Google is in love with beta) and allow users to preview it and optionally switch. This would allow them to get more feedback before switching everyone over, like Facebook did with their new redesign, which effectively took months to take effect.

However, given that iGoogle’s user base is likely a very small percentage of all the users who have Google as their start page (with most just preferring the stripped-down original search page as their starting point), perhaps Google believed that rolling out the updated site would affect so few that a beta period wasn’t really needed. In any event, the changes are not so ground breaking to warrant serious concern.

It’s been a while since Facebook introduced the concept of “applications” to their API, providing developers a very flexible set of tools to create and add features to Facebook itself. Applications on Facebook are best described as “widgets”, since they offer functionality that’s often provided by widgets on other sites, so why Facebook chose a different name is somewhat peculiar.

I’m not going to debate the merits of these applications, or whether they’re leading Facebook down the road to a MySpace-hell dominated by personalized profiles that are an eyesore (there’s already enough discourse on that subject, both on Facebook and outside of it), but rather I’ll take a look at this from a developer’s point of view. What is the potential for developing an application for Facebook, and at the same time, what are the pitfalls?

Pro: Relatively easy to develop

Facebook’s API is easy to work with, especially if you have experience with PHP. One of the official client libraries is written in PHP, and since it’s intended to be used for web applications, this makes perfect sense. Using it to develop an application should therefore be a relatively pain-free process.

While the documentation isn’t always complete, there’s a nice Wiki that covers additional details, and together, these two should allow you to overcome most problems you may run into during development.

Overall, the abilities offered by the API coupled with its ease of use make development relatively straightforward.

Pro: Access to a large user base

Facebook’s current user base of 30 million is rapidly growing. It’s already doubled since the start of this year, and continues to grow at close to 3% per week. If that rate continues, they’ll double again by the end of this year. But perhaps the most amazing fact here is the dedication of Facebook’s user base. It’s one thing to have millions and millions of users, with only a small percentage that are actually active. This isn’t the case with Facebook, which sees over half of its users log in daily. That’s an astonishing statistic by any measure, and even more so when you consider Facebook large and fast-growing user base.

Thus, developing an application for Facebook gives it access to a large, and more importantly, active user base. This gives it a huge potential to grow virally, that is, from person-to-person. When someone adds your application to their profile or account, it will show up as a News Feed item. This means that anyone who has this user as a friend will see a message in their News Feed about this user adding your application. The idea is that they might get interested, click on your application, and then add it to their profile as well, continuing the viral spread cycle.

They can, of course, also find your application by doing a search - if you’re lucky enough to get your application listed in Facebook’s official application directory - more on that later.

Con: Cost and scalability

I think Marc Andreessen (of Netscape fame) put it best when referring to the popularity of an application on Facebook, namely that success kills. (The rest of his article, while lengthy, is an excellent read and I suggest you take the time to read it) Marc gives the example of the iLike application, one of the first, which experienced an insane growth in the early stages. During that time, they grew by 300,000 per day, eating up all of their capacity to the point where they had to buy new servers on a daily basis.

While a company such as iLike, with sources of revenue, may be able to shoulder this kind of burden, it’s quite unlikely that a lone developer would. This creates a sort of Catch-22 - you want your application to become popular, so that you could hopefully monetize it. However, in order for that to happen, you need plenty of resources - which require money.

If all you’re looking to create is a neat little application for you and your friends, or if your application doesn’t really create a huge load on your end, you’ll probably be alright. But be aware that the same dedication and large user base of Facebook that can be so excellent for spreading an application, can be the same environment that quickly overruns your capacity to support your creation.

Con: Monetization

While we’re talking about monetization, it’s worthwhile to point out that if this is your main concern, it’s probably best not to pursue Facebook application development. Since support costs can be high for Facebook applications, attempting to derive a successful business model on this will most likely be met with limited success, if any. Some have called for Facebook to start a revenue sharing program, but this is unlikely, considering Facebook’s uncertain financial future - even if the IPO rumours turn out to be true. (Which they likely will be)

A revenue sharing program, however, would be fair, since by creating a successful application you are adding value to Facebook’s site, and directly increasing their revenues by nature of increasing the time a user spends on the site. I would not, however, hold out on this to develop.

This doesn’t mean that application development is limited to those who just want to create something “for fun” or to add something to their portfolio. On the contrary, I believe the best opportunities the Facebook platform affords is to other businesses based on web services. By utilizing Facebook, they can create applications that promote their site, or tie into their own API, thus using Facebook’s large user base as a source for new customers, users, and thus revenue. Indeed, the first applications developed were made by companies with this very intent. Other sites could follow this model.

Other Cons

Some believe that the viral nature of Facebook apps has been overstated, and that they now don’t spread as easily.

Another, more serious aspect, relates to something I alluded to when I commented on Facebook’s introduction of their Marketplace, a classified-listing type service. It seems that in the TOS of the Facebook Platform, they reserve the right to make a similar application to yours, without obligation to you. I don’t know if this is standard legalese in a TOS for API usage, but certainly it can be construed to be something more sinister, and would deny you any right you had to something you’d created. Of course, if Facebook did do something like this, I’m sure there would be an uproar from the community, with Digg fanning the flames, of course.

Privacy, as always

Privacy is also a concern, as it now not only falls on the user to determine what settings to implement, but also whether developers will respect the TOS of the Facebook Platform. The documentation clearly outlines what user (and user’s friend) info can be stored, but there is nothing to stop a developer from storing more of that information, either for the purposes of adding another feature to their application, or for malicious intent. There have already been concerns about this with popular applications.

The issue of privacy here is that when you sign into a Facebook application, it basically has access to all of the friend info that you would - after all, it probably needs this to perform whatever function it does. Though you may have consented to allow this information to be used, your friends may not have explicitly done this, and may not want their information to be used by 3rd party developers.

Though users can opt-out of participation in the Facebook Platform altogether (and thus prevent 3rd party developers having access), I’m guessing that not everyone or even a majority know about this feature. The privacy settings of Facebook have grown almost as much as the site itself, with settings divided amongst sections and sub-sections, creating somewhat of a convoluted mess. The best precaution to all of this, of course, is not posting anything on the Internet that you wouldn’t want to be known in public. This applies not only to Facebook but other sites as well; I only emphasize this for Facebook because of the notoriety its obtained from such incidents.

Facebook recently launched the latest version of their Platform, which combines their API with FQL and the new FBML. Facebook launched the next version of their platform at their developer’s conference, and accompanied the launch with many partner companies that rolled out applications designed with the platform simultaneously. This was also a huge event for independent developers, many of which got to work immediately on their own Facebook apps. (Thousands are now available) This is a huge event in the history of Facebook, and perhaps the next step in where the hugely-popular social networking site will go. As with any change in a social networking site, this one was met with some resistance and concern, but is it warranted?

The basics

The Facebook API has been around since last year, but has since added many more features. In its first version, there were only a limited number of methods one could call to request data. Early this year, they added FQL, their own SQL-like query language to allow for more flexibility in accessing that data. (In fact, now most of the API calls merely map to FQL queries as well) This newest version has added FBML, Facebook’s own markup language. Just like FQL is related somewhat to SQL, so is FBML to XHTML. Thus, web developers will have no problem adjusting to these Facebook-specific languages. From Facebook’s point of view, this makes them way more popular with developers.

FBML is big because it allows integration of Facebook apps with the main site. Before, Facebook applications were run on the developers’ own sites, and didn’t really hook into the main site. While the backend of the application will still have to be run off another site, data from the app can be neatly hooked into the main site in a variety of places, providing slick integration with Facebook itself. To quote Facebook:

You can hook into several Facebook integration points, including the Profile, Profile Actions, Canvas, News Feed and Mini-Feed.

This effectively turns Facebook apps into “widgets” that add features and functionality to the main site. In this way, users can pick and choose what neat apps they want to use on Facebook. At the same time, Facebook can keep the site neat and clean, because the integration makes it easy to adopt the Facebook “look & feel” for these widgets, preventing Facebook from turning into the graffiti-invested section of the web that MySpace is.

It’s about developers

Besides the ease with with most web developers will be able to learn the use of FQL and FBML, Facebook has also redone their Developer’s Site, making it look more different and separate from the main Facebook site. Most of the information remains the same, but it has been organized and streamlined more, and there are plenty of examples. Facebook also took the time to sign up many launch partners. For example, Last.fm quickly launched their Facebook application, and it’s quite popular.

Even more interesting is that Facebook is letting application developers keep the revenue made from ads served through their application. I guess this is a win-win situation, since by using the app, people stay on Facebook even more, so in the end, they make more money as well through their own ad system. This allays some of my fear outlined in my previous article about Facebook competing with services created through their API.

The OS of the web?

If this really is the case, then it signals a new direction for Facebook. No longer content to be just a popular social networking site, they now want to be a platform for all sorts of applications that will automatically have a wide audience. In this way, you can view Facebook as the “OS” and all of these widgets as the applications created for the users, in this case, the membership of Facebook. Users can easily pick and choose which apps they want to use, so nothing is forced upon users. Even “core” Facebook features such as “Notes” are placed under the same heading of “Applications” alongside user-created ones, so you can even opt-out of these.

This will have the overall effect of making Facebook the central place for social-networking. No more will users have to wait for Facebook itself to add features to the site, as if there’s enough need, some enterprising web developer will add the functionality. Want a calendar? 30boxes has one. (I’m waiting for a Google Calendar widget) Overall, I’m really impressed by the technical ideas behind all of this.

MySpace syndrome

One huge concern is whether or not allowing users to add any widgets they want to their profile will result in Facebook’s quality deteriorating to MySpace-like levels. No doubt that was a huge concern of the Facebook team, as they have built a successful social network that many users see as being more mature than MySpace. For the most part, they’ve accomplished this - integration with the main site has been done in a controlled way to ensure that widgets keep with the look & feel of the site, and don’t allow someone to turn their profile into an ugly affront to the visual sensory system.

However, users can still tend to overpopulate their profile with too many widgets, making things look cluttered. And, there’s nothing stopping anyone from making drawing widget. But perhaps the most unwanted feature was the addition of “trackers”. Many MySpace profiles now feature these - basically a link or an image to a third-party server that once loaded, can tell the profile owner who has visited their profile and how many times - a sort of form of reverse-stalking. Facebook took steps to ensure that this was not possible with their widgets.

This hasn’t stopped anyone from making such a widget for this purpose. However, this widget requires a user to click a link on the profile page in order to be tracked. In order to do this, they try to attract you to click this link because it sends you to a page that also shows who else has viewed the profile. It would seem that people’s capacity for voyeurism is boundless. However, as with all apps, you don’t have to add it, and you can even block or restrict it if you want.

In the end

All things considered, this will be beneficial for Facebook’s bottom line. I seriously doubt they’ll lose any significant number of users from this, and will certainly gain more and keep the existing user base happy and interested in what they’re doing. I think they learned from last year’s uproar over the introduction of News Feed that the loudest dissent starts right after the addition, and dies down soon after. News Feed is now an accepted part of Facebook, and I don’t think anyone would want to go without it.

It seems that before the launch of this service, Facebook decided to solicit some feedback from its users about its usefulness to them. After the “debacle” that surrounded last year’s introduction of the “News Feed”, perhaps they were a bit edgy about introducing new features without getting their users’ opinions. However, I believe this new service will be a big success, and should have come earlier. It also perhaps signals that there are more services to come.

If you build it, they will come

Yes, this is true, but with a slight modifier: If you build it, they will come, and possibly complain - but they’ll still come. Look at the news feed - when it debuted, users were up in arms about the “privacy violations” that it would bring. Now, it’s just as much a part of Facebook as anything else. At the core, it’s a good feature, but people just hate change. After they adjust to it, as long as it’s a good change, they’ll like it. And, considering that most of Facebook is the under-30 crowd, who easily adjust to new changes due growing up with computers, the adjustment won’t take long.

Which is why it’s perhaps a surprise that Facebook didn’t introduce this feature earlier. It fits right in with the concept of Facebook, that is, a localized social network of people you actually know. Research shows that people use Facebook like it’s a drug, and now that this new Marketplace is up front and center, it’ll be sure to attract lots of usage, perhaps even providing real competition to services like craigslist. Perhaps that’s the real power of Facebook - it has the ability to provide a huge audience to new services, provided they’re good.

In fact, many developers have rolled out similar services before Facebook’s, some of which even use Facebook’s own API to tie-in the service with Facebook. Also, Oodle recently sponsored a group on Facebook to attract users to its own classified service, though how effective this will be in light of Facebook’s new Marketplace, remains to be seen.

Part of the plan?

Facebook’s hesitation may have been part of their overall plan, though. No doubt they have smart people working for them, monitoring various online services that they’d like to compete against. They may have seen the popularity of classified ad sites, or more importantly, those that were using the Facebook API to implement their services. By allowing these sites to “take the plunge”, they could gauge the viability of such a service to the Facebook crowd - that is, whether it was worthwhile or not. Then, once they were convinced, they could begin working on an in-house version, that once ready, could be dumped onto “the masses” for an almost-certain success. Perhaps this was at least a part of the reason for the development of Facebook’s API last year.

Feature creep

Though I believe that this should have come earlier, I respect Facebook’s hesitation at introducing new features. Facebook, at it’s core, hasn’t changed much. They’ve only added new features slowly, and by doing this they avoid feature creep - the stage when an application has so many features that most users don’t know what they all do, and as a result, it ends up feeling bloated. Remember, when it comes to widely-used applications, simple is beautiful. By introducing new features only once in a while, Facebook gives its users time to adjust, so that they don’t feel like the site is changing into something very different than the one they joined.

However, I believe this may signal the end of Facebook’s Flyers, a paid ad feature. These were little user-generated ads that could be purchased for a fixed rate - you could, for example, buy an ad that would be displayed for 10,000 page views. Most of the ads that I saw were classifieds and would fit right in the new Marketplace section of Facebook. Now that you can place such an ad for free that people can search for, I see little use for “Flyers”. Facebook will likely quietly retire this feature, or it’ll only be used by companies wanting to advertise products and promotions.

Now, if you’ll excuse me, I have go list my textbooks on the Marketplace.

If you open it, they will come

Opening an API up to developers is a great move, for several reasons. Firstly, it signifies that your organization is open to feedback and ideas from the community, and gives them the green light to develop new uses for your service. Developers will surely create new applications and plugins that allow your service to be used in many different contexts, thus increasing both the popularity and scope of your website or service. But, perhaps the best part is that these developers willingly create these extensions, offering improved functionality, for free. As much as I hate MySpace, they could learn a thing or two from Facebook’s API move, considering they’ve made moves in the exact opposite direction. The release of this API, for Facebook, is further insurance that their service will have staying power with its users; it’s already been reported that 85% of college students are using it, with the majority logging in at least once a week.

In many ways this is like a game developer releasing a SDK to allow other developers to create mods for it. No matter which way you look at it, the end result is beneficial to all. The original game developer gets more exposure, end users get more substance, and mod developers get a chance to show off their skills.

Facebook is also popular with the geeks

As mentioned before, developers are already at work making new services for Facebook; it’s almost as if they were waiting to pull the trigger on this one - and this is only on the first day! Though the beta API is somewhat limited, some ideas that could be done include: working with a user’s events to transform them into a syndicated format (such as RSS or Atom), or even to move them over to a different format (like iCal) or service like Google Calendar using their API.

Another use that’s been talked about is somehow integrated Facebook functionality with Google Maps, using the respective APIs - that would totally rock. However, at present time I don’t think it’s possible - I don’t see any methods available for getting location information, but in the future, I see this becoming a reality. Edit: I stand corrected. Check out Facebook Friend Mapper. (There is a users.getInfo() method that I apparently completely missed.)

At present time…

As mentioned, the API is currently in beta, so expect more methods to be added beyond the original 14 that are currently described in the documentation. Some other facts from the terms-of-service are:

API use is currently free, but this may change

This is pretty standard legalese. You’re currently limited to 100,000 requests per day.

You are not allowed to store Facebook data on your site

Makes sense as well; it’s Facebook’s data, they don’t want you just copying it and hosting it off-site.

Intellectual Property - you own all the code you create

This is a pretty important one. Facebook won’t “appropriate” what you’ve created, but at the same time, you’re responsible for what you create, not Facebook. If you develop an application that makes the user’s computer catch fire, burn down their house, and kill their kitten, obviously Facebook is not going to foot the legal bill.

Facebook can expect good returns on this move; many users have wanted a calendary to display their events, and now that functionality can easily be added by a developer, without Facebook even having to commit time or money to it. Other features could be added in a similar manner, if Facebook continues to add to their new API.

Facebook is pretty much the only large, well-designed social networking site, and the release of their API only furthers this positive perception. MySpace is pretty much the exact opposite, and I don’t think they could care - they have plenty of users, are making a lot of money, and just signed a huge deal with Google. For them, it’s a classic case of “if it ain’t broke, don’t fix it”. Too bad that basically keeps them where Geocities was during the late 1990’s. Kudos to Facebook for being progressive.