Interesting stats:

• 21 web services analyzed
• 10 (48%) are using OAuth (including YouTube)
• 5 (24%) are using AuthSub (also including YouTube)
• Dopplr is the only non-Google property using AuthSub
• Tumblr is the only property using plaintext passwords, although Posterous is using HTTP Basic, which is basically plaintext

Looks like OAuth is gaining some real traction, and in fact if Google switched over to using it, it’d have a real hold on the authentication space. That would probably be a good thing. Next up in my adventure will be seeing how truly conformant/compatible all these OAuth implementations are, and how portable my code be able to be in accessing them all.

If you’d like to add any others that you know about, please throw them in the comments and I’ll add them to the table above so everyone can find them.

I was at BizTechDay on Friday afternoon at the WordPress table, after which Raanan was kind enough to drop me off down in Mountain View at the Wild Palms Hotel, where everyone was staying for the event. That night there was food provided and some drinks, general mingling/networking etc. The next morning we were all shuttled over to the GooglePlex (although I got a ride with the guys from TYPO3, thanks!) where we could grab breakfast, and up to the main room where we started the process of figuring out a schedule for the next day and a half. People suggested topics on large sheets of paper and each mentor had 8 stickers which were used to vote on sessions to indicate their relative popularity, and thus which room they should use.

Once sessions were decided, we scheduled them in on a giant grid which was provided, and then we could break out and start attending sessions which interested us. I tried to go to something in every time slot, and here are a few general notes from the 3 most interesting sessions I attended:

• WordPress has a relatively bad reputation for security, particularly amongst open source folks (who admittedly tend to have a more heavy-handed view of those sorts of things)
• A few people (specifically Jake Applebaum of Tor and Dan Collis-Puro of the Berkman Center for Internet & Society) thought that specifically doing security-only patches for WordPress, and doing them for “old” versions would be a way to increase the number of users who applied them
• Doing security-only patches would also potentially allow us to do fully-automated core updates.
• Getting designers involved in open source projects is really difficult
• Breaking down small, bite-sized projects is a better way to get designers involved (one small module, one form, *something*)
• Designers need to be involved from the ground up where possible. It helps build respect and trust, and it means they understand what they’re designing better, so they avoid coming across as “coming down from on high” with their opinions
• All the major CMSs (WordPress, Drupal, Joomla,TYPO3,  even MediaWiki to an extent) are coalescing around some similar problems/approaches, and are generally becoming application “frameworks” with a “default mode”.
• There is a LOT of potential to pool/combine development skills across these platforms to build common, core libraries (for things like Open ID, OAuth, Feed parsing, etc) where it makes sense
• There’s a lot to be learned from each other, yet we all felt like there was a culture of not wanting to publicly acknowledge/interact with each other for some reason (everyone is a zealot?)
• Below is a photo of the board of notes from a discussion on why the number of women involved in open source projects is so low:

For more detailed notes on all sessions, you can visit the mentor summit wiki.

All in all it was a great event, and I met some really cool people who I hope to maintain some connection with over time. I’m also hoping that perhaps from this we can start some sort of cross-pollination of ideas (and maybe even code) between some of the popular CMSs where it makes sense, and perhaps implement the idea of security-only patches in WordPress. We’ll see what happens.

It’s going to be long, so click through to read the full thing.

General Observations

• Really cool space (exposed brick, raw beams etc)
• Very professional set-up (black table-clothes, speakers, video etc)
• Good food/drink (bacon & egg croissants FTW!)
• Lots of seats, no power
• Secured but accessible wifi, but it’s painfully slow (very corporate controlled, thanks Fox)
• Saw/met dotBen right before we got started.
• Seeing/hearing a lot of people from big players like Google and Yahoo here.

Introductions

We’re getting a bit of background on OpenSocial’s development and organization over the last year. Seeing charts on growth over time, global reach (impressive, lots of international networks/apps implementing it). Some stats

• User Reach = 600,000,000
• 1 in every 2 users has installed an OS app
• 7,500+ apps available already

Now we’re getting some “how it used to be” from someone from hi5. He’s talking about their path to supporting OS. Before = “down in the coal mines”, After = “Borat, I liiiiike!”.

