140Plus.com makes it easy to increase the number of terms that your website can rank for without cluttering your site with extra pages that might make your site bloated and hard to navigate.

Below is a step-by-step guide for using 140plus.com as a highly effective and easy to use tool for SEO and traffic building.

1) What do I write about?

The most common road block to getting started with 140Plus.com is deciding what to write about. The answer is simple: write about your keywords. Since you’ll be using 140Plus.com to write about your industry and niche, it will be a natural place to create content around a wide variety of keywords.

2) Identify keywords (be realistic)

As an example, let’s say you want to increase the amount of traffic coming to your site for searches related to the term “pagerank.” Let’s face it, unless you’re Google or Wikipedia, you’re not going to be taking the #1 search engine result for the term “pagerank” anytime soon. That’s okay, you can still get crafty and take a sizable chuck of traffic by thinking about the way people search.

Most experienced Google users understand that using general terms isn’t going to get the results they want. Instead, people typically search for keyword phrases, for example: “increase pagerank,”, “improve pagerank” or “how to improve pagerank.”

I might never get the #1 spot for the term “pagerank” alone, but there is actually a chance that I could rank for the keyword phrase “how to improve pagerank.” Granted, it may not have a high search volume, but if you can rank for a dozen or more of these kinds of keyword phrases related to the term “pagerank” you’ll end up with a significant amount of traffic.

3) Optimize your post around your keyword (Page Title, URL, H1)

The most important places to included keywords on any page of your site is in the page title, the URL and the H1 tag. This means that if you’re trying to rank for “how to improve pagerank” you need to make sure that phrase, in that order, is in all three places.

You also need to make sure that this phrase appears first. A common mistake is for a company to put it’s name before it’s keywords in page titles. For example “140Plus – How to Improve Pagerank.” Instead you would want “How to Improve Pagerank – 140Plus.”

Fortunately, 140plus.com handles this for you automatically. Once you’ve identified your keywords and ensured they’re part of the title of your post, 140plus.com ensures that the page title, the URL and the H1 tag are automatically optimized for search engines for you.

4) Publish your post

Finally, publish your post. 140Plus automatically arranges your page into a clean, search-engine friendly format, while automatically publishing to the web, to Twitter, and to Google. Depending on how frequently Google and other search engines scan your 140plus.com site, it could take a few days or longer for your pages to be indexed and show up in Google. A simple tip to get your 140plus.com pages into search engines faster is to publish more often. When Google notices that a site is getting updated daily, it will scan the site more regularly.

This is another place where 140Plus.com does some for the work for you, automatically posting to Twitter and posting your RSS feed to Google, leveraging the real-time social web to help your 140Plus.com posts get indexed faster.

140Plus.com gives your site more inbound links, which increases pagerank and improves organic search results to greatly increase traffic to your site. 140Plus makes it astonishingly easy to publish content to the new real-time social web. No set-up or configuration required. Just publish your content and share the link in seconds.

The world’s simplest Twitter-integrated, SEO-optimized pages.

5) Check the results

Try an experiment: If it’s been more than a few hours since your post has gone live, open up a new browser tab and do a quick Google search for “how to improve pagerank using 140plus.com.” Does your post show up on the front page? If so, do another search for “how to improve pagerank.” Does it show up again?

The two features are interlinked, in what appears to be an attempt to make Facebook “friend lists” be more like Google+ “circles”.

New Sharing Options

This change started to roll out a few weeks ago and now appears to be  site wide, applying to all accounts.  The status box used to update your status got a few new controls and widgets.

New facebook status box

First, on the left are two new options. The “who are you with” button lets you tag people in your status update. The second widget adds location to the status. Ok, fine.

But the biggest change is the drop down on the right, next to the “Post” button. This lets you set who the status update goes to (sort of). The normal option (the way Facebook has always worked) would be the “Friends” choice, meaning the status update is seen by your friends only. If you specify “Public” your status is visible to anyone, basically making Facebook more like Twitter, where if you want to, you can publish your status updates for anyone to see. Bringing us to another new feature (described further below) where people that are not your friends, can “subscribe” to your public updates, again, more or less the way Twitter works. I think by default, Facebook has made the new default “Public,” so if you don’t change that, your status updates will be visible to everyone.

