Migrating user accounts from Google OpenID to Google OAuth to Google Plus


Over here, Ade has asked me to permalink a comment I made about moving Player FM accounts from Google Open ID to OAuth. The reason I did it was because Android sign-in is really based on OAuth, but what I didn’t know was Google at the time was preparing to launch “Sign in with Google Plus”, also based on OAuth. Bottom line: Google Open ID, afaict, is going the way of the dodo, so any services using it probably want to migrate their users to G+. (Googlers may please correct me if I’m wrong about Open ID’s demise.)

There were many permutations to be considered for this kind of migration, each with trade-offs to developer complexity and user experience. What follows was the optimum balance for me after a repetition of thought experiments, in between wishing I had a pony (ie that I’d opted for OAuth in the first place, the only reason I didn’t was availability of an Open ID Rails plugin). This is all web-based as we (thankfully) hadn’t launched on Android yet.

The problem

The first concern here is largely about user perceptions. To us developers, Google OAuth and Google Open ID are distinct login mechanisms, as similar to each other as they are to Facebook or Twitter. But to the user, they’re the same thing – Googles all the way down. So you can’t present the user with separate login buttons for Google OAuth and Google Open ID…you only get to present one Big G button.

The other concern is that sites who present “Existing users – log in here” versus “New users – sign up here” buttons … are doing it wrong. A major benefit of third-party sign-in is you can just present a “Connect with X” button and the user doesn’t have to care or remember if they previously connected with X or not. Don’t make me think!

Put concern A together with concern B and Houston, we have a problem. You present that one big G button with Google OAuth and what happens if the user is unrecognised? Is this a new user or someone who had previously logged in using Open ID. (It’s fine if the user is recognised, that means they’re one of the post-OAuth-era people.)

The solution

The solution depends if you’re willing to ask for email permissions on the new oAuth flow.

If you are willing to ask for email, that will make it easy to link the two accounts, because Open ID already relies on email, so you have their email. You can just switch right now to oAuth and once the user authenticates, link the account with the account having the same o8 ID. (Note: this scenario is purely speculative and not based on my experience.)

Since I chose not to ask for email, I had to do the uncool thing and temporarily divided Login from Signup.

In the Login area, the app prompted users for their email or login, and immediately made an XHR call to detect whether that account is using o8 or oAuth, then showed the corresponding button (the button is just a Google button, looks the same either way but the link will be different for o8 vs oAuth). (In addition, the Twitter and classic login form were shown.)

For people who logged in with Open ID, I built an !IMPORTANT! big red notification when the user logged in via Open ID, telling them we’ve updated Google login procedure, and when they click to set it up, taking them through the oAuth flow with a special callback for the migration. At this point, the server recognises the two accounts are linked (they’d already logged in with Open ID, now they’ve just logged in with OAuth), so we can save the user’s OAuth credentials. This user now has two third-party accounts – Google Open ID and Google OAuth. Just as they might also have a Facebook account and a Twitter account.

The Signup area of course only contained an OAuth button (as well as Twitter, which was exactly the same as Twitter in the login area, and classic signup form).

I published advance notice on the blog I would be shutting down the old Google IDs, kept the migration alive for two months, and then deleted all the Open ID accounts at that time. Anyone who didn’t log in at the time lost their accounts, but of course a few people mailed me about it (mainly when we launched the Android app and they tried to log in again), so I helped them migrate manually.

I did this for a couple months before deprecating o8 and returning to the nicer single Google button setup. And just manually merged the accounts when a few users asked me why the Google button is not getting them back to their old account.?


It was well worth the pain, as the vast majority of Android users now choose to log in with Google, even though we also support classic login and guest mode. The G+ API was a big bonus to come out of it. I’ve done some experiments on the social side and expect to do much more with G+ accounts in the future, to help people discover new shows to listen to.

Why Google killed off Google Reader: It was self-defense (GigaOM guest post)

Guest-posted this on GigaOM today.

Backstory is I started writing it on Thursday night after seeing all the Reader tweetstorm and figured it’s probably of more general interest, so I submitted it there. The original draft was ~1400 words and I wasn’t sure how seriously they take their guideline fo ~800, so just left it at 1400, but turns out they are, in fact, serious. So we edited it down.