Lane from Google is now talking about the OS Foundation. The Foundation was created so that we could create cool stuff, without worrying about Intellectual Property. Also hearing about the structure of the Foundation and how it helps to ensure everyone’s voice is heard. Making sure we know about the new OS wiki and the IRC room (#opensocial on freenode).

Apache Shindig (Java and PHP only) sounds like a cool tool that speeds up development based on discovering information through your social graph.

Apparently all slides from the presentations today should be on the OS site within a day or 2.

Where Can We Go?

• On and off the web (mobile)
• New Features!
• Make it even easier to make it adopt and build, better interop
• OpenID, oAuth etc being completely standard and “required” for new developments

Ali from XYLabs

Small team from India. Started as 3 devs, 1 designer and a QA intern. They’ve developed a number of social applicattions. Containers = Orkut, hi5, Netwall (?), Friendster and MySpace.

Biggest app is PhotoBuzz, which allows users to “buzz” this contacts with a small “greeting” based on pre-built animations. They are profitable, but are focussing on growth rather than revenue right now. Basically they superimpose their animation over a photo supplied by the user and send it as a “greeting card”.

They built a collection of re-usable libraries, made it possible to drop in analytics engines of their choice to keep track of metrics. Strongly suggests watching your numbers and listening to your users. Adapt quickly.

Viral loops and messaging are the biggest things that differ from container (social network) to container.

150,000 – 200,000 new users per day during “the hockey-stick”. They are now working with things like AppEngine to work around the scaling issues.

They split out their front/back-end and put the backend on AppEngine (python), while the frontend was all PHP-powered, and run off their own servers.

Raymond from RockYou

RockYou is a social applications developer. They develop for all platforms and networks. Their monthly reach is 90,000,000 uniques+ and they have over 80 staff members. 12 billion impressions across their network of apps. RockYou is sponsoring drinks/cocktails at the event.

Mission Statement: Engage the world with social applications.

Apps have been installed over 55,000,000 times across all platforms.

SuperPets is a virtual pet application. Adopt, personalize, accessorize their pets, then engage with their friends through their pet.

They have a new service called RockYouAds which provides advertising across different social networks via their application installations.

Design your UI to support slightly different view sizes across all containers.

Different containers implement certain aspects slightly differently. Especially different user information fields available because of policy/privacy, etc.

Even though Facebook doesn’t support OS, you can encapsulate your app and abstract it out to be ported relatively easily if you think ahead. Generally things run in an IFRAME, so you need to abstract away the server communications parts so that you can make it use either OS or FB-specific processes.

Charles from PixChat

They started out with hi5, then ported out to everywhere. hi5 to MySpace took 90 minutes (!!). Orkut took 60 minutes. Googe AppEngine took 3 hours.

OS != Facebook (but you can make them work together).

Google AppEngine rocks (and will save you a LOT of time).

Use jQuery

Use JSON – it’s standardized and gives you the ability to access your data in all languages.

Build an abstraction toolkit (container differences, view sizes, presence detection, etc)

Use viral channels, measure things (Google Analytics with some custom JS triggers to track events).

Scott (MySpace) and Evan (Google)

Talking about OS 0.9 (what’s coming next). Going through the proposal process and how the community is required to approve/block proposals.

Evan talking about changes in 0.9 that make it much easier to build gadgets etc. Generating HTML on your own server and embedding it back immediately, e.g.

<Content href="http://your.server.com"></content>

OS Templates give you a templating language which will be handled by the container.

Splitting out views for apps so that you don’t have to load everything down initially.

Lunch

Pretty impressive lunch was supplied.

Arne (Google) – OpenSocialDevApp

OpenSocialDevApp is an interesting “sandbox” type application that gives you access to a lot of tools and resources to get started working on a new gadget/widget. Generates all sorts of shortcut code for you, helps manage server requests etc.

Zembly (Sun)

A cloud-based development environment for developing OpenSocial applications. It is a social network in and of itself, but it provides a “Wikipedia of OS apps”. Has code, gadgets etc as starting points/components.

Provides an IDE (in the browser) to speed up the process, and includes automated hosting built right in (1-click). Collaborative development by inviting/allowing other users to participate in your coding environment. Creates a network around programming artifacts (snippets, gadgets etc), and gives you activity streams etc. You can even create an iPhone app within it.

It connects to all sorts of APIs on the web, to give you access to do things like Twitter aggregation.

Casey (iWidgets)

They take existing content from big content providers and put it in the social networks where people already are. They make their money through CPM/CPC advertising embedded in their widgets. Write once, deploy everywhere (Facebook is still a challenge).

Has a basic RSS –> widget wizard. If you can use something like Yahoo Pipes or PowerPoint then you can use their product.

Open Social Client Libraries

New set of code libraries in popular languages to get you coding faster. They provide an interface to container queries, accessing data etc. Simplifies the process and abstracts away as many differences between containers as possible.

Global Container Crawl

Instead of a pub crawl, the plan was to work their way around the globe, coding/deploying apps for containers hosted around the world. There were prizes to be had and other incentives, but I had to head home to take care of some other things and get some juice for my laptop (battery life is pretty lame on the MacBook Pro…)

All in all a pretty good day, and a great introduction for me to OpenSocial. I’m looking forward to hopefully getting a chance to check it out in a bit more detail soon.

Drag it to your bookmark toolbar, then click it, enter a street address (eg. ’2000 Bush St’) and hit ‘Ok’ to get an instant Google Map to that location in San Francisco (my current hometown).

map

Obviously editing this to work for different cities in the US would be trivial – knock yourselves out.

I got my most recent copy of the ‘Google Friends‘ newsletter, and towards the end, completely unrelated to anything else in the newsletter, they offer a definition (sort of) of what a Wiki is. They provide a link to Wikipedia and then leave it at that.

Google have already delved into the world of blogs (they own Blogger.com and run their own GoogleBlog), so I guess it was only a matter of time before they got into wikis as well. I wonder where this is going to go… especially since Yahoo! is already an avid supporter of Wikipedia at least (hosting some of their servers).

This means that you can now download XooMLe and install it on your own PHP-enabled server so that you can use it locally for integrating Google search results (and cache and spelling suggestion power) into your web-based applications.

In the near future, a ‘XooMLe In Action’ page will also be added to the site, showcasing some of the ways that people are making use of XooMLe and Google.

Purely by accident, I opened a Google page with my text size set to ‘largest’ and lo and behold, they have modified their HTML to allow for resizing of fonts. Even their AdWords ads resize according to the browser preference.

Looking at the source, it looks like they are slowly moving towards a CSS-based layout/design, although they still have a ways to go. Incidentally, I did a copy of their layout with CSS for an internal search engine that I built and it wasn’t that hard at all, their design even lends itself to being done with DIVs, UL/LIs and A tags, styled up with CSS.

So here’s their style definition on a results page now-days;

body,td,div,.p,a{font-family:arial,sans-serif }
div,td{color:#000}
.f,.fl:link{color:#6f6f6f}
a:link,.w,a.w:link,.w a:link{color:#00c}
a:visited,.fl:visited{color:#551a8b}
a:active,.fl:active{color:#f00}
.t a:link,.t a:active,.t a:visited,.t{color:#ffffff}
.t{background-color:#3366cc}
.h{color:#3366cc}
.i,.i:link{color:#a90a08}
.a,.a:link{color:#008000}
.z{display:none}
div.n {margin-top: 1ex}
.n a{font-size:10pt; color:#000}
.n .i{font-size:10pt; font-weight:bold}
.q a:visited,.q a:link,.q a:active,.q {color: #00c; text-decoration: none;}
.b{font-size: 12pt; color:#00c; font-weight:bold}
.ch{cursor:pointer;cursor:hand}
.e{margin-top: .75em; margin-bottom: .75em}
.g{margin-top: 1em; margin-bottom: 1em}

As you can see, they are not defining a font size for a lot of their elements, which is a good move, as it will inherit the browser settings automatically. One thing that I did notice is that the fixed-size fonts they are using (“.n a” and “.n .i”) are only applied to the numbers used for the links to different pages of results. I am assuming that they have done this because otherwise there’s the potential that thei cool little string of ‘o’s will be messed up from font sizing

Good Work Google! Good to see more of the big-boys embracing CSS design, I just hope that they continue down this path and have a completely CSS-driven design in the near future, browsers are almost up to speed so that it’s a valid move for them I think.

If this happens, it will probably be a chance for me to clean up the code on the entire project, and then I might also release the code so that you can “install” your own XooMLe server Information will be posted here if that’s the case, and I’ll also post to the XooMLe-News mailing list (sign up on the XooMLe Project Page).

Anyone else hanging out for an even simpler version of the XML results? I am thinking of having something like this;

{sample removed}

Comments? Suggestions? Please use the comments link below (to the right).