In addition to the “Public” and “Friends” options, you can now specify that an update should only be sent to friends on a specific list, one of your old “friend lists” (if you ever used that feature) or one of the new “automatic” lists that Facebook calls “Smart Lists,” which are managed by Facebook automatically for you based on profile information – another case of Facebook telling us “trust us, we know what you want.” Time will tell whether people find these automatic lists useful and trustworthy.

Finally, there is another special list called “Restricted” which is for friends that aren’t really friends This is where you put friends when you don’t want them to see your status updates. Friends on this special “Restricted” list will only see your “Public” updates (but I assume they still have access to your photos etc.)

Managing Friend Lists

The other significant change is in managing friends and friend lists. There are new options when you visit someone’s profile:

The new “Friends” widget shown above makes it easier to manage the lists a given friend is on. Every time you visit their profile, you can check or change what lists they are on. For anyone that suffered through the old cumbersome way of managing lists this is much easier than before, but there is still plenty of room for improvement.

There’s also the new “Subscribed” button, which allows you to subscribe to a person’s “Public” updates, so that any status updates they mark as “Public” will show up on your page, even if they are not your friend. This is clearly a case where Facebook wants to be like Twitter.

Why This A Potential FAIL

These new changes are mostly being heralded around the net and in the media as a brilliant move by Facebook. Technically, for being obviously bolted-on, I have to admit they are not that terrible, in terms of the implementation. But here’s where I wonder if Facebook might be shooting themselves in the foot here, and actually helping Google+ (especially) and Twitter (to a lesser degree) which is probably not their intent.

Twitter is essentially still a mainstream failure, with only 8% of online Americans using it. It’s clear that one big reason is Twitter’s complexity and the inability of Twitter to explain what it does and how to use it to mainstream users. It’s too early to tell whether Google+ will reach deep into the mainstream the way Facebook has. One of the points I raised about Google+ is the complexity and that it is too confusing to mainstream users:

Google+ is too complicated and too geek-oriented. When people share something with Google+, they are going to constantly find themselves asking “who is that going to?”  Twitter suffers from being too confusing to people too. But if Twitter is too complicated, Google+ is going to be like a third-semester Calculus class for many people. Only a tiny fraction of Twitter users ever figure out how to effectively manage notifications or “who sees what” on Twitter. Google+ hasn’t made it any easier. If people are overwhelmed and confused with the Twitter options, their brains are going to explode with Google+.

With Facebook now essentially copying the Google+ “circles” model, they have now introduced the same kind of complexity into Facebook that hinders their competitors, effectively removing a major differentiator of Facebook: being easy to understand for mainstream users.

Facebook has just done Google a huge favor.

In essence, by force feeding this change to  its 750 million users, Facebook will be doing something Google themselves may have spent years doing: teaching them how Google+ works. Facebook users have no choice but to accept these new features, and struggle to learn them, which will make all Facebook users more comfortable with the “circles” model, and that level of complexity, ultimately making it that much less painful to switch to Google+.

Before this, if a Facebook user went to Google+, they had to figure out how “circles” and selective sharing work using Google+ itself.  Google+ would be their first exposure to this mode of operating. They would have no mental model for it and no prior experience with the ideas of it. Now, a Facebook user will have a direct analog from their Facebook experience – as soon as they hit Google+ they will already have an idea how ”circles” and selective sharing work, removing a huge switching barrier.

Likewise, with the new “Public” and “Subscribe” features, Facebook is teaching those 750 million users how Twitter works too, something Twitter themselves has been largely unable to do. However, I think in this case, Twitter is the loser and Facebook the winner (more on that in a separate post).

But Google+, on the other hand, just got handed an enormously valuable gift by Facebook.

Okay then. Well, here’s some quick takes after trying it out a bit.

1. The Good

This section is the hardest to fill in for me. We already have Facebook, Twitter, and LinkedIn (and others). It makes it hard to identify an obvious place for Google+. There’s the much acclaimed (and sometimes befuddling) “Circles” (to scope the distribution of updates). There’s also “Sparks” (search) “Huddles” (group chat), and “Hangouts”. Of these, “Hangouts” is perhaps the most unique. It is a way to announce your interest in video-chatting. That’s very much like something we did with Phweet back in 2008, so perhaps that’s why I like it.

One other good thing? It’s not Zuckerberg. Google’s famous “do no evil” comment has to be something they regret saying by now, but even so, I still feel that Google is a lesser evil, especially when it comes to handling my personal data. Facebook has a simply atrocious record in this regard. The less they have of my data, the better.