For the record (since some people asked), I used Bloglines for as long as I could cope with its downtime, as I always found Google Reader too magic (unpredictable) with its use of Ajax. Eventually Bloglines was outaging for hours and IIRC whole days, so I made the switch to Reader, but could never get into the web app – too much Ajax magic – and instead used Reeder, sync’d to Reader when it came along. When I switched to Android for my primary device, I couldn’t find a satisfactory app, so just used Reeder on the iPad occasionally.

Meanwhile, with podcasts, I preferred the cloud approach of Odeo and Podnova, but both sadly died. I tried podcasts with Reader, but it just wasn’t the right experience so I mostly used iTunes, and then on Android, mixed it up between several apps (DoggCatcher, BeyondPod, PocketCasts, etc…the usual suspects) until eventually creating my own (still in beta). I really had problems with Listen though, so again, no didn’t do the Reader sync.

So bottom line is I did use Reader “somewhat”, but mostly as an API; and it’s no great loss to me like I appreciate it is to others. The responses to this article certainly demonstrate how passionate people are about a product they get to know and love, and use on a daily basis. It’s never easy giving up on muscle memory. The bright side of the equation is exactly what people like about it: RSS and OPML are open, so at least people can move on to Feedly, Newsblur, and so on. And I truly believe this decision ultimately liberates the standard and allows it to thrive among smaller players.

Discovering Users’ Social Path with the New Google+ API

Google announced a slew of identity and social updates today, most excitingly, the ability to browse users’ social paths. This happens after similar services recently blocking some folks from doing so, which tells you Google gave it due consideration and is committed to supporting this feature indefinitely.

Here’s how the authentication looks:

Now there’s a whole set of widgets and JavaScript APIs, but I was interested in the regular scenario for apps already using the “traditional” OAuth 2 dance. After asking on the G+ APIs community, I was able to get this running and I’ll explain how below.

Step 1. Visit the API doc: https://developers.google.com/+/api/latest/people/list

Step 2. Scroll to the interactive part below and turn on OAuth 2.0 on the top-right switch.

Step 3. To the default scope, add a new one: https://www.googleapis.com/auth/plus.login. That’s the magic scope that lets your app pull in social graphs.

Step 4. For userID, enter “me”. For collection, enter “visible”. (This collection property, representing circles/people the user can identify to the app, only has that one value at present.)

Step 5. Now hit execute and (as a test user) you’ll see the dialog shown at the top of this article. Then hit accept.

Step 6. I got a confirmation dialog saying “Clicking Confirm will let Google APIs Explorer know who is in your circles (but not the circle names). This includes some circles that are not public on your profile.” which is surprising as I believe circles are always private (for now), so I guess users will always see that. Accept it.

Step 7. The JSON response will now be shown below the form. It includes a top-level field called “items”, which is the list of your (the authenticated user’s) G+ people. If the list is too long, there will also be a “nextPageToken” field so the app can page through the list.

So that’s an overview of the new G+ social API. It’s a straightforward OAuth implementation and should be easy for anyone with a Google login to adopt. I’ve been looking forward to adding this functionality on Player FM so people can see what their friends are listening to … I think it’s a nice model where users can choose how much of their social graph they share with any app.

Integrated Google Plus on the Homepage

I’m getting more convinced Plus is the new Twitter, and also the new Posterous. I’ve been posting things on there I previously would have stuck on the Twitter or the Posterous, and so it was time to integrate Plus on my homepage alongside the existing Twitter and Posterous links.

Latest Post

It was pretty easy to integrate my latest Google Plus post (we don’t really have a name for a Plus post yet; a plust?), as I already have a framework in place for showing the last post from an Atom or RSS feed.

First, I found my Plus feed URL thanks to Russell Beattie’s unofficial Plus Atom Feed service:


Using MagpieRSS, you can easily get the last post.

  1. define('MAGPIE_CACHE_ON', false);
  2.   require_once('magpierss/rss_fetch.inc');
  3.   $feed = "http://plusfeed.appspot.com/106413090159067280619";
  4.   try {
  5.     $rss = fetch_rss($feed);
  6.     $recent_post = $rss->items[0];
  7.     $title = $recent_post[title] . " ...";
  8.     $link = "http://mahemoff.com/+", $recent_post[link];
  9.     $timeAgo = timeAgo(strtotime($recent_post[updated]));
  10.     // show the post
  11.   } catch(Exception $ex) {
  12.     // log exception
  13.   }


Inside the CSS3-rendered vcard, there’s a link to my plus alongside twitter etc.:

  1. <a rel="me" class="url" href="https://plus.google.com/106413090159067280619">plus</a>

/+ …. redirect to Plus

