Yahoo! has thrown their hat in the ring and joined the hottest new trend on the Web, shipping your very own "Connect" technology. What is a "Connect" technology? David Recordon does a good job of summarizing the common characteristics of this new category of technology offerings in his post Anatomy of "Connect" where he wrote

a straw man definition of a "Connect" application:

1. Profile: Everything having to do with identity, account management and profile information ranging from sign in to sign out on the site I'm connecting with.
2. Relationships: Think social graph. Answers the question of who do I know on the site I've connected with and how I can invite others.
3. Content: Stuff. All of my posts, photos, bookmarks, video, links, etc that I've created on the site I've connected with.
4. Activity: Poked, bought, shared, posted, watched, loved, etc. All of the actions that things like the Activity Streams project are starting to take on.

In my mind, the Goals of all of these "Connect" applications are focused on helping people discover new content, people they already know as well as new people with similar interests.

Facebook launched this trend with their announcement of Facebook Connect which offered an alternative to OpenID by offering a smoother user experience and the opportunity for sites to also leverage their news feed as a viral distribution mechanism. According to the Yahoo! Developer blog there is now a similar offering from Yahoo! announced in their post Extend Your Publishing Reach with JS-Kit + Yahoo! Updates which states

Here's how it works: Integration with the Social Directory API allows JS-Kit to display a user’s Yahoo! nickname and avatar picture on the site. Integration with the Updates API allows JS-Kit to publish an item to the Yahoo! Updates feed when a user adds a comment to a web site powered by JS-Kit. At all times, your users remain in control of their data by leveraging OAuth to broker data access between Yahoo! and JS-Kit.

Yahoo! Updates allow publishers (and publishing partners like JS-Kit), to syndicate user-generated actions (ratings, reviews, comments, favorites, and uploads) to Yahoo!'s massive global distribution network. In the coming months, as Updates are implemented across Yahoo!, publishers will enjoy referral traffic back to their sites from across the Yahoo! Network (more than 500M+ monthly unique visitors).

The more of these "Connect" offerings that are announced the more they seem like introducing a new problem instead of creating a solution. Back in the day, it was easy to argue that having a button on your site is more palatable than the OpenID login box prompting users to enter some obscure URL. However when I go to places like Sun's website and see a comment box with the following

I wonder if this is progress. There are even more perverse cases like StackOverflow whose current login page looks like

Of course, this is just StackOverflow's attempt to make the OpenID sign-in process easier for users instead of having them remember some obscure URL. Still I wonder about the paradox of choice style experience that is being thrown in front of users. Whenever I go to Hacker News I actually forget which of my various Facebook/Windows Live/Google/Yahoo IDs I've previously associated with the site via ClickPass. It actually would have been easier and less confusing for me to just create a regular account on the site like did with Reddit which would also enable cookies to work so I wouldn't have to sign-in every single time.

I also wonder about the unnecessary duplicative efforts it will take sites to integrate all of these different "Connect" offerings as well especially when you consider how radically different APIs like Facebook's friends.get are from Yahoo's Contacts API. I'm typically against premature standardization but when you have almost half a dozen offerings that effectively do the same thing but with radically different APIs it may be time for standards to start showing up.

Now Playing: Domino - Sweet Potatoe Pie

Earlier this year I was approached about writing a book on cloud computing topics by an editor for one of the big computer book publishers. Given that between my day job and having an infant I barely have time to keep this blog updated, I had to turn down the offer. However I did spend some time taking a second look at various cloud computing platforms like Amazon Web Services and Google App Engine then trying to put myself into the mindset of a potential customer as a way to figure out the target audience for the book. Below are the two categories of people I surmised would be interested in spending their hard earned cash on a book about cloud computing platforms

1. Enterprise developers looking to cut costs of running their own IT infrastructure by porting existing apps or writing new apps. 
2. Web developers looking to build new applications who are interested in leveraging a high performance infrastructure without having to build their own.

As I pondered this list it occurred to me that neither of these groups is well served by Google App Engine.

Given the current economy, an attractive thing to enterprises will be reducing the operating costs of their current internal applications as well as eliminating significant capital expenditure on new applications. The promise of cloud computing is that they can get both. The cloud computing vendor manages the cloud so you no longer need the ongoing expense of your own IT staff to maintain servers. You also don't need to make significant up-front payments to buy servers and software if you can pay as you go on someone else's cloud instead. Google App Engine fails the test as a way to port existing applications because it is a proprietary application platform that is incompatible with pre-existing application platforms. This same incompatibility rears its head when you look at App Engine simply as a way for enterprises to do new development. App Engine is based on Python, which if you look at the State of the Computer Book Market 2008, part 4 -- The Languages is not a terribly popular programming language. In today's world, enterprise development still means Java or .NET development which means enterprises will favor a platform where they can reuse their existing skills and technology expertise. Google App Engine isn't it.