David Pogue gives a number of reasons to like Google+ in Google+ Improves on Facebook at the New York Times. I don’t disagree with his points, so I recommend you check out the article. He concludes with:

Until now, Facebook and Twitter have been the Dominant Duo of social networking. But Google’s less sprawling, more video-centric, better-controlled new service is already too good to ignore. Now it’s the Dominant Duo …+1.

2. The Bad

Google+ is too complicated and too geek-oriented. When people share something with Google+, they are going to constantly find themselves asking “who is that going to?”  Twitter suffers from being too confusing to people too. But if Twitter is too complicated, Google+ is going to be like a third-semester Calculus class for many people. Only a tiny fraction of Twitter users ever figure out how to effectively manage notifications or “who sees what” on Twitter. Google+ hasn’t made it any easier. If people are overwhelmed and confused with the Twitter options, their brains are going to explode with Google+.

All the cool features discussed above under “The Good” could be put under “The Bad” when it comes to complexity and learning curve. Features are a double-edged sword. Confusion about how it works keeps a lot of people off Twitter, or at leasts keeps them from using it to share and Google+ appears that it is going to suffer from being confusing too.

3. The Ugly

Google will tell you that the coolest part of Google+ is that it is (or will be) integrated with all other Google services and features. I argue that this is the biggest thing that hinders the chances for Google+ to succeed and not just become another Wave or Buzz that people try for a while and then dump.

This is the “Google Account” problem. It’s the assumption by Google that you have one Gmail account that you use for everything. After jumping through some non trivial hoops, Google now allows you to sign in to “multiple” accounts (up to three, if they’re the right kind of accounts) at once, but one of them is the “primary” account and trying to use one of the others is like dancing a tightrope carrying an anvil in one hand and a sharp knife in the other. You’re probably going to get bloody… or hurt someone. You log out of one, and everything you use on Google gets signed out too, even if it wasn’t using that account. This is why people end up running a different browser for every Google account and for every Google product. I could go on and on about this nightmare.

At the moment, you can’t use Google+ with anything but the “primary” Google logged in account.

This is all fine for people that have exactly one Gmail account and it’s all they use. However, with more and more companies converting to Google Apps and more and more people working from home etc. many people are using more than one Google Account at the same time and using different Google Accounts with different Google services. For example. I’m using Gmail with one (or more) accounts, using AdSense with a different account, using Google Docs with another account, Analytics with yet another account etc.

When it comes to Google+ this problem affects you even if you don’t use multiple Gmail accounts and multiple Google services. Requiring and binding by browser session to a “primary” Gmail account means Google+ is limited to people that use Google and Gmail in that way. This means Google has pre-selected which friends you can and cannot find on Google+. If I look at the groups of people I interact with, I have never segmented them into “those that use Gmail and those that don’t.” That segmentation is not meaningful to me. Google might care, but I sure don’t – it doesn’t help me organize my contacts.  As @sreejitkk2000 puts it:

One needs to get a Google Account to use Google+ and they have to like it, in that they have to log in with that account and use it for every Google service they will ever use. Quick: What percentage of your friends have a Google Account?  Which ones don’t? Is that a breakdown that is meaningful to you? Is that a group categorization you would normally use to divide up your friends? I don’t think so. And yet, that’s what Google has done for us.

For those of your friends without a Google account, do they know how to get one? Would they want one? Is Google+ so great that you would walk all your friends through setting up a Google Account and Google Profile?  And what about those friends that you’d like to have in a “circle”, but that simply can’t (or won’t) use Google the way Google wants?

I think this is a fundamental mis-judgement by Google. They see the tie-in to a Gmail account and other Google services as a good thing but I see it as a massive albatross.

Summary

Google+ is kind of a hybrid of Twitter and Facebook. It takes some features from Facebook, like rich content, updates longer than 140 characters, and comment threads.  And it takes some from Twitter, most notably asymetrical connections as in “Circles”. Then it brings in a few unique features like “Hangouts”.

It’s too early to tell what will become of Google+. For me, it’s a wait and see. I’m using it, but it has not grabbed me yet, mostly because nobody is there yet. The above “Google Account” problem already means I’m using an identity on Google+ that is not the identity that I want to use with it (because the identity I want to use is not compatible with it). And I see the self-selection discussed above coming into play and selecting for me the domain of people that I can connect with on Google+ (and more importantly, who I cannot connect with). This severely limits how I can use Google+ – until everyone I want to connect with converts to using Gmail as their primary login with a Google+ compatible “Google Account” and “Google Profile” it can’t replace Facebook, LinkedIn or Twitter for me. Instead, it’s simply one MORE place I have to check. I think this was a key factor in limiting and killing Buzz and Wave and it could easily also be the thing that kills Google+.

