FBML, or Facebook Markup Language as it's called, was intended to ensure that malicious apps couldn't inject nasty code into the browsers of users. We assume that the new markup will have security taken care of by server side processing and this could enable an explosion in feature sharing and code efficiency.

• iLike offers tags that let you display favorite songs and playlists, complete with controls to listen, dedicate, watch, and make ringtones of those songs.


• Causes offers custom tags that let you show your support for your favorite
  causes by displaying badges that invite users to join and support the cause.


• Graffiti offers tags that let you draw and display graffiti.


• * Visual Bookshelf offers tags show the most popular books by category.

These tags should be reusable and offer some amount of customization, but the source code doesn't appear to be open. We'd love to see these tags expose their code to developers so they can be more easily altered for reuse in different ways by different apps.

Though there have been thousands upon thousands of apps built on the Facebook platform, many of them are of poor quality and have suffered since the company instituted a site redesign for quality control. Though effective app design is a competitive advantage for numerous apps that are making a shocking amount of money from ads and micropayments, we believe that at least some developers would be happy to share their best practices in the form of open, editable tag code if they were given the opportunity.

We'll see if that happens or if Facebook remains an essentially closed ecosystem, despite this big move made today. Read more about it on the Facebook Developers' Blog.

API publishing is no longer the future; it has clearly arrived. Companies from Best Buy to MTV Networks have jumped into the game, and more are taking the plunge every day. But what differentiates a successful API program from one that "never leaves the station"?

Before you can determine outcomes, you need to define the criteria by which you will evaluate the progress of your API program. It is important to realize up front that direct revenue is not the only metric; in fact, focusing on immediate revenue at the expense of longer-term benefits can be an expensive diversion.

Look at your API program from a bird's eye view. Are you trying to create entirely new revenue channels, or is brand awareness your primary mission? Are you trying to add more partners to existing programs, or are you more concerned with extending the reach of your interactions with customers?

Well-defined expectations are key, but there is an important corrolary: you need to be ready to take advantage of unplanned opportunities. Michele Azar of Best Buy recently described how opening the company's API to Geek Squad employees produced unexpected benefits. By moving quickly to harness the energy of these employees, Best Buy produced immediate, tangible results.

Measure Outcomes

Depending on your goals, some metrics will be more important than others. However, it is worth keeping tabs on all aspects of your program. API publishing is a process of discovery. Having a plan is imperative, but you will likely need to adjust that plan along the way. A clear 360-degree view of how your API is being used will give you the ability to make those adjustments with confidence.

Here are some metrics to track that we have gathered from our customer base and want to share with you:

APIs can reverse the traditional business development model. Instead of looking for partners, you can use your API to attract potential partners and to function as a vetting mechanism. Those developers who are doing good work with your API will likely be inclined to engage with you further. Be sure to delineate which partners are coming in via your API program; you may be surprised at the cost effectiveness of your program as a business development tool. By making its API available for commercial as well as typical non-commercial use, the Calais team at Thomson-Reuters saw a five-times increase in its business development pipeline in just a few short months.

One of the keys to tracking the success of an API is measuring traffic back to your site. How do you know who has sent you the traffic, and how do you make sure they link to you if you give them the content? Just as with Google Maps, making your content and services available for free will require that your terms of service include some level of attribution. This attribution will allow you to track the traffic back to your site from each partner.

Depending on how your API is being used, applications may provide entry points to a subscription-based service you provide. Thumbplay and Dada Entertainment are both off-deck mobile content providers that seek to register subscribers to their services. They have opened up their APIs to allow new affiliates to help them sign up subscribers. In turn, they compensate affiliates for each new subscriber. At the Business of APIs conference in early 2008, Thumbplay talked about the short-term results of its recently launched API program. It took the company two years to get to 40 partners, but with its API program it acquired the next 40 active affiliates in six weeks. Measuring the number of subscribers that come from its successful API program has become a key part of Thumbplay's monthly board meetings.

Reaching beyond your website can improve customer satisfaction and interaction. Mike Hart, Director of Engineering, Web API for Netflix, describes this as "delighting subscribers." The company is giving customers access to new means of interacting with Netflix. The measure of success for off-site interaction is called an engagement metric. Users can interact with content and services elsewhere on the web, and Netflix measures the ongoing engagement by watching the API activity on its partner sites. The higher the API calls, the higher the engagement.

