Blog

Glassboard and Social Sites

NewsGator has announced that they have integrated Glassboard into their Social Sites enterprise collaboration suite (full disclosure, Sepia Labs is a spin-off of NewsGator). Social Sites customers will soon be able to create boards and share with people inside and outside their organization, using Glassboard’s full suite of rich clients for iPhone, Android, Windows Phone 7, or directly through Social Sites. NewsGator has more detail available here. Our friends over at CMSWire and ReadWriteMobile also covered the announcement here and here.

We’re really excited about this integration, Social Sites has 3 million paid users in the world’s largest organizations such as Accenture, Kraft Foods, Merck and others, and if there’s ever a group who appreciates the work we’ve done to ensure privacy in Glassboard – this group is it!

We’ve been able to play around with the integration, its very slick and NewsGator has done a great job making the experience seamless in Social Sites.

Building the Glassboard API

We here at Sepia Labs love 37signals!  Their company blog is always a great read.  Yesterday they wrote a post entitled “API design for humans“.  Go read it.  Now.  Really.

OK.

Being admirers of their work, I was pretty excited to see how the API we designed for Glassboard measured up to their standards.  By the end of the article I was blown away!  I joked that the writer must have been sitting in the 360iDev Session we did.

The Glassboard API hit pretty much every point (we’re a bit weak on documentation but we’re a private API).

The last point he makes in the post was more or less what I learned the hard way over the last 9 months as we’ve built Glassboard.  It’s what inspired our 360iDev session.

“Use abstraction where it’s helpful.”

I envisioned the Glassboard API as a system of small 1-1 lightweight calls that mimicked the object types on the server side.  If a “Status” had “Likes” then it should be a separate GET on Status/{id}/Likes to get them.

This quickly fell apart as the client developers started using the API to build real world apps.  It was too slow and impractical.

We were expecting a mobile device with limited bandwidth, let alone memory and computing resources, to piece back together a puzzle we already had in one piece on the server.  It made no sense.

It’s the wrong way to design a Web Service API.  I did it.  Learn from my fail.

“If you think there’s some common action that people will go to the API for, you should make that action easy, even if it means compromising on ideology.”

Luckily we’re a team that’s been working on client and server API’s together for half a decade, so we reached this exact conclusion and changed directions.  It took re-architecting our Azure Table Storage to get the right performance, but once we had it implemented we were all taken aback by how much more responsive and useful the entire system became.

Instead of a series of calls to get the basic info the app needed to be useful at launch, we combined those all into one, gave it a new URI that meant something (/newsfeed) and told the clients to GET that at startup.  It gave us a new view of (and in) the apps.

His last sentence is the best advice I could ever give someone building an API, so I’ll end this post the same…

“Maybe try building something small using your own API – it can be an eye opening experience.”