Some of this may be obvious “well duh” sort of stuff for others out there who may be a lot smarter than me. Hopefully it won’t all be that way.

As many of you may already know, over the last several years, I’ve worked on and otherwise participated in a number of side-projects, including:

• Phweet – a phone call in a URL
• Taglets – the story of tagged things
• Twitmart – Twitter Marketplace for social classifieds
• SuperTweet.net API – An Answer for Twitter OAuth-pacalypse
• TweetPress (140plus.com) – a free Twitter blog at http://YOU.140plus.com

Each of these can be considered a failure, depending on the metric or dimension one examines. Except for SuperTweet.net and TweetPress, all of them have since been shut down. Each of them have been a disappointment, to some degree or another, for me, personally. However, they also each provided various positive rewards, in addition to the sometimes painful lessons learned.

Metric 1: Popularity

Certainly, with the exception of SuperTweet.net, they are all failures in terms of popularity – they never gained any significant traction.

With the exception of Taglets.org, each of these services require a Twitter account – the only way to use the service is using your Twitter account. This was an intentional decision, where these services were supposed to be integrated with and tightly coupled to Twitter and your Twitter social graph. I don’t recommend such a strategy for anything real you may be doing. It’s fine for side projects like these, but it’s a bad decision for something you might hope to make into a business and you only need one reason for that, according to Pew Internet:

8% of online Americans use Twitter

So by limiting your target market to only those using Twitter, you are automatically excluding 92% of potential users. And that’s the number as of December, 2010 (according to Pew) at a time when Twitter was claiming over 150 million users.  It was even worse, much worse, back when we released Phweet in 2008 when Twitter had only a few million users.

There are other reasons to avoid putting too much emphasis on Twitter as a social network (which even Twitter says it is not), some of which I cover below, but obviously the 8% problem is all you really need to know.

Opening up your site to Facebook users will expose you to about ten times more users. That makes good business sense – however, in my case, I don’t particularly want to help Facebook lock-in more users and more sites, so I have elected to not implement Facebook Connect – a bad business decision, but one I accept on principle (and admittedly more weakly, on long-term business strategy grounds). I don’t encourage anyone to follow my lead on that, unless you also are doing so for something other than sound business reasons.

It’s too early to call regarding TweetPress one way or the other, but given that it is Twitter account-based, it suffers from the above problem of excluding the lion’s share of potential users that don’t have Twitter accounts, right off the bat. The service has not received any TechCrunch, GigaOm, or other such “juice” as Phweet and Twitmart did, and is only being promoted through the limited reach of my own followers and a few friends and others that have started using the service. As a result, growth has been slow, if not almost non-existant. Either way,  it serves my needs and it continues to be a wonderful platform for experimenting with different technologies, mashups, APIs etc. I have no plans to shut TweetPress down, regardless of whether it ever achieves wide adoption, but it’s always more fun when such services are embraced by a larger community.

Twitmart was being used by a few users, but it never even started toward the goal of helping users build a trading community with their Twitter Friends and Followers. Nobody used it that way. Instead, it became little more than a vehicle for spammers, so we shut it down.

As noted above, SuperTweet.net isn’t a disappointment in terms of adoption. It has been steadily growing since Twitter shut off Basic Authentication on the API. Unfortunately, most the users are parasites, contributing nothing in return (with notable exceptions, @ae6rt @TheDarkNighty and a handful of donations) – certainly it has not produced the kind of community of support I had hoped it would (naive, wishful-thinking on my part). Update: I have to take this statement back – there has been a significant upswing in community support for SuperTweet.net – thanks folks.

About the 8%

This brings me to some of the lessons learned about the 8% of people using Twitter. Let’s look at the Twitterverse in more detail.

With each of these services, we have learned something about the evolving Twitter user-base. And as Twitter approaches double-digit penetration into the mainstream, it may also provide some lessons about the Internet population at large.  We have seen this pattern before. The early adopters skew the personality of a service in the beginning. We saw it with Usenet, way back in the late eighties, and the pattern has repeated across many services over the years, right on up to Quora today.