CBS Interactive built a new API with the specific aim of weaving its disparate online properties together more tightly. An internal dashboard allows managers of various CBSI sites to easily integrate content from other CBSI properties. The time savings from this streamlined workflow is not just a good way of saving frustration: it is also a serious cost-cutting tool. In such situations, analysis is not a luxury; it is an imperative.

One large media company recognized that by launching an API program, it could reduce the cost of internal development. With the API, it can now deliver one to two new products and 50+ features each month to its service. In today's economic environment, this might be a valuable measure of the program's success.

Some of the more mature API programs, such as those of Salesforce.com, eBay, and Amazon, measure things like "number of transactions that occurred through the API." Take a look at your business functionality. Is there a growing number or percentage of transactions that occur because of partner API use?

Perhaps the most important thing to remember is that publishing an API is an ongoing project rather than an event. You have to stay engaged with developers, track what they are doing, and measure the impact of your program. Staying flexible will give you the ability to pursue those opportunities (expected or otherwise) that your program creates.

If you enjoyed this post then check out Mashery.com, the leading provider of API management services.

Using the Mobile Application Generator

Using the tool is simple: you just enter in a blog URL or RSS feed in the box provided in order to get started. Next, you enter in the name of your application. There's an option for you to upload your own image to use as the logo which appears on the launch screen. If you choose not to add an image, the AppLoop logo will display the app launches.

The generator will automatically select a color scheme that matches the first image found in your site's code. You can customize this color scheme if you wish by selecting one of the preset schemes available or you can create your own.

You can then choose an image to use as an Application Icon which appears both in the AppStore and on the mobile device's desktop. You must categorize your app (entertainment, news, etc.) and select which Application Stores you want your app to appear in (iTunes and/or Android).

The final step is setting the price for your application - you can leave it set to free, or set another price using the drop-down list. If you choose to charge for the app, AppLoop will give you 60% of the revenue earned. You can optionally integrate various revenue models or advertising schemes within your application if desired, and the company can help you with those options. If a publisher wants an Ad Hoc version of the app to test before going live the App Store, the company can assist with that as well.

Your app will include the company's analytics package so you can monitor your app's popularity and usage.

Reading The News In The App

Once the app is installed on a mobile device, users have the option to "favorite" an item in the feed to read later. This is similar to starring an item in Google Reader. There's also a button at the bottom of the post to share the item with friends via social media. You can post to Twitter, digg the story, send to Facebook, or even email the story to a friend.

iPod Touch users who have to rely on Wi-Fi will appreciate the app's content caching feature. The data within the application is stored locally on the device so it can be accessed at any time regardless of whether or not an internet connection is available.

Upcoming Features

AppLoop says this mobile app generator tool is only the first version of the application. Upcoming versions will offer new features like support for third-party plugins, commenting, rating, multiple categories and feeds, and other widgets. Another upcoming feature will be a new community layer on top of all applications which will provide for live chat and sharing options. AppLoop may launch these additional features as a premium version of their tool, but the basic version will always be free.

Extending Your Reach

As a publisher, there's a real need today to be able to extend your content beyond your site to other platforms. RSS provides a means to do this, but with the launch of the iPhone, there's another way to reach your readers, too: via iPhone apps. Despite the popularity of the games and other time-wasting apps, there's also a lot of people out there using apps to get the news, too. Take the AP News app, for example. Out of their 16 million pageviews in August on all mobile devices, 95% came from iPhone. With this new tool from AppLoop, any publisher can take advantage of the iPhone platform (and soon the Android platform, too) by making their content more portable and easy to access from anywhere.

Note: Screenshots from a RWW iPhone app, not yet available in App Store

When LongJump first launched, the PaaS (Platform-as-a-Service) model was only just taking off. Since then, we've seen Google launch their App Engine and more services than ever are taking advantage of Amazon's EC2. Today, the Sunnyvale, California-based PaaS provider, LongJump, tries to one-up those big-name sites with the launch of their new LongJump Development Suite, a tool set that helps developers extend the power of LongJump by allowing interoperability with other systems and applications.

While this ease-of-use made LongJump ideal for enterprise I.T. teams looking for fast and easy ways to build and deploy apps, allowing those apps to interoperate with data from other applications and systems was not possible until now.

About The LongJump Development Suite

With the new LongJump Development Suite, an I.T. department can build the app they need, then use the included visual browser-based UI for data and process modeling. Alternately, they could instead choose to hand of the integration of the app with another system or application to a developer (or team of developers). Finding a developer to work with LongJump shouldn't be an issue since the suite provided is a Java-based development environment complete with a plug-in to the Eclipse IDE (Integrated Development Environment), something that's used by 69% of Java developers today. LongJump also provides a set of service integration points using SOAP and RESTful APIs to connect to other external systems.

