Wednesday, August 17, 2005

Revisiting the Skeletal Web (or Widgets aren't Toolbars)

This recent Science Library Pad post on rethink[ing] your model of the net: data + protocol + interface reminded me of a previous doodle on the skeletal web and got me thinking about the various ways to use Konfabulator style widgets.

Richard (Akerman)'s thesis is that web (service) publishers should be providing "primarily DATA and PROTOCOLS to your users, not interfaces. Let them build their own interfaces to suit their needs." and I quite agree.

The recent hive of activity surrounding BBC RSS feeds (or should that be web feeds?) encouraged by the launch several weeks ago of BBC Backstage has shown how creative people can be with reusable content.

And the upsurge in interest surrounding Konfabulator widgets has opened up the possibility of webscripting on the desktop.

However, I think the call to embrace a view of the net as "data + protocol + interface" is in danger of hiding a pretty major (though unnecessary) assumption - in particular: "data + protocol + browser based interface".

Why do I think this? Let me refer you to another Science Library Pad post, this time CISTI becomes Konfabulous - Search Widget, which describes a search widget for the CISTI catalogue that also allows you to check what you have out on loan.

Now this got me excited, because I've been meaning to build just such a search widget for the Open University Library catalogue and I thought I'd be able to repurpose the CISTI one...

...but it turns out that the widget, along with most of the other search widgets in the Konfabulator gallery, is just a desktop search box. Enter a search term, hit return, and your browser will fire up and take you to the search results page.

Now to me, that's pretty much the same as moving a browser toolbar onto the desktop, and using it to trigger various actions within the main browser window.

There are usability advantages to this, I guess - the widget takes up less screen real estate, so I'm perhaps more likely to have this widget open and ready for use than a browser window. But still, the browser is invoked to display the results.

Now, what I had in mind for my library widget was something that would be self contained and display my library record, and perhaps the top search results froma catalogue query, in the widget itself.

This needn't take a lot of work, and here's why:

1) There are more than a few RSS reader widgets out there (e.g. I've blogged about how to use the MultiNewsReader widget in a distance education setting for delivering news items here and here) that can be used to display live RSS feeds.

2) An increasing number of search engines provide an RSS feed (Google entered the fray not too long ago, of course, but let's not forget all the engine's that support A9's OpenSearch RSS format).

Putting the two together, and the implementation path is straightforward enough. However, the widget is only likely to be useful if it only has to display a limited number of search results, each of which must contain enough information to be useful (for example, a dictionary definition, a list of library books on loan, or a search of new library books in a particular topic area).

I was going to pop an image here showing an example of what an OpenSearch result looks like in the RSS reader widget (see the post mentioned in the PS below for an example query) but I can;t get image uploads to work properly in Blogger, so you'll have to do without :-(just use the query as an RSS feed address in the reader).

PS I've blogged before about Using RSS for Data Interrogation, and mentioned there the surprising lack of interest regarding Firefox extensions that exploit OpenSearch. It would be a shame if there were similar disinterest for novel OpenSearch mash-ups in the widget building community...

2 Comments:

Blogger rakerman said...

Oh, I agree absolutely, we would like to do a search in the widget and have the search results come up in the widget. However, both time and technology contraints prevented us from doing that in this version. Exactly as you described, it told us we need to find ways to get results in a better format (XML, RSS, etc.) from the catalogue, so that those results can then be poured into a display of our choosing e.g. a widget result box.

3:45 PM  
Blogger Stephen said...

Totally.

XML, SOAP, RSS... the technologies are on the branch and ripening. I think that the capabilities of these data and transport protocols will soon be demonstrable in widget-esque applications, and really show the ability of bringing the library to the user's space, as opposed to having the user fit the libraries paradigm.

I'm hoping that, if indeed the desktop space war is staring with the recent release of Google search/sidebar, more of these desktop application platforms will enable web service (and other) api's.

4:00 AM  

Post a Comment

<< Home