In the beginning the services are populated with users that are smart, helpful, active etc. – there is a real community and it’s a regular utopian bliss. But then the real world steps in. And guess what, not everybody is so smart or sweet and nice. Some come from harder backgrounds where making a living might mean $1 a day. There are sleazeballs of every flavor with all kinds of motivations. If there is a way to exploit the service for their own personal gain, they find it, especially if it costs them almost nothing to do it (whether it’s the cost of a Usenet post, email, or a Twitter status update).

And Twitter is no different. As it’s gone from under a million users to hundreds of millions of users, the flotsam and jetsam of the population came along. As with email, the spammers and the like may be only a small fraction of the total user-base in number, but they can have a tremendous impact on the overall system. And there is a gigantic gray area of behaviors in the name of “social media marketing” and “SEO” going on on Twitter that sometimes cross the line. I read a business plan recently that literally referred to Social Media as the “advertising mecca of the future.” I suspect such is a common view among budding entrepreneurs.

One doesn’t have to look very far to find a huge array of consulting firms, PR agencies and others that will make all kinds of claims about their “secrets” and expertise in Social Media Marketing, often charging exorbitant fees – I shouldn’t even have to say it, but very few of them provide any value and most the time, engaging such a service will end up doing more harm than good by damaging your firm’s reputation.

Anyway, while I doubt the percentage of Twitter users that fit the above abuser category is very large, their presence is felt loud and clear. And they are the first to try to “game” any new system or service connected with Twitter, as well as Twitter itself of course. These are the folks that jumped on Twitmart and, I have to say, soured me on the project, and on Twitter as an ecosystem to a degree.

The Twitter “social graph” is a joke

In the bright young days of Twitter, a lot of us thought it might be a new kind of social network. And it was, for a while (and still is for a small percentage of Twitter users). But once Twitter started to aggressively market the service, attract celebrities, and celebrity stalkers, any chance of a meaningful social graph were put to bed. As Pew and other research has shown, there is nothing mutual in those relationships and no community or friendship aspect to them. Even Twitter finally acknowledged last year that they are a media company, not a social network.

Further, the Twitter Home Timeline, the stream of who you follow, has also become part of the joke. Most people that have a ‘reputation’ of any kind also follow a lot of people out of a sense of duty – they feel obligated to follow people so not to send a message that “we aren’t really friends,” even though they don’t really care much about that person’s tweets.  Their “following” list is so polluted with such connections, they really never follow it at all.  I had a high-profile Twitter guru tell me recently, in essence, that I’m not a serious or typical Twitter power-user because I don’t follow 500+ people. I brutally manage who I follow because I still actually read my timeline, basically every tweet in it. If I followed 500+ people, I may as well not be following any of them, because I’d never see most the tweets in that timeline/feed. But that’s exactly what a lot of people do on Twitter, making their home timeline, and thus their social graph, meaningless.

The implication is that any Twitter-related service that somehow relates to the social graph is working from bogus data and won’t be of any use to the largest segments of Twitter users, those for which the social graph is almost entirely meaningless.

Twitter is less real-time than you think

For news and events, the Twitter consciousness, the live timeline (fire hose), can provide wonderful insights as events happen. This is the broadcast platform role that Twitter serves very well.

In terms of real-time person-to-person conversation, however, Twitter is hit and miss, mostly miss. With Phweet, we discovered that most people don’t tune in to Twitter all that often or consistently. Here are some other issues that impair Twitter’s ability to serve as a communications platform:

1. Many connections aren’t mutual, so direct messaging fails
2. Twitter settings are too complicated, such that most people never figure out how to set up real-time notifications
3. Messages get lost in overflowing timelines
4. The 140 character limit kills deep conversation, or causes them to move elsewhere

Many services have emerged to try to solve the conversation problem on Twitter and they have all gone nowhere. In my opinion, Twitter as a person-to-person or small-group conversation platform is a non-starter.

Summary

In the end, Twitter is basically like a zillion RSS feeds overloaded with a messaging system (actually two messaging systems, @ messages that are semi-public, and direct messages that are email) wrapped around a search engine, and hooked in to SMS (at least in the US). Probably the original description of Twitter as a “microblogging service” is still the most accurate.

In short, people use Twitter to share stuff. Unlike a Facebook or LinkedIn style social network, tweets are generally shared with the world at large, not just ones mutual friendships. When, or if, people see what you share depends on a number of factors, not just whether they “follow” you or not. They might see your tweet as a search result, due to a retweet, as part of a Twitter list’s contents, or because the tweet was directed to them via @ messaging. And the fact that they follow you is no guarantee they will ever see your tweet, far from it.