Following Tim Bray’s suggestion, I redirected http://mahemoff.com/+ to the plus page. It’s nice to have a memorable URL.

Google Plus: The Good and the Bad

I’m on Google+ and I’ve mostly found it pretty decent in the ~2.5 weeks I’ve been using it. (Also had an opportunity to do dogfood before it went live, but really, it’s a different world once it’s out there and being used for real, so that’s what this post is about.)

Thought I’d sum up my experiences to date. You’ll notice a lot of my comments compare it to Twitter, because after all the crowd has been similar so far. And honestly, I often find myself with something to write and having to decide whether to stick it on T, G, or both. The decision feels kind of arbitrary right now and will probably shift to G over time, unless Twitter gets its innovation seriously on …

The Good

Things to like about Google Plus …

  • The UI! I’ll call out the design first because it’s not been Google’s strong point in recent years. Yes, clean white pages were a breath of fresh air in 1997, but getting long in the tooth now, and Google Plus shows Google’s now getting serious about visual design, and beyond just statistical hue calibration.
  • Engagement. The overall experience leads to much higher engagement than I’ve seen with blogging, twitter, or anything else. For the big guys, you see literally dozens of comments in the first few minutes.
  • No size limit. You don’t have Twitter’s 140 character limit. Fortunately, Twitter taught us the benefits of brevity, so it’s very acceptable to write just a sentence or two. But you can still go all out with an entire paragraph and that’s fine too. And no more shoehorning txt,just 2fit the arbtrary char limit.
  • Comments. Compared to Twitter, I actually have all responses to my status in one place. On Twitter, there’s no UI to see all the responses to a tweet; you have to view them all individually. The comments also facilitate a conversation, whereas on Twitter, you’d end up with multiple tweets and no decent UI (save third parties perhaps) to view the whole conversation.
  • Mentions. Similar to Twitter @ mentions, but because of the comments, + mentions have more of a feel of being summoned into a conversation. It’s certainly easier to get the entire context of the conversation in which you’ve been mentioned.
  • Search. <rant> Seriously a shambles about Twitter is the inability to search through tweets. I can’t even search my own tweets!!! This was one of my initial motivations for using posterous, figuring I’d pipe everything through it. And same reasons others use identica, etc. The problem is you don’t get all the clients, e.g. Tweetdeck. So I ended up sending a lot of tweets which I can’t actually search through. They fall off Google and they fall off Twitter’s own search. It has constantly amazed me that a company in constant search for a revenue stream doesn’t have a full history of content available.</rant> Now, with Google Plus, there’s no search either, but at least advanced users have the option to search using site:plus.google.com. And in all likelihood, we can assume Plus will have search too. (Although Android search shows Google + Search is not a foregone conclusion of excellence…but Plus’s virtues to date promise good things.)
  • Hangouts. I think the concept of video hangouts is immense, as opposed to just standard VC, and will be a great asset for remote teams. (I know some teams already just keep an open skype session running all day.) However, I’m speaking out of my speculatum because I haven’t yet tried it, for reasons explained below.
  • Updates. The team is doing a great job of engaging with the community, listening to the feedback, and making updates. They’re doing a great job if the worst controversy is closing down accounts of sophisticated tech companies blatantly flouting the rules by setting up corporate accounts, complete with filling in their first name, surname, and gender.
  • Android App. A fine production.

The Bad