So how about Web developers? In my classification, I broke up Web developers who'd be interested in cloud computing into hobbyists (like myself when writing a Twitter search engine on Windows Azure) and professionals (like myself when working on the platform that powers Hotmail's recently launched social features). Hobbyists either don't spend money or spend relatively little so I discounted them as a target audience of interest. The professional Web developers interested in cloud computing would be those who are considering Server or Web hosting but have concerns about scaling up if their service gets successful. After all, it seems like every week you are either reading about scaling hurdles that startup developers have faced as their applications become successful whether it is Bret Taylor's recent post How FriendFeed uses MySQL to store schema-less data or Jeff Atwood's Deadlocked! which talks about how he had to learn more about SQL Server's locking strategy as StackOverflow.com became more popular. The fact that Google App Engine is limited to only Python meaning that it is unavailable to developers using WISC platforms and only a subset of developers using LAMP can participate on the platform. Furthermore, there are key limitations in the platform that make it infeasible to build a full scale application. For example, Bret Taylor mentions that a consequence of having a denormalized database they need to run a background "Cleaner" process which fixes up data references and makes their database consistence. The App Engine DataStore API requires applications to store data in a denormalized way but there is no facility to run background processes to clean up the data as FriendFeed and most other large scale services which use database sharding often do. According to a recent blog post the Google App Engine roadmap has been updated so at least this limitation will be addressed. Other limitations for Python developers are that they can't use all of their existing knowledge of Python libraries since it only supports a subset of Python libraries. Database developers may be relieved that a lot of database management tasks no longer exist but may be chagrined once they see the restrictions on queries they can perform and hear some of the horror stories about query performance. At the end of the day, it just didn't seem to me that there were many professional Web developers who would put up with all of this pain over just going with AWS or dedicated hosting.

That said, Google App Engine does address the long tail of developers which I guess is nothing to sneeze at. Maybe it will see some success from targeting the low end in the same way that AdSense targeted the long tail of advertisers and is now the powerhouse of search advertising. Maybe. I doubt it though.

Now Playing: Aerosmith - Livin' On the Edge

Earlier this morning I was reading a number of comments in response to a submission on reddit.com where I found out that despite being a regular visitor to the site there were multiple useful features I was completely unaware of. Here's a list of features I discovered the site has that I hadn't noticed even though I visit it multiple times a day

• Private user-to-user messaging feature including an inbox containing all responses to your comments.
• A social networking component which enables you to customize the site so you only see content from your friends.
• An option for bookmarking my favorite stories so I could come back to them later

These are all clearly useful features. In fact, some of them are features I'd have lobbied for if ever asked what features I'd like to see added to reddit even though they already existed. Considering that I'm a fairly savvy Web user and visit the site multiple times a day, it is problematic that I'm unaware of valuable features of the site which were the result of valuable effort from the developers at reddit.

This is a very commonplace occurrence in software development. As applications add features without wanting to clutter the interface, they begin to "hide" these features until it gets to the point where their users end up clamoring or pining for features that actually already exist in the application. A famous example of this comes from Jensen Harris' series of posts on the UI changes in Office 2007. There is rather informative post entitled New Rectangles to the Rescue? (Why the UI, Part 4) which contains the following excerpt

Contrary to the conventional wisdom of the naysayers, we weren't (and aren't) "out of ideas" for Office.  Customers weren't telling us that they didn't need new features--to the contrary, the list of requests is a mile long.  Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features.  The only problem was that people weren't finding the very features they asked us to add.

To address the issue above, the Office team effectively dedicated a release to making their existing features discoverable¹. This isn't the only example of a popular application dedicating a release to making features more discoverable instead of adding new features. The Facebook redesign of last year is another famous example of this which has lead to increased usage of the site.

A recent TechCrunch article, Facebook Photos Pulls Away From The Pack shows the effect of the redesign on the usage of the site

...
What accounts for Facebook’s advantage in the photo department? The biggest factor is simply that it is the default photo feature of the largest social network in the world. And of all the viral loops that Facebook benefits from, its Photos app might have the largest viral loop of all built into it. Whenever one of your friends tags a photo with your name, you get an email. This single feature turns a solitary chore—tagging and organizing photos—into a powerful form of communication that connects people through activities they’ve done in the past in an immediate, visual way. I would not be surprised if people click back through to Facebook from those photo notifications at a higher rate than from any other notification, including private messages.

But the tagging feature has been part of Facebook Photos for a long time. What happened in September to accelerate growth? That is when a Facebook redesign went into effect which added a Photos tab on everyone’s personal homepage.

The lesson here is that having a feature isn't enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn't to add new features but to make sure the existing features are giving users the best experience.

