As more wireless carriers adopt Google Android, many new consumers ask frequently how to do common tasks on their Android phone. This section is dedicated to offering Android Advice to new and experienced Android consumers. There will be more to come, however here are the top 6 frequently asked questions by new Android users:

1. What Android apps should I download?

There are many list all over the web, even many on our website (coming from Blackberry to Android see this list). We'll list a few must have best Android apps to get you started:

• Must Have: Astro File Manager, use this app to browse files on your SD card. Bar Code Scanner, use this app to scan the QR bard codes with all of our reviews to quick link you to apps in the Android Market!
• Task Management: TasKiller
• Battery/Power Management: Power Manager or Screebl
• Email: K9 Mail or Exchange by Touchdown
• Music: Pandora or Meridian Player
• Home Screen Customization: aHome or SlideScreen
• Productivity & Note-Taking: Astrid or Evernote

Keep visiting www.AndroidTapp.com for the best Android app recommendations.

2. How do I setup email accounts?

First gather your POP3 or IMAP protocol access information. Launch Email > type email address and password > Choose either POP3 or IMAP account > enter Incoming POP3 or IMAP protocol information > enter Outgoing information > choose whether email account is default.

3. How do I save battery power?

Try turning off Bluetooth, Wifi and GPS when not needed. Try to minimize update intervals of some apps such as Facebook and Twitter from the settings menu. There are apps to help manage battery power for you such as Power Manager.

4. How do I Customize my phone?

There are many home screen customization apps to give a completely different experience; popular apps include aHome, Open Home and SlideScreen.

5. How do I set Ringtones?

Either purchase them from sources like Amazon MP3 or download free with Mabilo Ringtones.

To place your own MP3 songs as ringtones go to the Android Market to download Rings Extended. Plug your phone to computer via USB cable. An icon will appear in the top left notification bar, slide the bar down (this is called the window shade). Tap USB connected > Mount > on your computer a new drive will appear > drag your own MP3 files to the drive > tap home button > Menu button > Settings > Sound & display > Phone ringtone > choose Rings Extended to browse your MP3 files on the phone.

6. How do I import my Contacts from SIM card?

From home screen tap Menu > Contacts > Menu > Import contacts > Import All (Import allows for single imports)

Have more questions? Feel free to ask in the comments below or Contact Us!

Google's two new announcements: integrating a Twitter-like service into Gmail and a goal of a real-time speech translation service shows what direction they're taking the company: Into the space between you and every other human being on the planet.