All these things are important to keep in mind when conceiving applications or services that in some way work with Twitter.

So can you build a business, or even a viable service, around Twitter, exclusively? I don’t think so. Oneforty has done it (to whatever degree they are successful) and of course some Twitter clients have done alright (many have not done that well, especially once Twitter themselves became a competitor). Even though Twitter claims 200 million users, bear in mind that only 8% of online users use the service, and of those, only a tiny fraction make up the kind of users that can help build value in a community.

I essentially put 140plus.com together for my own needs but made it general enough for anybody to use. I’ve been trying to decide what to do with the 140plus.com domain for a while and finally decided to go ahead and deploy this rather modest idea on that domain.

Basically, I am always spinning several plates at the same time in the form of ideas and projects I’m working on. These often have a Twitter ID associated with them. 140plus.com lets me have a simple blog for each of these using just a Twitter ID without having to go through the setup of a full Blogger or WordPress blog.

Blogger and WordPress invite one to customize a blog – the urge to do so is often overwhelming – soon you can find yourself spending an enormous amount of time on the look and theme and widgets and other options on your blog. 140plus.com is the anti-Wordpress in that regard. There are NO VERY FEW customization options with 140plus.com. With one click to sign in using your Twitter account (using Twitter OAuth), you have  your blog setup at http://YOU.140plus.com and are ready to start writing posts.

140plus.com Admin Dashboard

140plus.com blogs can choose from a few basic themes with pre-set layouts (the default and most common theme is derived from the Kubrick design by Michael Heilemann – at some point, this might change). You can set your blog title, define some keywords, and add a few links off your blog page, and that’s basically it. All of these settings are optional and automatically default to reasonable values if not set, so never need to be touched, if you don’t want to.

Another way to look at 140plus.com is as a “Twit Longer” type service, where you can post items that don’t fit in 140 characters to Twitter.  When you post a new entry on your 140plus.com blog, the title of the entry is sent to Twitter, with a link to the full post.

Sample 140plus.com Tweet

Check it out and let me know what you think: http://140plus.com

We’ve enjoyed the experiment with Taglets.org this past year and a half, but it’s time to move on and shutdown the service. We haven’t driven the sort of usage we originally had hoped. Thanks for joining with us while we attempted to see if Taglets was useful at scale. We truly appreciate it.

The service will stop functioning Friday, October 22, 2010. For those of you using the service by way of the WordPress Taglets Feeder plugin, you may wish to uninstall the plugin to avoid posting to the Taglets service.

Respectfully,

Mark Petrovic
David Beckemeyer
Founders, Taglets.org

http://www.taglets.org

SuperTweet.net Access Credentials

For example, to send a tweet, use the http://api.supertweet.net/1/statuses/update.format such as:

curl -u user:password -d "status=playing with cURL and the SuperTweet.net API" http://api.supertweet.net/1/statuses/update.xml

The password shown in the example above is never your real Twitter password, but a separate password you set up just for use with the SuperTweet.net API – As with Twitter OAuth, you can revoke, change, or disable that password without any impact to your real Twitter password or Twitter account.  Also, you can deauthorize the SuperTweet.net API application itself on Twitter.com if you think it’s being bad, again, without affecting your real Twitter password or other Twitter applications.

Learn more: http://www.supertweet.net/

This has, of course, created quite a stir in the Twitter development community, with accusations that Twitter is “eating their young” and pushing third-party developers out of the market.

These recent events have really brought home for developers the risk that when building on top of someone else’s platform, they could decide to compete with you head-on. Of course we’ve seen this many times in the past, most notably with Microsoft, but also with Google, Cisco, and many others. Those seeking funding for Twitter mashups often struggle with this push-back from potential investors. Perhaps now, that will become even worse and it will be even harder to get funding for a Twitter-based product or service.

That’s not good news for Twitter. While their platform is popular, with a claimed 50,000 developers, it’s still relatively small, compared to Facebook with 500,000 or Apple’s 185,000 apps in the app store. Furthermore, both Facebook and Apple’s App Store have spawned lucrative breakouts like Zynga, Tapulous and PopCap, while Twitter’s ecosystem has yet to produce a similar hit in terms of revenue, to say nothing of profit. Even among the most popular Twitter apps with lots of users, there are plenty of companies burning cash, but few producing any.