When you do find out that usage of a feature is low given it's usefulness and relevance to your user base, this is a good time to invest in an experimentation platform where you can perform A/B testing (aka split testing) and multivariate testing. There are a number of off-the-shelf tools for performing such experiments which enable you to test and validate potential redesigns today without unleashing potentially negatively impacting changes to your entire user base.

¹I believe the Office team shipped lots of new features as well in Office 2007, however the biggest change from an end user's perspective was the redesign not new features.

Now Playing: Metallica - Harvester of Sorrow

I often wonder whether the founders of Twitter think of the site as a social utility that helps keep people connected with the people they know and care about like Facebook or whether it is primarily another personal publishing platform like Blogger. How they view the service influences the features that are the added to the site and its evolution.

For example, take a simple feature like "friend suggestion". A site that views itself as a social utility would implement such a feature in a way that attempts to bring you together with people it thinks you know or who've implied they know you. A site that views itself as a personal publishing platform for would-be pundits and people interested in them will end up recommending the most popular users in a move that mirrors the Bloglines Top 100 or recommending people based on editorial choice instead of how they relate to you.

Now compare the results of Twitter's Suggested Users feature shown below 

with one of Mr. Tweet's various recommendation options

Twitter's suggestions for me include a grocery store, the microblog of an online shoe store CEO and a mommy blogger. On the other hand, Mr. Tweet has actually recommended people I have met or at least know professionally. As I go down the list of recommendations from Mr. Tweet and finally encounter people I don't know they are at least people who move in the same circles as me online. On the other hand Twitter's list contains a grab brag of celebrities and brands that have no direct connection to me.

Twitter is squandering an opportunity to grow their social graph in a way that deepens their users connections on the site and with the site. If I were in their shoes, I'd pick up Mr. Tweet in the same way they picked up Summize because the technology and feature set nicely complements the site and fills a hole in their user experience.

Now Playing: Metallica - Leper Messiah

There's some storm in a teacup around Facebook's terms of service which is in reality just another iteration of the freak-out-because-web-company-changed-their-terms-of-service that we see in the blogosphere every couple of months. For the most part this is a boring dance but there is an interesting issue around end user expectation around sharing content and ownership of their personal data underneath all the melodrama.

The point of interest is called out in Mark Zuckerburg's post On Facebook, People Own and Control Their Information where he writes

One of the questions about our new terms of use is whether Facebook can use this information forever. When a person shares something like a message with a friend, two copies of that information are created—one in the person's sent messages box and the other in their friend's inbox. Even if the person deactivates their account, their friend still has a copy of that message. We think this is the right way for Facebook to work, and it is consistent with how other services like email work. One of the reasons we updated our terms was to make this more clear.

The issue of what to do with content a user has shared when they decide to delete the content or attempt to revoke it is in an interesting policy issue for sites geared around people sharing content. When I've discussed this with peers in the industry I've heard two schools of thought. The first is that when you share something on the Web, it is out there forever and you have to deal with it. Once you post a blog post, it is indexed by search engines and polled by RSS readers and is then available in their caches even if you delete it. If you send an inappropriate email to your friends, you can't un-send it. This mirrors the real world where if I tell you a secret but it turns out you are a jerk I can't un-tell you the secret.

The other school of thought is that technology does actually give you the power to un-tell your secrets especially if various parties cooperate. There are ways to remove your content from search engine indexes. There are specifications that dictate how to mark an item as deleted from an RSS/Atom feed. If your workplace uses Outlook+Exchange you can actually recall an email message. And so on. In the case of Facebook, since the entire system is closed it is actually possible for them to respect a user's wishes and delete all of the content they've shared on the site including removing sent messages from people's inboxes.

I used to be a member of the second school of thought but I've finally switched over to agreeing that once you've shared something it's out there. The problem with the second school of thought is that it is disrespectful of the person(s) you've shared the content with. Looking back at the Outlook email recall feature, it actually doesn't delete a mail if the person has already read it. This is probably for technical reasons but it also has the side effect of not deleting a message from someone's inbox that they have read and filed away. After all, the person already knows what you don't want them to find out and Outlook has respected an important boundary by not allowing a sender to arbitrarily delete content from a recipient's inbox with no recourse on the part of the recipient. This is especially true when you consider that allowing the sender to have such power over recipients still does not address resharing (e.g. the person forwarding along your inappropriate mail, printing it or saving it to disk).

At the end of the day, many people would like to use technology to solve what is essentially a social problem instead of adjusting their behavior. The bottom line is that even though it is technically possible for Facebook to delete my private messages from your inbox when I decide to delete my account, it would be harmful to your user experience AND it doesn't buy me anything since you've already seen the content. The real solution is for me not to have sent any messages to you that I'll later regret in the first place.

Now Playing: Bush - Everything Zen