Posts tagged microformats
Why we’re not quite ready for everyone to build their own social networking site
Dec 10th
Whether or not you should build your own social networking site and/or make use of sites like facebook is currently a hot topic within the not-for-profit web developer/consultant world. The launch of sites like Amnesty International’s “unsubscribed”, which bears many hallmarks of a social networking site, combined with growing attention for facebook campaigns and tools like SuperBadger bring the options and potential into clear focus. Elizabeth Dunn’s post last month “social networks, walled gardens, and decision trees” makes a compelling argument that non-profits should be focussing on these questions now even if they’re not key for their current audience: sooner or later they will be and you don’t want to be playing catchup.
There are certainly many advantages to having your own social networking site. A facebook or myspace presence may attract attention, but the data you’ll be able to gather about your supporters and the potential for inserting your own branding are limited. Set up your own social network and you have full flexibility to integrate that data with your supporter databases, and to tune the site to your very specific requirements. But not only are they a significant investment of resources, there’s also a significant cost of time for supporters who will need to sign up for yet another site, identify their friends once again and give their attention to even more online data. Online campaigning’s great strength so far has been its low barrier to entry; for cause-specific social networks to really make sense their barriers need to fall.
That desire is definitely not unique to non-profits. As Brian Suda’s “Portable Social Networks: Take Your Friends With You” highlights, finding ways to let users move their data from site to site is a hot topic across the web development world. Sites like traveller network dopplr have succeeded in part by letting their (so far highly tech savvy) users import data from other social networks such as twitter. The real breakthrough will be when the mass-networks of the moment (as facebook is today) become similarly open. That won’t make it easy, but it will mean that there is suddenly a huge audience who can become fully signed up for your site with just a couple of clicks.
Right now most efforts hinge on a set of emerging standards, two of which will be familiar to anyone who’s been reading this blog for some time but which bear some more attention. There’s plenty of information around the web on these so I’ll just touch on them briefly:
Microformats are a way of taking plain old HTML and, by following some conventions, adding meaning to the content that could be understood by machines. While a human might be able to look at some information and infer that it is describing an event, machines aren’t so good at that, so we need standardised ways to say “this is describing an event, that bit is the date,” or “this link is to the homepage of my brother.” There were already ways to do that, but it involved adding extra things to your website. With microformats, so long as you (or your content management system) follow some simple conventions when creating a page, a machine can get the content out of the page as easily as a human reader can. That lets us identify friends/contact lists in a portable way, among other useful functions.
OpenID is a way to get rid of the frustration of having to create a username and password for every new site you visit. Instead when you visit a new site that you want to sign up for, you enter a URL that is your OpenID and that site will check with a central system (which may require you to log in) whether you do in fact own that OpenID. Rather than having to remember dozens of usernames and passwords, you’ll probably just have to remember one URL, one username, and one password. And because you’re using that same OpenID for lots of sites, when you sign up for a new site you can be identified on others. So if you sign up for a new site I’ve created using the same OpenID you use on livejournal my software can identify you on livejournal and import your posts from there. So there’s less work for you to tell that new site you’re creating a profile on how to find your blog and to import the posts, and an easy way to make your profile active and informative.
OAuth is the newest of the standards and goes hand-in-hand with OpenID. It allows you to grant one web application permission to access certain parts of your data in another application without giving your usernames and passwords all over the places. If you’ve ever used a site that redirected you to flickr to get your permission to do something with your photos, you’ve seen something like it. If OAuth is widely adopted, no longer will you have to give every social networking site your webmail username and password in order to have your address book checked for other users of the site, simply trusting that they won’t abuse it. Instead, it becomes easy to give a one-off permission while keeping your details as secret as they should be.
What these pieces add up to is a significant reduction in the psychological hurdles that might prevent your supporters from joining your new social network. Instead of pouring hours into their friendster profile only to find everyone has moved to myspace, and so not signing up for your site because they’d have to go through the whole process all over again, they can sign up with their OpenID, perhaps grant you a few permissions with OAuth (knowing that they’re not handing over the keys to their email, online photos, or whatever) and be signed up with an already complete profile.
In other words, persuading people to sign up and build their profiles is no longer the issue and you can focus on providing them with compelling reasons to keep coming back.
So if you’re wondering whether now is the time to start building out your campaign’s fancy new social networking site, it just may be, but chances are a few months from now will be a better time. As OpenID and OAuth become better established—and maybe even get adopted by some of the big players—your life is going to be easier and provided you pick web developers who’ve been keeping up you’ll be able to focus on your campaign strategy rather than coaxing visitors to spend another few hours re-entering the same old details.
Versatile RESTful APIs Beyond XML
Mar 14th
An article I wrote has just been published over at InfoQ. It’s called Versatile RESTful APIs Beyond XML and shows how easy it can be to extend Rails’ RESTful behaviour to input and output resources not only as XML but also as JSON and Microformatted HTML.
The article builds on some posts on this blog, such as Intercepting Microformats In Rails Input, but offers a bit more context. The timing of the article fits nicely with a post on the microformats-rest list about Rails, REST and microformats, so hopefully we’ll see more discussion of these concepts over the coming weeks.
Intercepting microformats in rails input
Feb 20th
In Input formats and content types in Rails 1.2 I mentioned a project I’ve been working on that will provide a RESTful service interface which accepts its input in a number of formats, including microformatted HTML.
For certain types of data microformats provide a great way to receive input as they don’t require your clients to learn a new schema to send you data. They can take the same semantically rich HTML they’re displaying on their website and POST it to your endpoint. Or they can use a tool like Ryan King’s hcalendar creator to generate some sample input.
But intercepting and interpreting that data isn’t quite so simple as JSON or XML. Those formats have well defined content types that we can use to identify them, and use the parameter parsers I described in my earlier blog entry. Microformats are HTML and so will come with an HTML content type, just like other forms of input.
It would be nice if there were a simple way (short of running them through a full parser) to identify POSTs whose bodies contain microformats, but so far I haven’t come across one. What we can do is to override rails’ default handlers to parse the raw post data and see if it looks like regular form input. If it doesn’t, we can presume it’s meant to be considered to be microformat data and we can do some parsing using the excellent mofo (on which more, later). My code at present is:
microformat_interceptor = Proc.new do |data| parsed = CGI.parse(data) if parsed.collect { |key, value| key + '=' + value[0] }.first == data { :event => HCalendar.find(:text => data) } else CGIMethods.parse_request_parameters(parsed) end end Mime::FORM = Mime::Type.lookup("application/x-www-form-urlencoded") ActionController::Base.param_parsers[Mime::FORM] = microformat_interceptor ActionController::Base.param_parsers[Mime::HTML] = microformat_interceptor
With that code in environment.rb, a request with hCalendar data in its post body will look to our actions as if it had an HCalendar object in params[:event]. If we extend a few of our event model’s methods, our controller can treat this input just as it would XML or a standard query string.
Obviously this is a work in progress, its output is very simple, and it’s not all that versatile, but so far my tests stand up well, and it makes the code considerably more elegant.
For a little more on microformats and APIs, check out Drew’s “Can Your Website be Your API?” and the REST page on the microformats wiki.
GOOD Magazine
Dec 15th
Yesterday we pushed the button and launched the new version of GOOD Magazine, a site I’ve been working on for the past couple of months along with the folks at Area17. It’s a relatively large Ruby on Rails system built on top of the ORGware system (refitted as an engine) and supported with a caching system built for Madame Figaro.
Most of my work has been under the hood, but where I’ve touched the frontend I’ve tried to make use of microformats and other good practices. We’re providing a range of atom feeds (which will become easier to find over time as we make some refinements) but eventually I hope that we’ll have all listing pages using hAtom so that anything can be a feed.
The project’s been yet another reminder of the importance of a good test suite. Because we’re using an engine most of the test code has been in the form of integration tests (functional tests don’t automatically pick up the code from the engine) but I quickly lost count of the number of bugs that the tests helped me squish quickly, let alone prevented in the first place.
It’s always good when the placeholder content is interesting, and I’ve been enjoying reading the content from the magazine as I’ve worked on the site. Check it out at www.goodmagazine.com. I have to go and push out another update.
Microformats and extensibility
Apr 21st
I’ve been following the chatter over microformats (XFN, xFolk, hCalendar, and their kin) for some time, but having been having a hard time formulating a response to all the discussion. In particular, the discussion over at Ryan’s blog and some postings such as this one by Danny Ayers have triggered further thinking.
The idea of ‘emergent semantics’ is an appealing one, and as many have argued lower-case semantics are far more likely to be adopted by a broad sweep of the web development community in the short-term than are carefully constructed XML vocabularies, or RDF representations of resources. But at the same time I fear that this sort of format will delay adoption of ‘true’ Semantic Web technologies, and balk at the apparent lack of extensibility the microformats offer.
As I work on plans for some future web app development, RDF has become more and more appealing because it is decentralised and allows for the representation of complex relationships between items. If I need to attribute a property that my current vocabulary doesn’t support, there is a standard system of drawing in another namespace which my tools can automatically understand. By contrast, (X)HTML only allows for rudimentary relationships, and there is no standardised way of indicating within the document which vocabularies tools should expect.
That’s not to say that microformats aren’t useful. Now that we have a large community of developers building standards-compliant sites it makes sense to work towards standardised class names for certain page elements and types of content. Having developed a number of screen-scrapers (and suffered the pain when a non-standards redesign then obliterates all that work), I’d love to be rid of the need to re-code whenever a manager decides a layout needs a slight change. But it will be to the benefit of all of us if we ensure that that standardisation doesn’t distract us from improving tools for generating and interpreting RDF, simplifying content-negotiation options, and otherwise making the web more interoperable.