Things not to like about Google Plus, keeping in mind it’s still in “field testing mode” (“beta” is so web 2.0) …

  • Circle statuses aren’t public. The problem is I want my Twitter-like geeky status updates to be public, but not contaminate the streams of my non-geek friends and family. There’s no good solution for this right now. If I publish a geeky status update to my “webdev” people, they will get to see it, but it won’t be public. If I publish it to “Public”, everyone in my circles sees it. Right now, I’m opting for “Public”, and if others are doing likewise, their non-geek friends and family will freak out the first time they join Plus and run fast in the opposite direction.
  • No groups. A lot has been said about whether circles themselves are a good idea, given that people’s relationships are nuanced and dynamic. But what interests me more than circles is groups. I’m really hoping Google somehow merges Google Groups with Plus; private groups would be particularly powerful for workgroups. The cool thing about groups, like what Facebook has but few people use is: (a) compared to circles, the visibility model is easily understood and predictable – someone can see messages if they’re in the group and can’t see them if they’re outside the group…simples! (b) you don’t have 100 people all adding the other 99 to the same circle and all micromanaging their circles to stay in sync – the owner just adds everyone once…this saves a lot of hassle, it works better for mainstream users who can’t or won’t micromanage circles, and ends up with a single source of truth.
  • Comments UI. As I mentioned on + Comments UI works for the average Joe with a handful of comments. But for Scoble etc, they are reedeeculous! 100+ comments in an hour? With no threading. It’s a mess to read and removes much of the incentive to post anything. This stuff is write-only. Since comments are +1able, G+ should let the popular ones float to the top, or perhaps display them with the others being collapsed. There are some other good suggestions in the comments to the aforementioned + post.
  • Comments and Sharing. The problem with sharing is people will comment on the sharer, not the original. I think it makes sense for everyone to be commenting in the same space, or at least for some easy summary view. I think this is Google being initially biasing towards privacy measures to avoid adverse reaction, but it does lead to comments being even harder to follow.
  • Finding hangouts. I can’t. Maybe that will change now that PlusRoulette is here! Or not. I also hope Google adds the ability to record hangouts at some stage. Lightweight video podcast ftw!
  • No metadata. I get it. Statuses don’t have titles or keywords or anything else because people are lazy and sites that don’t realise that won’t go mainstream. So Google’s being smart here. But that said, for my own use case, there are times when I’d love the ability to tag a post with “announcement” or whatever, so I can later have a feed of those. Anyway, I guess one can work around it by including some hashtag-like token in the actual status. Just making that point, though I realise my own use case is not that which Google is targeting – it seems the lesson has been learnt from Wave et al that Googlers and assorted geeks shouldn’t always be the target audience.

Okay, that’s me done. I’m enjoying Plus and I’m hoping it spurs Twitter and others to build on the awesome. Are you using it? Any other goods and bads?

Update: conversation on Plus

I, Xoogler


I am now ex-Google. In this post, I’ll reflect on my time as a HTML5/Chrome Developer Advocate at Google, why I decided to move on, and what I’ll be doing next. In a follow-up post, I’ll do a bit of a roundup of my main activities while at Google. This is a long one as other priorities meant I didn’t get around to blogging much about Google while I was actually there!

Where to next? Nowhere, of a sort. I’m staying right here in London and not jumping to any company at this time. I have a ton of itches to scratch, so I’m looking forward to doing some hacking and building apps. I’ll be drinking the HTML5 kool-aid I’ve dished out in ample quantities.

Life at Google

I joined Google in April, 2010, and it really is an amazing place to be. I’ve worked in a lot of different environments, from startups to SMEs, to large enterprises, and across several industry sectors…and Google really does stand out as uniquely awesome, for the following reasons:

  • The people. Of course, you always hear about all the industry rockstars, but the remarkable thing is those conspicuous by their absence. If you’ve worked in a big company, you’ll know what I’m talking about. There’s always that guy (or girl). Only one of them if you’re lucky, but one is all it takes to doom projects and drive away talent. That guy (or girl), who might not even be a developer and might not even work in your department, but will still be there to do silly things and block all manner of progress, maybe in the name of mortgage-driven development or maybe because they have a solid theory about sticking beans in their nose. The absence of those people from Google is the really noticeable difference, not the rockstars. (Rockstars are not exclusive to Google after all.) To quote Joe Kraus from In the Plex, “There were no bozos”. But more than that, the baseline is set high and defended wide.

    Having conducted numerous job interviews, I saw first-hand how the company is relentless in maintaining its quality threshold; from my observations Google takes a “talent collector” attitude. It’s patient and would rather accumulate a talent pool over time than make any compromises. Every company likes to pay “people are our best asset” lip service, but Google takes it really, really seriously.

    Most importantly, we’re not just talking about technical ability, but a company culture of helpfulness and enthusiasm, and this includes non-engineering functions too. Certainly people are busy, so they won’t always go along with your plan…but when there is inaction, it’s not borne of malice but resource constraints. It’s not the zero-sum, cut-throat, mentality you sometimes see in mature industries, where there’s an expectation that one worker’s promotion is another’s stagnation.

  • The ambition. In a previous role, a phrase I heard constantly was “we’re not trying to boil the ocean”. This was a valid way of keeping things real, but also a good way to progressively evaporate the dreamer in each of us. In contrast, “boiling the ocean” is etched into Google’s DNA. Google+ is the latest example, another is Chrome, the product I worked most closely with, another is Android, etc.
  • The openness. Internally, Google is incredibly open about upcoming projects and company strategy generally. It has both the culture and the technology to pull this off. Culture-wise, there’s an attitude that people should be free to test and even work with other projects; as Dion once pointed out, openness is the real genius behind 20% time and the part many companies miss when they pontificate about “driving innovation” and “inspiring creativity”. Using Buzz internally was tremendously rewarding; companies who have used tools like Yammer can probably relate, though I think Buzz is more amenable to these kinds of conversations (lacking 140-char limits and supporting comments against status updates).
  • FOOD! And the massages, etc. But especially the food! “Free” is not actually the main benefit. It’s simply the option to go grab a healthy (or less healthy, but the point is that you have a choice) meal quickly with your colleagues. That it’s at work means it’s convenient and that it’s free means there’s no counting or payment process to slow things down. Not that it hurts the bottom line either :).

