Stephen Downes’ OLDaily post about MyGlu got me thinking. (OLDaily 9 January 2006). Stephen repurposed elements of his own EduRSS codebase to enable other users to build a rss aggregator in their own sites. Great concept and a generous contribution which has stimulated me to make my own donation; but it was when trying out MyGlu prototype that I found myself exercised by how we can move this stuff beyond the bailiwick of web/blog/geek masters. So the first part of my posting considers my alternative approach to RSS aggregation (pseduo-aggregation really) and the second goes part on to consider some of the approaches to making this sort of syndication functionality more usable.
[b]Part 1[/b]
Since the inception of Auricle I’ve had what Stephen entitled a ‘nifty RSS Dispenser’ which enables readers to select RSS feeds from a list which I select. Now while I quite like the concept of aggregating RSS feeds I was also keen to avoid visual and cognitive overload where multiple inputs to a site overwhelm the user with choice. So I opted for my drop down menu solution where the user chooses which syndicated feed to view (if any). If you’re not familiar with it then scroll down to the bottom of this Auricle home page. But while I give the user some choice they only get to view the feeds I choose and so, prompted by Stephen’s MyGlu post, I’ve decided to do something about this.
So following on from Stephen’s example I would like to offer the full commented php scripts which drive my RSS dispenser to anyone else who’s interested on a Creative Commons attribution and share-alike basis. You’ll find the code scripts at my Bath download site. There are two files. First up is ‘rssmenu.txt’ followed by the ‘UseMagpie.txt’. Download these files and change their suffixes from .txt to .php. Read rssmenu.php before UseMenu.php.
[b]Part 2[/b]
But all of the above is likely to fly over the heads of those who don’t script or code and who will consider ‘perl’ a misspelling of what you find in an oyster and ‘php’ a new designer recreational drug. That’s why services like SuprGlu exist; they shield the user from the nasty technology creative bits and let them get on consuming what interests them. The trade off is a dependency on a service that may eventually disappear and which lies outside of the house-style and furniture of the user’s site.
It would be possible, however, to increase usability and uptake of solutions like Stephen’s MyGlu and my RSSdispenser if they were designed to be functional components of a host system with a modular architecture and which already offers basic RSS management functionality.
For example, I’ve been looking with some interest at WordPress as a host architecture which, since version 1.5, has integrated the Magpie RSS functionality, although remarkably little has been written about this. This is important because this saves a whole lot of new coding effort to write yet another RSS parser when there’s quite a lot of offerings already out there. If WordPress users don’t like the integral Magpie RSS support then it’s fairly easy to introduce alternatives. I’ve used Geckotribe’s GPL version of CARP as just such an alternative and found it easy to install and use. Geckotribe seems to specialize in all things RSS and also offers other pay-for and free enhancements like Grouper and Moray, with the latter apparently offering filter, reaggregate, and republish in much the same vein as Stephen’s MyGlu.
What often isn’t considered by those writing RSS parsers is that they may have to work through institutional firewalls and lack of this functionality may make existing offerings a non-starter. A plus point for CARP is that Geckotribe responded very quickly to my criticism of their original product and so now has proxy functionality built in. I’m not sure if the version of Magpie built into WordPress 2.0 has proxy capability.
Nevertheless, theoretically, it should be possible to develop an RSSdispenser type plugin for WordPress and, if you are so inclined, please feel free to do so. As regards MyGlu or SuprGlu type functionality, WordPress already offers a significant number of syndication plugins but, I haven’t had time to judge whether they all support proxy functionality (I suspect not). One of the most interesting is the BDP RSS Aggregator plugin which certainly seems to have the right combination of usability and power. This plug-in has a good high level interface which makes aggregating feeds a breeze.
But, of course, nothing is for nothing. Such plugins offer usability but at a cost in the form of ‘lock-in’ to a particular platform; albeit in our case, open source lock-in.
The WordPress plugin would only work in WordPress. It won’t work in, say, Moodle which would need it’s own plugin. It certainly won’t work as a Blackboard Building Block so more custom engineering effort would be required if such functionality was required there. And if these other platforms lacked basic RSS management then that would have to be created first.
Perhaps we need a plugin specification and standard? 🙂
But despite the usability benefits of plugins such as those available for WordPress it’s only those with administrator rights who get to specify the list of rss feeds. So how do we overcome this constraint?
The answer of course is that each user has their personal blog for which they are the administrator and so their feeds become syndicated inputs for others. They don’t even need to be using the same blog system although putting effort into plug-in development/utilization now begins to make a lot of sense because it’s now that the usability benefits will stimulate use, i.e. filling in the details on a Web form beats php, cgi, or even OPML scripting and configuration hands down.
It begins to sound like a personal learning environment in the making 🙂