Why LongJump?

Unlike both Google and Amazon, the focus with LongJump is on application creation, not just the delivery. When you build on Google or Amazon, you still need to know how to build - you need to know code. LongJump is focused on letting anyone build without code. They aren't the only ones thinking this is the next big trend for the web, either. Earlier this year, for example, we covered an app called Iceberg whose aim was to allow anyone to become a developer.

Will this trend take off? For enterprise I.T. organizations, their bottom-line focus is usually money and time. If PaaS offerings like these mean custom apps can be built quickly and easily without needing to hire outside dev teams, there's a good chance for their success. However, they do have to fight with a number of already decent solutions out there. Thanks to the Web 2.0/Enterprise 2.0 movement, there are already a slew of business applications built and ready to go. These apps might not be perfect but are often they are often "good enough," and that's proven to be a good way to get in the door of the enterprise...just ask Google Docs.

A few blogs ran with the story that Google might be considering building the gPhone after all. The reason for this latest round of rumors? Hollywood Reporter's Dan Cox wrote an article summarizing a semi-formal press conference on Friday where Google co-founders Larry Page and Sergei Brin and CEO Eric Schmidt met to discuss the state of the technology community. In the article, Dan wrote: "The trio of Google execs also used the opportunity to talk about the inroads the company is making with its own branded mobile phone as a replacement for the iPhone." Add to that a claim that the Ammunition Group is designing it and you've got a full-on Gphone rumor.

Unfortunately, the rumor is most likely just that - a rumor. Silicon Alley Insider took a look at Reuter's reporter, Ken Li's, notebook from the event and made the determination that "the Google guys were talking about the fact that they're not producing their own branded phone, and that there isn't a 'Google phone.' And something got mixed up in the translation."

They also made the rather sensible statement that "if the Google guys had talked about a major change in their mobile strategy, you'd think the story might have appeared in other outlets."

We asked Google for comment and they actually pointed us to the same Silicon Alley Insider story, saying it was all just a misunderstanding by one of the reporters in the audience. They also noted that their hope for the Android platform will spur the development of thousands of different kinds of phones.

We wonder though, if these rumors point to the fact that there may be a demand, or at least a desire, to see Android loaded onto a Google-branded phone as opposed to it being just another mobile platform? Are people already looking for a solid iPhone competitor?

Android Developers Are Mad

Of course, before you can have a successful gPhone or mobile platform, you have to have a happy developer community and lately, those guys have been getting antsy.

Public developers recently started an online petition on Android's Google Group because they're frustrated with the lack of an updated SDK - the last one was provided in March 2008. The complaints are that the current SDK is buggy and that certain features don't work.

The Android Developers' Petition

The first post that begins the petition states:

In order not to lose many highly encouraged developers, I think its time to release some news about the development process of the SDK. Maybe let us know why we have to live with these long cycles...In my personal opinion it is not the right choice to keep developers in the dark. We, the developers, are the absolute base of success to the whole Android platform. The presentation with GoogleIO was a good first step but for me it was nto [sic] enough.

Other developers chimed in to express their dissatisfaction, too. One developer claims he's only going to wait until the end of July, then he's switching to iPhone or Windows Mobile. Another says the developer community is falling apart, calling them "Google roadkill." A third notes that by the time a new SDK ships, many of the developers will have already released software on the iPhone platform, noting that it's "a platform with 20+ million users versus ZERO user install base for Android.  It's not a hard decision to make after all.  Hopefully someone wakes up sooner than later."

Google's Android Engineers Are Frustrated, Too

Among the 37 responses, a Google Engineer Jean-Baptiste Queru spoke up. Although he makes it clear that he's not the official spokesperson for Android, he does try to address some of the issues while also expressing some frustrations from the engineering team's side of the fence, too. In fact, reading between the lines a bit, it sounds like some of the engineers aren't happy with the decisions being made, either.

His post reads, in part (see the full version here):

I'm going to get into trouble for this post...

There is some truth however in saying that we (the Google Android team) are very much focusing on playing our part in getting an Android device on the shelves as soon as we possibly can, and that focus comes at the expense of other tasks, like getting an SDK out.

