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...

Thursday, August 11, 2005

Easy Peasy Google Maps Labels

This is has been blogged around to death recently*, which is why I decided not to post anything, becuase it wouldn't be adding anything anything new...

But here it is anyway: want to add your own text to a Google map label? simple add +(Your text in brackets) to the search term, like this: This is where I work...

So - how to make this post a little different? Err - how about this: I'm not really into using FOAF, but it would be handy if there was somewhere I could made particular, specific contact details avaliable. Like or, for example... They come as RSS, too, of course:

I'm not sure if supports unshareable tags yet? That is, I don't really want to be able to look at the personal/homepage tag for every user at the same time - I just want to look up that particular profile item for a single user at a time.

Addendum - not done to death it seems...funny how coming to a backlog of a few days news mucks up your perception of what's happening in the blogosphere. Whay seems to have happened is that in a marathon catch-up news reading session I'd read three posts in quick succession on the topic (two of which were trackbacks to Paul Miller's original post on A ridiculously easy way to add arbitrary text to Google Maps) and not paid attention to the common root (which I then unconsciously ripped off in the title of this post...).
So - not done to death, just a really neat discovery in one of Paul's last few posts, I guess, to the Common Information Environment blog.

Tuesday, August 09, 2005

Autodiscovering OpenURLs

OpenURL defines a URL syntax using the HTTP GET request format that allows users to pass bibliographic information to an OpenURL resolver and retrieve a published article. (See also
this article on OpenURL in scholarly environments).

There have recently been all manner of postings in the blogosphere about COinS (ContextObjects in Spans), which seeks to embed OpenURL data in a <span> statement to support straightforward OpenURL Autodiscovery, such as autodiscovery via a bookmarklet.

I like this idea - almost a lot - but can't help feeling a true microformat approach would offer more potential (similarly for Dublin Core).

Just in passing, this conversation appears to offer a history of COinS, and this early post sought a way of embedding OpenURL info in Dublin Core metadata.