15th March 2009

SXSW - Second Day round up

After hurriedly writing my round up of Day One we missed breakfast and grabbed a cab to rush in to our first talk of the day.

How not to fail at Web Services

Without realising it (perhaps I should have read the description more) I walked into another REST discussion (after seeing a similar talk at DevDevDev last year). However it was an interesting talk marred only by a slightly incessantly nit-picking Q&A. At least this time there was less constant direct referencing to Roy Fieldings dissertation.

Gregg started by discussing other API possibilities such as SOAP before turning his attention to REST. Essentially what we're talking about here is making full and correct use of the HTTP verbs i.e:

Get = Show
Post = Create
Put = Update
Delete = Delete

So that we can address the REST requirements of:

Resources (nouns)
Uniquely Addressable Resources
Standard methods of interaction
Stateless

A counter to something I'd often seen/considered using, was put forward. In that, uris such as user/create/ should not exist as the verb is being used as part of the resource locator.

This strict use of the four HTTP methods however does sometimes lead to the need to break down and analyse your RPCs i.e. play_game could be considered as a new verb (play) but could also be seen as 'create', and therefore post, as you are creating an instance of a game.

The latter half of the talk consisted of naming and shaming big name apis (YouTube gets REST, Flickr Doesn't, Myspace does, Amazon simple DB doesn't, eBay doesn't, Rails 2.0 does, Google does etc.) followed by an interesting screencast of Ruby on Rails 2.0 making the appropriate REST Verb Calls (although through the browser only get and post are used - with method type parameters)

The key thing to take away from this talk however was the discussion of the future (and essentially - 'why REST'). The Open Stack made up part of this discussion, with the idea that Open Social, and more generally REST, could allow a standardisation of interaction between consumers and services whereby code is written once; To take advantage of the Open Social standard interfaces allowing the consumer to use the same code across all open social compatible services.

Microformats: Quiet Revolution

I always love to hear about Microformats and some of the stuff discussed in this talk was really exciting... if a little scary. I took note that Tantek regularly made clear that the information being displayed/parsed/used by Microformats consumers was public information. However, even so, it felt a little scary to realise how easy it is to pull together someones entire online identity by scraping/parsing Microformats enabled sites.

An impressive demo of HuffDuffer by Jeremy Keith started us off. I urge you to try it out. After sign-up Jeremy makes use of the Google Social Graph API, and therefore any rel="me" XFN Microformats on your provided homepage, to build up a list of 'elsewhere' sites. In addition he even pulls in a relevant avatar from a provided hcard.

After updating my 'Me' link on my homepage to include the rel="me" (I already had rel="me" links on my about page but nothing on my homepage to refer to it) I was able to see my own results. It included a link to my flickr and twitter as well as my twitter avatar being used.

Slightly scary stuff, but both a wake up call to users about exactly how much you are putting online and a contrast to the Open Social discussions that had taken place in the REST talk. Where Open Social relies on services using standard APIs to allow cross service 'write once' code the Google Social Graph works totally from the client side output that is found across the web.

It wouldn't be a Microformats talk if the excellent Operator plugin wasn't mentionned but some people may be unaware of the plugin available for IE. It's called Oomph, but in my view the most useful aspect of this is that the jquery behind it is also available directly. This allows a site to use microformats and add value themselves (by including the javascript to output the Microformats widget). Providing a good way of showing a return on the time investment. Rather than having to say things like 'users may have a plugin' or 'other services may utilise it'.

Example required javascript below:

                    <script type="text/javascript" src="https://visitmix.com/labs/oomph/1.0/Client/jquery-1.2.6.min.js"></script>
                    <script type="text/javascript" src="https://visitmix.com/labs/oomph/1.0/Client/oomph.min.js"></script>

fig. 1.0

As if that wasn't enough Glenn Jones had to trump it all with an intriguing set of demos. Of particular interest is the Identify plugin that pulls out and neatly displays virtually all Social Graph information in a lightbox. If any of this excites you be sure to also check out the Social Graph Explorer

In short people who aren't using Microformats should be. There is no excuse, particularly with new projects. Often the areas that require Microformat classes will require classes for styling anyway. Instead of making up your own, use the Microformats ones and add value. There have been some accessibility issues and these were discussed, for example with dates using the abbr element. Possible fixes include separating the date and time elements or storing the 'title' info in a span that is styled away. It is good to see such issues are being addressed.

Further Links

HKit: A PHP Microformats Parser

Trade Show

To kill some time and get away from rigidly sitting listening we paid a visit to the trade show whereby we were immediately dissed for being .net developers by a Ruby based CMS producer before being subsequently let down by a WPF demo (by an AMD guy) complaining about the heat of his PC in a cabinet. Enough said...

Web Typography

Unfortunately I didn't keep any notes on this (or I did, and they've got awol). However in general what we were discussing was:

@font-face
Legal issues surrounding font ownership/licensing/usage
Microsoft's EOT, everyone else's OTF font embedding support

To recap over the legal issues; essentially if you provide a font for embedding on a website you are possibly opening it up for free download to any user of the site. This is why many font producers have difficulty with the idea of @font-face embedded fonts.

There are things you can do as a website owner (such as .htaccess protecting direct download of the font etc) however a determined user will be able to retrieve it. The question is, if you take reasonable action, have you done enough in the eyes of font usage licenses (some of which currently flat out prohibit online usage)?

Internet Explorer has taken one view of this problem and supports EOT's (kind of 'DRM'd fonts with only particular characters included). However this is not a perfectly secure solution and is not cross browser.

It was interesting to note that although the panel spoke about the abilities you would have with embedded fonts they also noted that there is a lot that can be done with typography online even now, with attention to detail and fine tuned usage of the standard 'web fonts' that we know so well.

Additionally, apparently Jeremy Keith caused a stir in the browser wars panel by asking "Does the panel believe that it's the job a browser to uphold existing or outdated business models or should it remain true to the vision of the twenty year old web and just render the damn content it's given?"

Boagworld: Live Spectacular!

An excellent panel with actual disagreement and debate rather than feeling like a staged group presentation. The questions covered IE6 support, use of JS and CSS frameworks, wireframing, and business anecdotes

It can be downloaded here