There've [sic] been quite a few long threads recently in various groups(this thread, along with one in android-developers and one in android-internals) around the issue of communication from Google. I'm sure that many of the people who participated in those threads get the feeling that their comments fell on deaf ears, whereas in fact that's not true. Quite a few members of the Google Android team read those groups (and we also read a number of community web sites), and (quite a bit by definition) we are the ones who do care about the community. Many of us have played roles in various developer communities in the past, very often on both sides of the fence, and in more ways that one we understand the situation that the developer community is in right now and we share the pain. So, while those posts aren't falling on deaf ears, they're typically falling in the wide-open ears of people whose hands are tied and whose mouths are gagged, and the frustration that such posts create in the Android team might in fact be larger than the relief that gets created in the community.

I'm afraid that none of all that I just wrote brings any closure in terms of communication. That's all because it's not my role to communicate the "big picture" answers that people would like to hear. The Google Android people who read the groups hear you, we understand your pain, we communicate it back up to our management, we're not happy about the situation either, we'd love more openness too. And, just like anybody else, we don't like to read implications that we're lazy, or that we're liars, or that we don't care about you, or any of the other nasty things that have been written or implied about us, because none of that it true.

The full post is much longer and is followed up by a second post where Queru says that he's not about to say anything concrete about the ship date for the next SDK.

Wow. What on earth is going on over there with Android?

With Cascada Mobile's platform called Breeze, anyone can take their idea from thought to app in about fifteen minutes. Well, maybe not anyone - the apps are built using HTML, so you would have to have some rudimentary web programming knowledge to use their platform. Still, you have to admit, that's a lot easier than using a professional development platform.

With Breeze, you can build, test, and distribute mobile J2ME apps that run on hundreds and handsets. And these are "real" apps, too - fully integrated mobile applications with their own icon, not just mobile widgets.

The "Breeze Simulator" lets the novice developers test their app for hundreds of different handsets - a usually daunting task in the world of mobile web programming where apps that work on one model don't work on another, even if they're similar in design or from the same manufacturer.

Check out this video that shows Breeze in action:
Cascada Mobile Breeze from Cascada Mobile on Vimeo.

In addition, Breeze developers will receive a line of code they can put on their web sites, blogs, or social network profiles that let their visitors download the app by entering their mobile number. Breeze takes care of the distribution via SMS, WAP Push, and direct download. To subsidize the cost of distribution, the apps are ad-enabled. However, developers wanting to go ad-free can pay for the use of Breeze in order to do so.

Should Programming Be Left To the Professionals?

So, now we have an application that lets everyone program web apps (Iceberg) and a platform for building mobile J2ME apps, what's next? If this trend is to continue, the next big move would be to let novice developers build their own iPhone applications, you would think. But the real question is do we actually want amateurs building apps for our mobile devices? Or would you rather that was left to professionals?

You can try some Breeze applications for yourself from here. (Ooh, mobile Twitter!)

The best is yet to come, though, as Yahoo! also said today that MyYahoo would open up to outside developer applications in the next few months. That's among the changes we've been waiting for since the company's big announcement in April about a shift towards whole scale personalization and data portability.

MyYahoo's market share in the startpage field is massive, Comscore estimated in January that the site sees nearly 50 million unique visitors each month. Google's iGoogle startpage is a distant second with just over 20 million. Facebook, however, is destroying both services - it's at an estimated 80 million active users worldwide and growing fast.

The Facebook platform hasn't shaped up as well as was hoped, however. While Facebook's platform faces growing problems with privacy, decreased developer interest and lower than expected user engagement - a MyYahoo platform would be hot. The placement of Facebook apps on the public facing profile pages instead of the user facing admin pages is a problem that MyYahoo wouldn't suffer from. Additionally, while Facebook users arguably use the service for communication more than for the other type of activities that so many Facebook apps facilitate - MyYahoo is already a full-service, multi-use portal for millions of people.

If the Facebook platform was a first run for the social networking app platform paradigm, and the LinkedIn platform is the most sought after place for developers seeking a professional userbase, then a MyYahoo! platform would be the sweet spot for mass audiences of mainstream users.

We hope that the general availability of the new MyYahoo will be one of the last key steps before the platform opens up. In response to our inquiry about the time frame for the platform, Yahoo! sent the following response:

"This strategy involves opening up Yahoo! in three phases throughout this year (2008) and next: the first is to open up internally, and you will see products like Yahoo! Search, My Yahoo!, and Yahoo! Mail open up and become more integrated, sharing content and data. The second phase is to open up the Yahoo! platform to third party developers, which will be happening throughout this year, starting already with SearchMonkey. The third phase will be to allow the Yahoo! experience to be accessed off the Yahoo! network and you can expect progress on that phase throughout this year and into 2009."