So why would I leave all that? I’ll explain more further down …

Life in Developer Relations

I’m proud and fortunate to have have been part of Google’s ever-growing Developer Relations organisation. Here’s Don Dodge’s description of the team: “Thirteen of them have authored books, at least four of them have software patents to their name, and most of them have made significant contributions to Open Source projects. Several others have contributed to industry standards, and sit on standards boards.”

Working in developer relations gave me a chance to be paid to do things I’d done in my spare time: participate in conferences, blog, play with interesting new tech, etc. It let me meet and be inspired by many developers around the world. And it also gave me a chance to reflect on the growing discipline of developer relations and the broader topic of Developer Experience.


Overall, companies are realising that if they want to provide APIs and platforms, it takes more than a marketing department to win developers over and support them in their efforts. Microsoft has been a pioneer here with its “Developers, Developers, Developers” mantra (there was actually a profound point in there!) and Apple too with its evangelists; but Google has more recently played a key role in grounding this role more on the engineering side and framing the role as an “advocate” of the external developer rather than an evangelist of the platform.

Life in HTML5 and Chrome

The growth of HTML5 and Chrome have both been astounding in the time I’ve been working in this role. (Naturally I accept full, unconditional, personal responsibility.) We saw Chrome jump from 70M actives to 160M between IO 2010 and IO 2011. And the web feels like a different place.

The APIs we now enjoy as web developers are plentiful and continue en masse – CSS3, WebGL, IndexedDB all in several major browsers. Installable web apps. Mobile HTML5 en masse. At the same time, it’s not a foregone conclusion that “the web has won”. There’s the risk of fragmentation as browsers plow ahead with different features. It’s being handled nicely through stnadards process, but the risk is always there. And while there’s not much life in desktop platforms, the native mobile platforms are rolling along very nicely, thankyou very much. Mobile HTML5 has come a long way, but the gap remains.

Just as interesting, the fundamental development platform has shifted. We’re seeing an excellent shift towards a superior developer experience. The HTML/CSS/JS trio is becoming HTML++/CSS++/JS++ through a new breed of language enhancements which don’t so much replace them as augment them. Sugar … it’s sweet! Jade/Stylus/CoffeeScript is the stack preferred by the exciting new SocketStream framework and will continue to flourish until the browsers themselves start to simplify things, through intiatives like JS.Next.

And then there’s the Nodequake …


Life After Google

There’s a lot of logical career moves from here, but since life is short, logic is overrated. The main reason I decided to move on is I have a massive urge to do some dedicated hacking time. There are apps in my head, they need to come out.

I was certainly able to have some fun coding while at Google, with some bite-size apps even being used in production.

But I was at a fork in the road. I’d be struggling to cultivate a serious app, with a serious server side and serious users, in 20% time. Yes, 20% time really does exist and I saw some people achieve good things with it. But 20% is an upper bound, and for the kind of apps I want to be working on, I’ll want to be spending 120% time on them to get them going. Also, some apps I want to make would be seen as downright mundane, or quirky to the point of weird, but are still apps that I want to transplant from my head to my web server. If for no other reason than I want to use them myself.

From a technology perspective, I really want into Node too. I’ve been dreaming about server-side JavaScript for a long time and looking forward to using it in anger now that Node took it mainstream.

My immediate goal, though, is to fix up a few existing sites, e.g. make WebWait mobile-friendly and make ListOfTweets cleaner, persistent, and social. I have a few apps on similar scale in mind beyond that, and can’t wait to make them happen! Of course, I’ll be happy to get feedback, so please let me know if you want early access. Of course, stay tuned on this blog for more info.

And Thanks