So, is it time to drop the “twit” or “tweet” from your brand name and become less intricately linked and integrated with Twitter and the Twitter platform? Or is this a perfect time to show loyalty to Twitter in the hope that they reward you for that loyalty? To Twit, or not to Twit. That, is the question.  What do you think?

You can actually compare the difference side-by-side by comparing the performance on a native Java web server (Jetty) platform vs. the exact same code running on App Engine:

Java Jetty –> http://twitmart.org
Google App Engine –> http://twitmart.appspot.com

This shows pretty clearly that the performance issues aren’t Twitter (most of the time) nor are they in my Java webapp implementation. The same code is running on both platforms. Nor is it hardware – the machine running Twitmart.org is a very modest server that is hosting a large number of other sites.

The showstopper problem for Twitmart on App Engine is that Twitmart.org is a Twitter mashup using the the Twitter API. It turns out that Twitter API calls from App Engine fail frequently. I’m not sure why. It should not be due to throttling as the app uses authentication but on the other hand it could possibly be that Twitter is overwhelmed by API calls from the App Engine platform and therefore throttles the entire Google infrastructure. I think the most likely answer is just that App Engine has problems making API calls (HTTP requests) in general, because I’ve seen this same problem to other APIs besides Twitter from App Engine, such as the issues we had with the Taglets API.

Regardless, it’s bad for App Engine and Twitter Mashups. It means Google’s platform is not useful for Twitter mashups or any kind of mashups. That sucks and makes the platform much less useful in general.

Beyond that showstopper issue for Twitmart.org (and all Twitter mashups considering using Google App Engine), is the performance / consistency in general. For no clear reason, about 20% of requests just take a ridiculous amount of time on App Engine, even to do the simplest thing. E.g. a url that simply renders a template, that usually takes sub 100ms, will about 20% of the time, take 3-5 seconds or more. That’s simply too high of a “near-fail” rate for a “serious” application.

I hope that Google does address these issues and start to take serving “important” applications seriously. The idea of cloud computing in general, and Google’s “App Engine” approach specifically, is really cool. It’s very attractive to have someone else taking care of the servers, the network, patches, etc. However, there is a certain performance bar the service has to meet too, and unfortunately, Google isn’t making it yet, even for the price of “free”.

Working with my friend and colleague, and serious Java guru, Mark Petrovic we decided that a good “Goldilocks” candidate, that was neither too big, nor too trivial, was the experimental service Twitmart.org, a classifieds marketplace mashup, using Twitter APIs.

We decided that “porting” an existing web-based application rather than inventing a new one made more sense because this way we really didn’t have to think a lot about the design or functional specifications.  We already had them. We just had to think about how to implement to those specifications on a Java-based web application platform, and specifically, the Google AppEngine for Java platform.

With the Twitmart application, the first thing to address was that the site uses Restful-style urls (as opposed to a fully Restful architecture, for you Rest weenies). This introduces a number of issues. The AppEngine for Java platform implements the venerable, but now decade-old, Java Servlet API. Servlets don’t naturally support the clean urls that are essential in modern web applications.

Bad => /post.jsp?type=area&hash=forsale&postid=hKqo1
Good => /post/area/forsale/hKqo1

One way to go about this is to do it the old fashioned hard-coded way and manually parse urls and forward to servlets for the action. We considered doing so, as a last resort, but it would be painful and potentially a maintenance nightmare.

We had hoped to use Jersey but found that it was not quite there yet in terms of compatibility with Google AppAngine, although it looks like there is progress and we will see at least a subset of Jersey supported on AppEngine at some point. For this project, we decided that the outstanding issues with Jersey on AppEngine were more than we wanted to deal with. Since Twitmart is a web site rather than a web service API, perhaps Jersey isn’t quite the right platform anyway.

Regardless, we went with Restlet, which does support AppEngine in their latest unstable releases. Going with Restlet meant that we also needed a compatible template engine to replace JSP. We went with Freemarker which is supported as a Restlet extension.

There are many Java libraries for accessing Twitter APIs. We went with Twitter4J which appears to be the most AppEngine friendly (and it’s a nice, clean API too).

With all of these building blocks in place, the port of Twitmart to AppEngine for Java was mostly a matter of grinding it out. Here’s a bunch of stuff we learned in the process:

Restlet, Freemarker, and Twitter4J work on AppEngine

The Twitmart application doesn’t exercise every part of any of these tools, but the basics clearly work. That’s nice to know. We will use these again on future projects.

Servlets and Restlets can co-exist

A few of the operations that Twitmart does were better suited to traditional servlets. With some effort, we probably could have made them work as Restlets, but it was much quicker and easier to make them servlets, so that’s what we did. And it works. Servlet urls are directed to servlet classes in the usual way in the web.xml config while everything else is passed through the Restlet adapter/router class.

The AppEngine Text class overcomes the 500-character limit of Strings in the datastore

The datastore will only accept Strings of up to 500 characters. To store larger text, one must use blobs. AppEngine provides a Text class that makes this pretty easy – but it does make your application more AppEngine specific. A Text object cannot be viewed in the datastore viewer (admin panel) and they cannot be indexed or queried.

It’s not that hard to put arbitrary Java objects into the datastore

The Twitmart application accepts images uploaded by users to display with classified ad postings. Since AppEngine has no writeable file system, these “image files” must be placed into (and retrieved from) the datastore.  This turns out to be pretty easy, as long as the size of the data conforms to AppEngine’s limits – e.g. 1MB per datastore entity (see http://code.google.com/appengine/docs/java/datastore/overview.html)

Objects in the datastore have unexpecetd dependencies

I don’t know if  Java bytecode ends up in the datastore or not, but it kind of feels like it does. When we rearranged some classes, we discovered that datastore records using those classes failed with ClassNotFound errors. I guess we should have expected this, but it’s something to keep in mind – once something is written to the datastore, never move the class.

As I’ve noted before, the AppEngine datastore is not an RDBMS, despite providing a query capability that might make you think otherwise at first glance. The AppEngine datastore is based on the BigTable storage system. BigTable follows a very different philosophy than traditional RDBMS and, as a result, imposes many important restrictions. Knowing this from prior work on Taglets.org and other projects on AppEngine for Python, I knew about these restrictions and, in fact, the Twitmart application doesn’t make any queries at all; it always retrieves objects (records) by key and never via query.

Another lesson from our experience with the Python AppEngine was “be prepared to move off AppEngine” (for any number of reasons). This means trying to structure your application such that moving to a standard platform will not require a complete re-write. One place to start is to avoid any com.google.appengine.* imports. In the case of this Twitmart app, the only place we do that is for the special com.google.appengine.api.datastore.Text class (in order to store text strings larger than 500 characters). This is isolated to a couple of Java classes in this application, but in a larger app, or if such things found their way into too many places, it would be best to write abstraction libraries of some kind to make it easier to separate out AppEngine dependencies later.

The Twitmart app, as written, should run on any standard Java web application platform, such as Jetty, pretty easily. However, that said, while using JDO as the data management interface works, in theory, as a way to make your application work on AppEngine and on a standard platform, it might not turn out to be the best way, or the most common technique for managing data on standard web application platforms, in practice. In many cases, you would probably want to add an abstraction layer around your data models to make it easier to swap in different low-level APIs. I think in general, the AppEngine for Java platform makes this easier and more natural than the AppEngine for Python platform, where it takes a lot more effort to keep your app standard-platform ready.

The Twitmart port is not done. There are few functions left to implement and a few things still to fix in terms of better exception handling and related cleanup and enhancement, but the primary functionality is operational.  In practice, even with light usage, it is slower on AppEngine than it was on my own server, but I guess that’s the price you pay for “free” – so much for scaleable. I guess the theory is, on AppEngine it will show similarly poor performance for a dozen users as it does for 100,000 users.

Summary

If I develop more AppEngine apps, I’m going to use the Java AppEngine for sure over the Python AppEngine. Unless there is some really compelling reason (like a specific library I want to use) I don’t see me writing another App Engine app in Python ever again.

While I still don’t think Google AppEngine is ready for anything too important yet, if it ever will be, having a Java version is a big step in expanding the possible uses of Google’s cloud computing platform, IMHO, and I will almost certainly deploy more experimental applications like Twitmart using AppEngine for Java in the future.

References:

• Google App Engine for Java
• Restlet
• Restlet edition for Google App Engine
• Freemarker
• Freemarker extension for Restlet
• Twitter4J
• Twitmart.org

UPDATE October 16, 2009: The performance on App Engine was so poor that we had to move the Twitmart.org site off of App Engine and back to one of our own servers.  Details here.