To be fair, these two developments are really far apart in their delivery dates. The Gmail status update could come as soon as tomorrow, whereas the the speech-to-text-to-speech translation system is still a ways out. You can definitely see just how much work Google needs to do by trying to read your Google Voice voicemail transcriptions. (Voice search works better on Android 2.1 because you're talking slower and enunciating.) But both these features point in the same direction many of the company's other products have been hinting at. Here's a list of Google's major products, in case you forgot, and which sector of communication they want to dominate.

Google Voice: This is a big one, and it'll be the most natural interface for Google to slot in the voice-translation into. If you're using it the way Google wants you to use it, you're already piping all your voice calls and SMS through Google's tubes. And refining speech to text gives them a good idea of your interests and what you're talking about, allowing them to better serve up the relevant ads to you during calls.

Gmail: Having access to at least one end of everyone's email conversations, outside of business emails, gives Google the ability to be a gateway for most of your written communications. But that's not enough for Google, which is why they developed...

Google Wave: It's email, message boards, chat rooms and collaboration software all in one, except every participant needs a Google account. This closes that "openness" loophole that email has, and forces everyone into Google's biosphere. So this, and Gmail, should make sure that every medium-length communique passes through Google's maw for analysis. But what about shorter and longer forms? Update: Thanks commenters, for reminding me that Google made Wave open, so people can create their own Wave servers to talk to each other with the Wave protocol. The point still remains, that if you were going to use a service, wouldn't you rather use the service from the company that created the protocol, for performance and feature reasons?

Google Docs: For longer documents.

Google Talk: For short blasts of instant messaging, video chats and some audio chatting.

Picasa and YouTube: Communication doesn't have to be all text-based, you putting your photos and videos online count too.

Android and Chrome OS: By getting you down at the operating system level, Google can theoretically know every kind of communication you perform. It knows who you talk to, how you do it and when you do it. It can even shape the how by delivering the experience themselves.

Everything else. There's Checkout, Finance, Maps, Reader, News and other apps, which fill in the other forms of communication or expression that aren't quite covered by the major products above. One major missing piece is social networking, where Google basically failed before with its Orkut service (except for Brazil), so this new Twitter/Gmail hybrid might be their next entrance into the space.

But why do they want these things? Why would Google want to be the middleman between you and the world? To sell you ads, of course. And don't think Google is going to stop at just helping you talk over the internet or over the phone, they're going to reach into meatspace as well. How? One step is making that speech-to-speech translation portable, so you can do a sort of near-field communication with someone else with the same device while at the same time being able to look them in the face. Then, blast you two with the appropriate ads on the billboard next to you.

Last week was a busy one for new APIs and in addition to the 7 new APIs we profiled earlier this week, here are 6 more new listings from our API directory. These include an API for tracking political and business relationships (an involuntary facebook of powerful Americans), a real-time website analytics service API, an API for getting the Mood of the Nation, a ringtone search API, a museum geolocation service, and an API for internet hosting and resellers. Below are more details on each of these new APIs:

LittleSis API: LittleSis is a free database tracking the key relationships of politicians, business leaders, lobbyists, financiers, and their affiliated institutions (also described as an involuntary facebook of powerful Americans, collaboratively edited). The LittleSis API exposes the raw data used on the LittleSis website. The data consists of basic information about people and organizations, and the relationships between them. It uses a RESTful interface and responses are formatted in XML and JSON.

Mixpanel API: Mixpanel is a web service that lets companies track how users engage with their websites in real-time. The Mixpanel API allows users to post and access the data that Mixpanel is analyzing. This is a RESTful API and responses are returned in JSON format.

Mood of the Nation API: Mood of the Nation API allows clients to retrieve the raw trending data associated with the free Mood of the Nation iPhone application. The application collects mood information (physical, mental, emotional) from users and trends over day, week, month.

Motime API: The Motime Open Access platform is an affiliate program based on the APIs of the Motime service which allows partners/affiliates to advertise Motime ringtone content on their own web or mobile sites and earn money for each referral given to Motime. The search API offers a REST protocol to allow developers to link their content with Motime's catalog of ringtones.

Muselius API: The Muselius API can be used to display information on up to 99 museums in an area on your own web site. The information about museums can be used to enrich your art related sites, hotels and tourist sites. Muselius is a global directory of museums. Our mission is to facilitate the information you need for visiting museums all over the world. Muselius is created and maintained with the help of many users who update and complete the data we have about each museum.

OpenSRS API: OpenSRS API is intended for resellers who offer domains and supporting services to their customers. Resellers can provide functionality to their customers by integrating data from the RESTful API functions (includes SSL support). Developers can use the API to run queries or automate tasks that would otherwise be performed manually using the Domain Name Control Panel.

By Senior Editor Kris Smith (@croncast)

Fring is an Israel based startup that has been offering its signature VoIP application for mobile devices is now available for Android phones in the Android Market. Fring is an app that allows users to connect via popular chast and VoIP tools like Skype and Google Talk.

It was first introduced a little over three years ago in beta for handsets that were running Symbian OS. Since that time it has spread across the other popular platforms to gain a foothold in the instant messaging space on mobiles. Not to mention cornering VoIP though API development with some of the most popular internet based messaging software.

Fring allows users to aggregate their connections across networks and easily send text, photos, files and now video. And yes, like anything else being released today, Fring will allow you to tweet. Happy?

The two most robust platforms for using Fring are on Symbian 9 or higher and Windows Mobile phones. The newest, Android, has a few features for now like text chat, mobile calling and personalization settings.

Using the application is fairly straight forward as you need to download and install for your phone, register and then wait for Fring to connect the together your networks and contacts. Once this step is done you can begin getting in touch with your posse(s) via your mobile.

I've had good luck with Fring when I needed to get in touch with a contact that I didn't have handy in my phone contacts and for Skype text based chats. Now that it is ready for the new kid, Android, I would suspect that more features like those for the iPhone will make their way into the app.

DISCLOSURE OF MATERIAL CONNECTION: http://cmp.ly/0

Android Market VoIP by Fring is a post from: TechStartups.com

By Senior Editor Kris Smith (@croncast)

The gadgets are flowing and they've got both publishers and subscribers in a tizzy over their options. Are they 3g? Can I put my content on it? Just wifi? What services do they deliver? Do I need to build an app? Am I locked in?

All great questions but not the one that is at the front of my mind. That question being where is the personal media hub for all of this content? Each type of media that we consume has a disparative quality of some sort that requires another gadget or format transcoder to allow usage which means, users need a hub.

I just want to know where that hub will be. I'm not sure if it belongs in the cloud or can even exist there due to limitations placed on that content by rights holders. Which is a legitimate reason not to use the cloud since publishers need to eat.

A couple reasons to use the cloud would be transfer speeds, remote accessibility and backups. With increased gadget connectivity it would make sense to do this. An example of a gadget that needs to be fed from an outside source like the cloud is the PSPgo. It relies on connectivity to fetch games, video and browse the web.

The games on PSPgo arrive from a Sony controlled hub behind a firewall. If the cloud is too limiting due to rights management the other other solution would be to offer a private hub. Another gadget, but one that resides in the dwelling of an individual. Using the Sony model for control and privacy a device like this could be the next evolution of an inclusive hub. It seems to me to be the missing link.

Media management across multiples platforms and for varying devices would require some version of a standard protocol. The protocol probably already exists and could be as simple as HTTP with SSL. The device itself a web server that connects to cars, phones, tablets, computers, televisions, etc.

A device like this could also create new opportunities for rights holders to create new models for selling content. I'm thinking in the range of micropayments for ongoing usage or payments for amount of time used. An example would be a movie that instead of a 24 hour limit would allow the consumer to view it 2 times on any device before being crippled or offered for purchase for an additional few dollars.

My personal interest would be to have a media hub that I had control over and could add content to from any device like the PSPgo, Kindle, iPhone or computer. The ability for these devices to speak a common language for file storage and retrieval would increase consumption and sales as all of a users purchases become portable, even if lockedin to a device.

There are plenty of media hubs that exist today for personal use that can be net connected, but this device would find its niche in storing and delivering content without limitation.

DISCLOSURE OF MATERIAL CONNECTION: http://cmp.ly/0

Where is the personal media hub for ebooks, music and videos? is a post from: TechStartups.com

I was asked to review a scenario for a friend this morning that deals with competition for mind share in an ongoing roe between disparate entities. Ahem, feuding like Hatfields and McCoys as Waylon Jennings would say, and they're doing it primarily online.

Most of us choose to go about our business online without causing confrontation. You might not choose to be involved in a situation like this.

However, if you are put in this position tactics for a remedy are below:

1. Make sure all of your sites where dynamic content is being created on have RSS feeds
2. Make sure the sites are being indexed by Google . . . and recently cached by going to Google and typing in site:blogdomain.com blogdomain.com being the site URL
3. Most of the sites below (I was furnished with list including Topix and Blog Catalog to mention a couple) require registration and some code editing to claim the sites. Register with them and follow their protocol for submission into their directories for partner programs and additional synidcation
4. Create a press release(s) that contains links, not just copy, but links to the RSS feeds from clients site(s). Example, For more information on this ongoing issue subscribe to: http://www.blogdomain.com/rssfeed. The popular outlets have wide syndication
5. Use this tool from Google http://www.google.com/sktool/# and enter your sites and the sites of the competitor into it. Disregard the pricing listed on the page for AdWords and focus on the keywords. Compare the the keywords of your competitor with those of your sites and adjust accordingly in all digital communications. Organic search is king.
6. Next use this too from Google https://adwords.google.com/select/KeywordToolExternal once your keywords are set to see how you are doing
7. Depending on the blog or site platform you should have the abilility to create keyword RSS feeds. Do this. Robots like structured data and favor feeds. Most, if not all, Google real-time alerts come from RSS feed links back to the source site.
8. Commenting on local (this is a regional battle for mind share) blogs with links to client site(s) and feeds is another way to increase chances of indexing and more favorable search results

If I were fighting this battle or one like it these are exact steps that I would take. So dear reader, if we ever lock horns, we may duel to a draw since you have my playbook.

How to Win Mind Share in Online Battles is a post from: TechStartups.com

Database normalization is a technique for designing relational database schemas that ensures that the data is optimal for ad-hoc querying and that modifications such as deletion or insertion of data does not lead to data inconsistency. Database denormalization is the process of optimizing your database for reads by creating redundant data. A consequence of denormalization is that insertions or deletions could cause data inconsistency if not uniformly applied to all redundant copies of the data within the database.

Why Denormalize Your Database?

Today, lots of Web applications have "social" features. A consequence of this is that whenever I look at content or a user in that service, there is always additional content from other users that also needs to be pulled in to page. When you visit the typical profile on a social network like Facebook or MySpace, data for all the people that are friends with that user needs to be pulled in. Or when you visit a shared bookmark on del.icio.us you need data for all the users who have tagged and bookmarked that URL as well. Performing a query across the entire user base for "all the users who are friends with Robert Scoble" or "all the users who have bookmarked this blog link" is expensive even with caching. It is orders of magnitude faster to return the data if it is precalculated and all written to the same place.

This is optimizes your reads at the cost of incurring more writes to the system. It also means that you'll end up with redundant data because there will be multiple copies of some amount of user data as we try to ensure the locality of data.

A good example of a Web application deciding to make this trade off is the recent post on the Digg Blog entitled Looking to the Future with Cassandra which contains the following excerpt

The Problem

In both models, we're computing the intersection of two sets:

1. Users who dugg an item.
2. Users that have befriended the digger.

The Relational Model

The schema for this information in MySQL is:

CREATE TABLE `Diggs` ( `id` INT(11), `itemid` INT(11), `userid` INT(11),
`digdate` DATETIME, PRIMARY KEY (`id`), KEY `user` (`userid`), KEY `item` (`itemid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;   CREATE TABLE `Friends` ( `id` INT(10)
AUTO_INCREMENT, `userid` INT(10), `username` VARCHAR(15), `friendid` INT(10), `friendname`
VARCHAR(15), `mutual` TINYINT(1), `date_created` DATETIME, PRIMARY KEY (`id`), UNIQUE
KEY `Friend_unique` (`userid`,`friendid`), KEY `Friend_friend` (`friendid`) ) ENGINE=InnoDB
DEFAULT CHARSET=utf8;

The Friends table contains many million rows, while Diggs holds hundreds of millions. Computing the intersection with a JOIN is much too slow in MySQL, so we have to do it in PHP. The steps are:

1. Query Friends for all my friends. With a cold cache, this takes around 1.5 seconds to complete.
2. Query Diggs for any diggs of a specific item by a user in the set of friend user IDs. This query is enormous, and looks something like:

   SELECT
   `digdate`, `id` FROM `Diggs` WHERE `userid` IN (59, 9006, 15989, 16045, 29183, 30220,
   62511, 75212, 79006) AND itemid = 13084479 ORDER BY `digdate` DESC, `id` DESC LIMIT
   4;

   The real query is actually much worse than this, since the IN clause contains every friend of the user, and this can balloon to hundreds of user IDs. A full query can actually clock in at 1.5kb, which is many times larger than the actual data we want. With a cold cache, this query can take 14 seconds to execute.

Of course, both queries are cached, but due to the user-specific nature of this data, it doesn't help much.

The solution the Digg development team went with was to denormalize the data. They also went an additional step and decided that since the data was no longer being kept in a relational manner there was no point in using a traditional relational database (i.e. MySQL) and instead they migrated to a non-RDBMS technology to solve this problem.

How Denormalization Changes Your Application

There are a number of things to keep in mind once you choose to denormalize your data including

1. Denormalization means data redundancy which translates to significantly increased storage costs. The fully denormalized data set from the Digg exampled ended up being 3 terabytes of information. It is typical for developers to underestimate the data bloat that occurs once data is denormalized.

2. Fixing data inconsistency is now the job of the application. Let's say each user has a list of the user names of all of their friends. What happens when one of these users changes their user name? In a normalized database that is a simple UPDATE query to change a single piece of data and then it will be current everywhere it is shown on the site. In a denormalized database, there now has to be a mechanism for fixing up this name in all of the dozens, hundreds or thousands of places it appears. Most services that create denormalized databases have "fixup" jobs that are constantly running on the database to fix such inconsistencies.

The No-SQL Movement vs. Abusing Relational Databases for Fun & Profit

If you're a web developer interested in building large scale applications, it doesn't take long in reading the various best practices on getting Web applications to scale such as practicing database sharding or eschewing transactions before it begins to sound like all the advice you are getting is about ignoring or abusing the key features that define a modern relational database system. Taken to its logical extreme all you really need is a key<->value or tuple store that supports some level of query functionality and has decent persistence semantics. Thus the NoSQL movement was borne.

The No-SQL movement is a used to describe the increasing usage of non-relational databases among Web developers. This approach has initially pioneered by large scale Web companies like Facebook (Cassandra), Amazon (Dynamo) & Google (BigTable) but now is finding its way down to smaller sites like Digg. Unlike relational databases, there is a yet to be a solid technical definition of what it means for a product to be a "NoSQL" database aside from the fact that it isn't a relational database. Commonalities include lack of fixed schemas {TODO}. Below is a list of some of the more popular NoSQL databases that you can try today along with a brief description of their key qualities

1. CouchDB: A document-oriented database where documents can be thought of as JSON/JavaScript objects. Creation, retrieval, update and deletion (CRUD) operations are performed via a RESTful API and support ACID properties. Rich querying is handled by creating Javascript functions called "Views" which can operate on the documents in the database via Map/Reduce style queries. Usage: Although popular among the geek set most users seem to be dabblers as opposed to large scale web companies.

2. Cassandra: A key-value store where each key-value pair comes with a timestamp and can be grouped together into a column family (i.e. a table). There is also a notion of super columns which are columns that contain whose values are a list of other key-value pairs. Cassandra is optimized to be always writable and uses eventual consistency to deal with the conflicts that inevitably occur when a distributed system aims to be always writable yet node failure is a fact of life. Querying is available via the Cassandra Thrift API and supports fairly basic data retrieval operations based on key values and column names. Usage: Originally developed and still used at Facebook today. Digg and Rackspace are the most recent big name adopters.

3. Voldemort: Very similar to Cassandra which is unsurprising since they are both inspired by Amazon's Dynamo. Voldemort is a key-value store where each key value pair comes with a timestamp and eventual consistency is used to address write anomalies. Values can contain a list of further key value pairs. Data access involves creation, retrieval and deletion of serialized objects whose format can be one of JSON, strings, binary BLOBs, serialized Java objects and Google Protocol Buffers. Rich querying is non-existent, simple get and put operations are all that exist. Usage: Originally developed and still used at LinkedIn.

There are a number of other interesting NoSQL databases such as HBase, MongoDB and Dynomite but the three above seem to be the most mature from my initial analysis. In general, most of them seem to be a clone of BigTable, Dynamo or some amalgam of ideas from both papers. The most original so far has been CouchDB.

An alternative to betting on a speculative database technologies at varying levels of maturity is to misuse an existing mature relational database product. As mentioned earlier, many large scale sites use relational databases but eschew relational features such as transactions and joins to achieve scalability. Some developers have even taken that practice to an extreme and built schema-less data models on top of traditional relational database. A great example of this How FriendFeed uses MySQL to store schema-less data which is a blog post excerpted below

Lots of projects exist designed to tackle the problem storing data with flexible schemas and building new indexes on the fly (e.g., CouchDB). However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs (see this somewhat outdated article on CouchDB, for example). MySQL works. It doesn't corrupt data. Replication works. We understand its limitations already. We like MySQL for storage, just not RDBMS usage patterns.

After some deliberation, we decided to implement a "schema-less" storage system on top of MySQL rather than use a completely new storage system.

Our datastore stores schema-less bags of properties (e.g., JSON objects or Python dictionaries). The only required property of stored entities is id, a 16-byte UUID. The rest of the entity is opaque as far as the datastore is concerned. We can change the "schema" simply by storing new properties.

In MySQL, our entities are stored in a table that looks like this:

CREATE TABLE entities ( added_id INT NOT NULL AUTO_INCREMENT PRIMARY
KEY, id BINARY(16) NOT NULL, updated TIMESTAMP NOT NULL, body MEDIUMBLOB, UNIQUE KEY
(id), KEY (updated) ) ENGINE=InnoDB; 

The added_id column is present because InnoDB stores data rows physically in primary key order. The AUTO_INCREMENT primary key ensures new entities are written sequentially on disk after old entities, which helps for both read and write locality (new entities tend to be read more frequently than old entities since FriendFeed pages are ordered reverse-chronologically). Entity bodies are stored as zlib-compressed, pickled Python dictionaries.

Now that the FriendFeed team works at Facebook I suspect they'll end up deciding that a NoSQL database that has solved a good story around replication and fault tolerance is more amenable to solving the problem of building a schema-less database than storing key<->value pairs in a SQL database where the value is a serialized Python object.

As a Web developer it's always a good idea to know what the current practices are in the industry even if they seem a bit too crazy to adoptyet.

Further Reading

• How FriendFeed Uses MySQL to Store Schema-less Data by Bret Taylor
• Looking to the future with Cassandra Digg Blog

Now Playing: Jay-Z - Run This Town (feat. Rihanna & Kanye West)

Shared by Schlomo
Word. Chesspark/Collecta has known this for a long time.

Web surfers nowadays use many browsers on different machines, even on small devices like smartphones. They obviously need a way to gather together all these sparse data (like bookmarks, passwords, history, etc.) and make them available from any browser at any time.

Two of the largest internet players today provide two different approaches, both at the same experimental state:

• Mozilla with Weave, a product from its labs, providing a Firefox extension, a opensource server implementation, and a documented protocol
• Google will offer a Chrome feature, Google Talk server, Google account, and maybe a documented protocol, since the code is opensource

It is possible to provide browser data sync client as a cross-browser extension or plugin, a server component which would rely on an existing XMPP server and account of your choice, and a protocol which could well be Bookmarks, Message Archiving, or Persistent Storage of Public and Private Data via PubSub.

This shows the ongoing effort of Google to use XMPP: Talk and Jingle, GMail notifications, Wave, and now data sync.

With Google and Apple using XMPP for its notifications service, XMPP shows itself as a strong infrastructure for a wide array of applications beyond the simple chat.

Pushbutton is a name for what I believe will be an upgrade for the web, where any site or application can deliver realtime messages to a web-scale audience, using free and open technologies at low cost and without relying on any single company like Twitter or Facebook. The pieces of this platform have just come together to enable a whole set of new features and applications that would have been nearly impossible for an average web developer to build in the past.

Background

The most interesting area of new development on the web is the innovation happening around realtime messaging, the ability to deliver updates to a website or application in one or two seconds. While various systems like Yahoo News Alerts or feed readers like Google Reader have offered some simple ways of delivering fairly fast notifications, they are still built on an infrastructure that relies upon requesting a web page repeatedly. These systems do the equivalent of hitting the "reload" button in your web browser over and over.

While those systems have been using these inefficient methods to deliver updates, newer platforms like Twitter, Facebook and FriendFeed have focused on building the infrastructure for efficient large-scale delivery of updates using their own proprietary networks. A lot of attention has been paid to Twitter's 140-character limit, or Facebook's News Feed, but the compelling technology that enables the user experience on these platforms is the immediacy with which updates are delivered. Earlier systems like instant messaging or chat allowed realtime messaging on a one-to-one or small group basis, but it's been harder to deliver those realtime messages to anyone in the world who wanted to receive them unless you had a lot of money, expertise and infrastructure.

Another barrier is that, while there are many different programs and clients that let you connect to Twitter or Facebook with your own applications, there haven't been any free and open options for delivering realtime messages to a large audience if you couldn't, or didn't want to, rely on those companies.

But recently, a few key pieces have fallen into place that make it inexpensive and relatively easy to add realtime messaging as an incremental upgrade to existing websites and web applications. This set of related technologies, which I'm calling the Pushbutton platform, will yield a broad new set of capabilities for users, publishers and developers on the web. Best of all, Pushbutton technologies are free, open and decentralized, meaning that the arrival of realtime on the web will not be owned or controlled by any single company.

Defining Pushbutton

The concept and potential of Pushbutton is a lot like Ajax it's not a single technology or invention, it's a whole family of technologies, some of which have been in development or deployment for nearly a decade, that together enable this new realtime web. Pushbutton's foundation is built on these systems:

• Atom and RSS: The most common feed formats, for syndication on the web
• PubSubHubBub and RSSCloud: Powerful new "hubs" for distributing messages
• Web Hooks: Simple web services for receiving messages, rather than sending them

Pushbutton systems rely on the web's fundamental HTTP protocol for communication between these component parts. The architecture of Pushbutton message delivery is also simple to understand. Before Pushbutton, in today's systems, when you create a message (a blog post, tweet or other update) that's published in your RSS or Atom feed, every application or site that wants updates from you has to repeatedly request your feed to know when it's updated. You can optionally notify ("ping") some applications to tell them it's time to come collect your new updates, but this is time-consuming and resource-intensive on both sides, especially if you want to notify a lot of people.

In the best case, the system we have now is analogous to a person coming by your house and saying "Hey, there's a new edition of your favorite newspaper today. You should go get it." And then you have to go to the newspaper's printing plant to pick it up. In a Pushbutton web, that person is delivering each story to your house the moment it's complete.

That's because Pushbutton-enabled applications will improve upon the current state of affairs by proactively delivering not just the notification that there's a new message, but the content of the message itself. And instead of requiring all those applications to come to your site to read the update, it uses a hub server in the cloud to pass along the message directly to all the receivers that are interested in it.

1. You, the Sender, create a message to be delivered via RSS or Atom
2. Your application gives the messsage to one or more PubSubHubBub or RSSCloud hubs, which reside in the Cloud
3. The PubSubHubBub or RSSCloud hubs deliver the message to any Receivers, the applications or sites that have requested updates from you

In this way, each time you create a new message, a large number of Receivers can consume that message in near realtime (usually less than a second) without a lot of complexity. This kind of messaging has been possible with custom-built or more obscure technologies in the past, but the Pushbutton ecosystem is a breakthrough for a few reasons:

• Sending messages just requires a minor change to an RSS or Atom feed, and a simple, well-defined update notification, instead of major changes to the application where you create your messages.
• Receiving messages is also very simple, only requiring a developer to handle incoming notifications of updates.
• Most of the system's complexity is handled in the hub servers, which are well-documented, implementable in a variety of programming languages, and built around open code that will likely attract a large developer community.
• Most of the scaling effort and expense happens at the hub level, and all current hubs are designed to run on inexpensive cloud systems like Google App Engine or Amazon's EC2.
• The software for Sending, Receiving or running a hub is free, open source and available on almost any platform.
• Messages sent on Pushbutton platforms are delivered via HTTP, which is familiar to any web developer and runs well on any hosting environment. All requests between the different layers of a Pushbutton system can be made as simple REST calls.
• Pushbutton technologies can be adopted incrementally, so that features can be added piecemeal on either the sender or receiver side, without requiring a wholesale upgrade to infrastructure or application architecture.

Who's Behind Pushbutton?

Pushbutton technologies have been created and advocated by some of the most credible and experienced developers of social web technologies. Here's a brief overview of the impressive pedigree of these components:

• PubSubHubBub was co-created by Brad Fitzpatrick and Brett Slatkin of Google. Brad was founder of LiveJournal, and created or co-created fundamental social web technologies like Memcached, OpenID and more.
• XML-RPC update pings, RSS and the RSS Cloud ideas were pioneered by Dave Winer, who has been actively developing open implementations of each of these technologies.
• Web Hooks have been evangelized by Jeff Lindsay, and have been deployed by a variety of different companies and platforms which all independently developed the technique.

In addition, Google has supported Brad and Brett's development of PubSubHubBub, and enabled it on the Google FeedBurner service. A number of smaller companies are deploying large parts of this infrastructure as well. In short, some of the best reputations in developing open web systems have made Pushbutton possible, from the biggest tech companies to the most steadfastly independent developers on the web.

Related Ideas and Prior Art

There are a lot of existing technologies that have influenced the creation and evolution of Pushbutton technologies; If you're familiar with any of these systems, you're probably already ahead of the curve in understanding part of what Pushbutton is trying to enable.

• Twitter Firehose, FriendFeed SUP, TypePad Update Stream: These realtime delivery systems offer up the content of their respective platforms as an unending stream that developers can consume and use in their applications. At the present time, they all have varying licenses and degrees of openness, and slightly different formats for delivering updates, but have proven the utility of the "sending" part of Pushbutton's realtime functionality.
• XMPP (Jabber), NNTP (Usenet), IRC: These older internet protocols all delivered various degrees of realtime messaging and distributed messaging capabilities, and can form a very useful base of experience for Pushbutton developers to learn from. In some cases, fundamental architectural choices about security, authentication or architecture were made when the Internet was less populated and less complex, making them inappropriate for today's applications. In all cases, these protocols are less-known by most contemporary web developers, and thus lack familiar toolkits and development resources, which make them quite challenging to deploy in common, inexpensive environments.
• TrackBack and Pingback: These systems for delivering updates between blogging systems were very effective in enabling rich distributed conversations in the early days of the blogosphere. These have declined in usefulness due to poor or missing implementations of authentication, which led to spam problems, and a general lack of understanding of their utility by a lot of newer bloggers. Pushbutton may offer an opportunity to restore some of the value of the idea behind these systems.
• Reverse HTTP may end up being a useful component of some Pushbutton deployments, as a complement or companion to Comet and related techniques.

What should we worry about?

• A format war? If you're familiar with the communities around technologies like feeds, you may know they have a deserved reputation for being contentious and even breaking into heated disputes over arcane details. I don't think that's likely to happen this time, because there are only one or two viable formats for each layer of the platform, and the creators of each part have shown some consistent good-faith efforts to promote interoperability where possible and peaceful coexistence where necessary. In the Ajax community, for example, the "X" in Ajax often stands for JSON instead of XML, but this hasn't hindered its broad adoption at all. I'm also willing to personally commit to try to prevent any kind of interpersonal conflict that would inhibit the adoption of Pushbutton technologies. Worry? No.
• Scaling issues? There will inevitably be some learning to do about how to scale the resource-intensive hub layer of a Pushbutton system. But because the hubs live on cloud systems that make enormous amounts of computing resources easily available, because the coders creating the reference implementations of the hub software have great experience making web-scale systems, and because it's relatively simple to introduce new hubs as needed, this will likely not be a gating factor for adoption of Pushbutton. Worry? No.
• Intellectual Property Concerns? I'm not a lawyer, and this isn't legal advice. But there has already been a great deal of interest in these systems, and it's likely that any bad actors who were interested in throwing their patent lawyers at this sort of system would probably already be suing people left and right. And the main players who are already involved have shown a consistent desire to make truly open systems that don't have IP encumbrances. Put simply, I think anybody smart enough to invent these kinds of technologies is smart enough to not want to look like jerks by suing somebody for using them. Worry? Probably not.
• Competition from centralized systems? Pushbutton technologies are not just free and open, they're decentralized, which is a serious threat to the "lobster trap" model of social software. We can expect serious competition from the centralized networks that are currently building these sorts of systems. If a threat arises to Pushbutton's adoption, this is the most likely source. Worry? Definitely.
• Bad user experience? One of the worst things we can do in making use of new technologies is to ignore the social, personal or even political implications of their use. Messages that are immediately delivered can't, by their nature, be erased from all the places they appear. The idea of permanently archiving these types of messages is unfamiliar to a lot of less technically-savvy users. And whenever we see something shiny and new, we have the temptation to use technology for technology's sake, whether or not we're solving a real problem or providing a real value. If Pushbutton gets a bad rap early on despite having tremendous potential, this will be why. Worry? Hell, yes.

Conclusion

I have tremendous excitement about the new realtime era of web applications. While I'm fundamentally an optimistic person, I have great skepticism when it comes to mindless hype about new technologies, so it's with a bit of reluctance that I indulge in some hype myself. But I think the Pushbutton web has the opportunity to give individuals and organizations with distinct and passionate voices the ability to be even more immediate and expressive on the web, and after ten years of publishing on the web, that's the part I love the most.

I have no doubt that some skeptics will say "Pushbutton is just PubSubHubBub by another name", just like they said "Ajax is XMLHttpRequest by another name", and if that's what the super-geeky guys want to believe, I'm fine with that. And I'm sure there will still be some significant technical details to resolve. But I think by giving the overall concept an approachable, understandable name and (hopefully!) an explanation that can be understood by anyone with an interest, it can catalyze interest in a whole new area of innovation on the web. And to be honest, when I see folks like Brad Fitzpatrick and Dave Winer hacking on the same set of problems, I can't help but think something interesting will come of it.

Over the next few days, I'll be outlining some of the opportunties around Pushbutton, espousing more of the philosophy that has the potential to imbue Pushbutton with a bit more meaning than most new web tech, and providing some simple explanations of how you can get started both learning about and taking advantage of these technologies. Most of all, I hope you'll offer your pointed criticisms, thoughtful critiques, detailed corrections and even better ideas. I'll be following the conversation here in the comments, across the blogosphere, and on Twitter using the tag #pshb.

Google makes its money mostly from targeted advertising on product searches and other narrow, directed searches. The advertising on news-related searches is not nearly as valuable. Google could remove all newspapers and journalism content from its Web search catalog tomorrow and lose very little of its revenue. The links to news it provides are valuable to its users but not terribly valuable to its advertisers.

Most galling was that The Huffington Post's use of an Associated Press version of SI's report was initially tops on Google, which meant that it, and not SI.com, tended to be the place readers clicking through to get the gist of the breaking scandal would land.... Why did The Huffington Post come up ahead of SI.com? Because, even Google insiders concede, Huffington is effective at implementing search optimization techniques, which means that its manipulation of keywords, search terms, and the dynamics of Web protocol give it an advantage over others scrambling to be the place readers are sent by search engines. What angered the people at Sports Illustrated and Time Inc. is that Google, acting as traffic conductor, seemed unmoved by their grievance over what had happened to their ownership of the story. An SI editor quoted to me Time Inc's editor-in-chief, John Huey, noting crisply that, "talking to Google is like trying to talk to a television."