Thanks go to my colleagues, partner companies, and the developer communities I’ve been able to work with throughout my time at Google, as well as those who invited me to apply for a role I didn’t really know existed (you know who you are!). Please keep in touch.

And thanks for reading. As mentioned above, I’ll write up a roundup of my time at Google in a followup post.

(This post is slightly late; my final week was the week before last. But a few hours after handing over my card and a big pile of tech on that Friday afternoon, I was bound for the excellent south coast of Turkey, where limited bandwidth and way too much sunshine prevented me from mentioning this earlier.)

Joining Google

I mentioned I’m moving on from Osmosoft a few weeks ago and after 12days and a week of doing much less than one could ever have imagined, it’s time to announce where I’m going: Google. I’ll be joining Google as a Chrome developer advocate, which means focusing on HTML5, Javascript, the Chrome browser, ChromeOS, and related technologies.

I’m very excited about the role, for reasons best explained in terms of a timeline for the web. I see the history of web technologies divided into three phases and I believe we’re currently in the transition from the second to the third phase. Which is the starting context for this role.

Dark Ages (Web as a Black Art)

Rich web apps were hard work. Black art even. During this phase, I spent most of my time on server-side languages – Perl, PHP, Java/J2EE – and Javascript was a weird sideline. Taking an interest in the user experience, I always wanted to know more about this black art, since it’s the web technologies that touch the user and have the most direct influence over their experience with any application. But what paid the bills in the late ’90s and early noughties was form submissions and page refreshes. And most Javascript content was odd little ticker tape scripts you could download, not too much to learn from, and always difficult to achieve in one’s spare time. I think this was the frustrating experience for many web developers: not enough time and hard work. I did get by and pick up a few tricks here and there, but things only took off when the A-word was unleashed …

Ajax Era (Web as an Established Practice)

Everything changed five years ago, on February 18, 2005. Jesse James Garrett hopped in the shower, came up with the term “Ajax”, and published his thoughts on this rising architectural pattern. Many people bristle at the notion that a simple term, for something people were already doing, can make such an impact. “BUT I already knew how to do that!” they cry. Good for them. But the fact is, Ajax allowed the whole developer community to rally around this style of application. Events, blogs, books, libraries, tools, the whole thing flourished. I got seriously interested, recorded a podcast explaining the topic, and started diving into all the existing applications, which ultimately led to the Ajax Patterns wiki. All those applications, and many featured in the book, were created in the Dark Ages by brilliant pioneers who had scant resources to learn from. Today, such applications can be created at exponentially faster rates. This is thanks to improved knowledge, improved libraries, and improved tools.

There are historical analogies to this era, e.g. the rapid rise of the automobile industry once all parts were in place. In that case, it was more a matter of discovering new physical and engineering principles, whereas with Ajax, it was a superficial act. The browsers were already there, with a killer feature like IE’s XMLHttpRequest sitting largely unnoticed for five years. Few people had taken the time to really understand how they worked. It was the Ajax term to trigger the boom.

HTML5 Era (Web on an Improved Platform)

(I hesitate to call this the era of HTML5, as many things happening are outside HTML5, notably improvements to CSS and the core Javascript/ECMAscript language. But HTML5 is increasingly becoming a brand, much like Ajax in its heyday, a term that’s familiar to anyone with a passing interest in technology.)

The starting point for this era is the success of open web technologies. While we continue to learn more each day, we have the basics in place today. We know how to harness HTML, CSS, Javascript to make powerful libraries and applications on the existing browsers. This is where the Ajax Era landed us. We have seen some genius hacks. In fact, we have seen MANY ingenius hacks. On-Demand Javascript and JSONP, for example, are completely fundamental to the way business is done on the web these days, and is utterly a hack. Full credit to those who came up with them, but these hacks can only go so far. They can increase programming complexity, impact on performance, and cause security threats for those not fully-versed in their capabilities. And that’s just for the things we can do. The bigger problem is that we are heavily limited in our functionality on Ajax-Era technologies. We can’t do rich graphics or video, for example. So the next stage is all about improving the underlying platform. It’s not something an application programmer, however heroic, can do on their own. It’s something that has to involve improvements from the platform providers, i.e. the browser manufacturers and others.

To draw a line in the sand, take IE6. Although it was created back in 2001, we could do far more with it in 2004 (e.g. Google Maps) than we could in 2001, and we can do far more with it in 2010 than we could in 2004. This is because of all the knowledge, libraries, and tools the Ajax Era has provided. However, we’re in serious plateau mode now. We can continue to squeeze out 1-percenters, but the low-hanging fruit was plucked and digested a long time ago. The next stage has to be an improvement to the underlying platform, and that’s what’s going on today with modern web browsers.

Once you say “okay we’re now going to build the next-gen web platform”, you’re not just going to add support for round corners. So there’s been a truckload of effort going on, in HTML5 and beyond. Graphics in the form of canvas and SVG and WebGL and CSS3, media in the form of audio and video tags, semantic markup improvements, new form controls, offline storage, support for location-awareness. And much more.

We have the new platform and alongside it, we have the activity of understanding how to use the new platform. Not just understanding the parts, but the whole. How do you put all these things together in meaningful ways. Can we show custom-font text on a canvas? If so, how? And when does it make sense? And how to avoid performance problems? Or, to take another example, what kind of CSS transforms can we use to render videos? And since we can grab image data from the videos, what are some cool things we can do with that data? And all the while, where’s the graceful degradation story here? How do these apps look in older browsers? Most of the talk so far has been on the capabilities of the platform, not patterns of usage.

All these new capabilities take us to the place we’ve been aiming for all along: true applications deluxe, not just “html++”. Of course, there’s plenty of room for both of these, but we’re now in a place where we can really build true applications with all the capabilities of a traditional native experience. We’re seeing it in a big way in mobile space. The new model is all about sandboxing, doing away with the filesystem, and explicit permissions. Exactly what the web’s good for. They’re not only a good fit technically, but they’ve become the ubiquitous lingua franca among the programming community. The technologies are familiar, as are the patterns of UI design and code composition. Those patterns will continue to evolve with HTML5 and associated technologies.

We’re just scratching the surface here; there are exciting times ahead!

I’m not an official Googler yet, nor even a Noogler, as I’ve taken time off to chill, smell the roses, and pursue a few projects (like dusting off the homepage and … watch this space. Actually, watch that space). I’m starting in about a month. And of course, even when I am official, this blog continues to be my own opinions, caveat emptor yadda.

The role covers EMEA and I’m still based in London. Despite not starting just yet, I’m looking forward to participating in tonight’s Chrome/Chromium OS and HTML5 London event. See you there!

(I’m not the only one to announce a move to Google at this time. I’m looking forward to meeting and working with many of my talented future colleagues.)

Google IO Keynote, 2009

I’m here at Google’s London office, where they’re streaming the IO keynote.

Eric Schmidt talks about Ajax, always-on, simplicity, and how it’s improved life.

Vic Gundotra’s on. We spent too long not fully using XML, CSS, etc., i.e mid-late ’90s they were there, but really started using them to the max around ~2005. Let’s not wait so long for the current technologies.

Now we’re talking about five things that excite Google. (He doesn’t identify the 5 things.)

Canvas. Includes a demo of Bespin – nice one Dion, Ben, and Joe :).

3d graphics – keen to work with people on APIs for this. Good demo, but it’s a plugin, so still needs work!

Video. Shows YouTube.

Address from Firefox VP.

Firefox 3.5. As well as canvas and video, …

Great performance boosts since 3.0 and ?10 times since 2.0.

Support for Geo-Location.

Support for offline.

Support for web workers.

A geo-location demo. Browser gathers signal strengths of nearby hotspots and worked out lat/longs. If cellphone, towers. Or GPS if it’s there. Users will be able to download add-ons to choose the functionality. (Very Fire Eagle).

Back to Vic

And Apple have also implemented W3C Location API, so it’s there in Google Maps on iPhone 3.0 OS.

Demo-ing a simple offline app, and then showing GMail on Android and iPhone, Google’s first major HTML 5 app.

Palm Address

Michael ?? from Palm. Showing how HTML5 is used – e.g. CSS transformations for animation.

Shake, orientation, acceleration – all these are available in Javascript in Palm…and would like to see them introduced to HTML5. window.addEventListener("shakestart", beginShaking, true);

Back to Vic

Talking about performance – impressive web workers demo. Followed by a more impressive demo of motion detection within Javascript, analysing a video.

App Engine and GWT Talks


Google Web Elements

Inspired by embedding videos etc.

It’s bascally widgets 12.0. Just a much cleaner way of grabbing gadgets and putting them on your page – get some cut and paste HTML, which is an iframe rather than the usual script tag.

Ready now at http://www.google.com/webelements

I’ll embed one here:

Text-To-Speech API

As part of Android, there will be an open source text-to-speech available. (How about a public one for any web developer?)


He gives away 4000 Android phones, one per person. In London, we get pizza and soft drinks. But then, a small detail – the SF attendees actually paid for to be there! We just left the St James office and rocked up, so a decent event all things considered. Thanks to Google for hosting it and hopefully the same next year.

Google jQuery CDN

NO LONGER UPDATED: July 2012. This page is no longer indexed prominently in Google, so keeping it up-to-date is not much use to anyone. So consider updates finished. Try this link instead

SUMMARY: Get the latest jQuery here:


To include in your web app, cut-and-paste this:

<script src=”http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js”></script>

You can also cut-and-paste one of the following to suck it down:

  • curl -O http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
  • wget http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

With the release of JQuery 1.3, I thought I’d mention the Google JQuery CDN, one of several libraries you can yoink from Google’s Ajax Libraries API. Instead of hosting your own JQuery, you just point your web app to Google’s JQuery:

<script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js”></script> (Modified version from 1.3. I’ll try and keep this post linking to the latest version.)

Google’s documentation would lead you to believe you need to import Google’s library, and then call google.load(), but it’s unnecessary; just pull in the script directly using the link above. The link is officially documented, so it’s going to stay put for a very, very, long time.

There are also other libraries available on Google’s CDN and elsewhere.

The main point of the CDN is caching. If a user hits 100 JQuery sites, the library will only be downloaded once, and the remaining 99 sites will pull it from the local cache. From an operation cost, you also get to offload the cost of server Javascript to Google. As an added bonus, I also find it easier as a developer to kick off a new project by just linking to the CDN – no need to download and copy the latest version of JQuery.

Great. So when not to use a CDN?

Obviously, whenever you’re working offline. This sometimes occurs as a developer working locally, and with Single Page Applications like TiddlyWiki. (The next “major minor” release of TiddlyWiki, v2.5 is JQuery-powered.)

Another case would be when you can deliver faster than the CDN, and care about that. This might be the case when all users are close to the server. Even then, though, you won’t get the local cache benefit from users who already have the JQuery.

Finally, privacy and security concerns. Using the CDN, you are trusting the CDN to faithfully serve JQuery and relying on no third-parties injecting funniness in between the CDN and your user’s browser. If anything went wrong here, your user could be subject to a world of XSS and CSRF attacks. Or, in a more mundane scenario, the CDN might simply go down, thus breaking your web app. Furthermore, you’re giving the CDN data about your users this way. Although Google doesn’t use cookies, others might; and even if they don’t, the IP number is going to be sent back to them. The referrer – being your website – will also be sent to them, so they can, if they want, track your website’s usage.

For many websites, though, it’s great that we can use a reliable CDN like Google’s to fetch JQuery fast.

Update (11-Feb-2009): In a show of recursive linking, I should fess up as to why I originally sat down to wrote thistwitter message.

Update (erm, mid-2009 sometime): Montana left a comment pointing out you can also drop off the minor numbers to get the latest version. So, for the latest JQuery (since 2.0 doesn’t exist), use http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js. Or, for the latest in the old 1.2 series: http://ajax.googleapis.com/ajax/libs/jquery/1.2/jquery.min.js.

Update (19-March-2010): Scratch that. @premasagar pointed out to me that the link to just the latest version (until 2.0, i.e. http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js) as opposed to a specific version (http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js) is undesirable; Google will expire the “latest” content after one hour, as opposed to one year for a specific version. This is for good reason of course, as the latest version is subject to change. For this reason, I’ve reverted the link at top to be a specific version, which I’ll endeavour to update upon each new release.

Tools Europe – Pre-Workshop Preparation

I have the honour of delivering a keynote at the Tools Europe conference in Zurich next week, as well as at the “Mining Web 2.0 Patterns” workshop, which, as you can tell from its title, I’m looking forward to participating in. The workshop chairs are Dragos Manolescu and Joe Yoder.

The keynote is on OpenSocial, Gadgets, and Design Patterns; and I’ll have more to say about it later. I believe it will be recorded too. For now, I’m using my blog to post my response for the pre-workshop preparation.

Sites and materials relevant to my presentation


  • Which features make the gadgets easy or hard to use, and how might the gadgets be improved?
  • At UI level, which best practice patterns are apparent?
  • What changes to the platform would improve user experience?

Sites and materials relevant to other workshop tracks

Site Navigation: