Pipes vs HyperCard and the demise of interactive content

I’ve recently enjoyed a brief exchange with Scott Wilson on a CETIS after he asked "is Pipes the new HyperCard". I felt I had to comment, not least because it was with HyperCard that I first learnt how develop interactive content, so I felt I understood a little about just how revolutionary that application was. Those who know me will also attest that I am very enthusiastic about content syndication using RSS, so I also get where Scott’s coming from stating the significance of Yahoo Pipes (though perhaps not everyone is quite so enthusiastic). The discussion quickly went beyond Pipes being an interesting service to being more about interactive content, interactive multimedia, call it what you will, being supplanted, or not, by YouTube and it’s ilk. I personally think this is a far more interesting topic.

Anyway, Scott’s posted some of the exchange on his weblog but he doesn’t allow comments so in the spirit of the two-way web I’ve posted some more by way of a reply. I’ve edited a little but you can always visit the list archive for the full text of all the discussion.


"I’d like to challenge Scott on his Pipers/HyperCard comparison. At best Pipes might do the metaphorical equivalent of linking different stacks or possibly cards of content but not much more. HyperCard was revolutionary because it allowed non-programers to develop interactive multimedia content. When content moved off the desktop onto the web, HTML took over and for a while it was easy-ish for anyone to create content but then increasingly complex tools such as Flash became the interactive multimedia development platform of choice and a new generation of content developers were born leaving a gap in the market for easy non-technical content generation. Then along came content publishing systems (in the context of teaching & learning) such as VLEs, blogs and wikis and content was easy to make again, but the nature of the interaction has shifted from humans interacting with content to humans interacting with other humans. It would be nice to see another accessible tool, the 21st Century equivalent of HyperCard perhaps, for the development of interactive web-based content. But it’s not Pipes."


"My counter-argument isn’t about whether things like Pipes and HyperCard directly compare in terms of function, for the reasons David points out. However I think there can be a comparison in terms of role and purpose, because the nature of content itself is changing. HyperCard, Flash, and the like are indeed tools of interactive media. However, interactive multimedia is no longer in fashion (who needs a "next page" button in a piece of content when we have ubiquitous hypertext? Why embed the movie in Flash when I can just link to YouTube?)"

"Instead we have entered an era of connected media. Connected media does not contain interaction; instead content items are nodes in a network of connections that are the focus of interaction. The content is inside-out. The hot content today is not interactive – Flickr/Photobucket, YouTube, iTunes, RSS feeds all feature non-interactive content, yet the content is highly connected via layers of interlinked metadata (del.icio.us, technorati, recommendations, hyperlinks, comments…)"


"So, my thesis is that Pipes-like tools (I don’t think Pipes is it, but one will come…) are to wrangling with connected media what HyperCard was to developing interactive media – an easy to use tool that lowers the barriers for all kinds of users."


"Hmm. I think I’d have to disagree with the suggestion that interactive multimedia is no longer in fashion. If nothing else witness the phenomenal growth of Flash, but there is of course much more than just Flash-based content that’s rich and interactive. I’d even suggest that there’s more interactive multimedia available now than at any previous time and similarly probably more multimedia developers (or instructional designers if you prefer) in employment. But this isn’t surprising because the scale of the endeavor is greater. It’s a bit like saying the web is popular because there are now more web sites than there once were."

"However, I do think that the interactive media we now have is (generally) not the same as the hard-coded CDROM-bound multimedia on the 90’s that you either loved or hated. Inevitably we’ve ‘Ave moved on a long way from closed publishing systems towards more open formats with content more easily aggregated using just the kinds of systems Scott is a strong advocate for, and that few would disagree with. This is also not surprising because technology advances at an ever-increasing pace along with what we can do with that technology."

"There’s no question that a deluge of user-created content is transforming the way people consume and distribute content. And new ways of allowing people to interact online are challenging some of our thoughts about activities such as education."

"It’s all good. Buts it’s not all one thing or another thing, it’s not all about connected media just as it’s not all social interaction and it’s not all about interactive media. I naturally resist the thesis that the web is this or it’s that, it’s everything (or has the potential to be) to everyone, it just depends what you’re taking from it."


"So I’ll agree with Scott. The new aggregation technologies offer almost unimagined potential for finding your own trails of information. These are as innovative in their way as HyperCard was in its way. If this is the era of connected media (I don’t share that view as my experience is it can be very difficult to connect media right now – because when people say that they’re often selective in the media they choose to connect – rather it’s people that are better connected at present though even that is pushing it) then very soon we’ll move into the era of interactive connected media 🙂 […] "

I hope this thread develops further because it has helped me think more about how much of the YouTube, Flickr, etc, so-called web 2.0 content complements, but is neither the same as or a replacement for, interactive instructional content. It’s just different, and we need both. And I think web 2.0 will get a lot more interactive content soon enough.

Could Yahoo Pipes make repository interoperability obsolete?

Being able to search aggregated RSS feeds is nothing new, but the combination and filter functions offered by Yahoo Pipes is. One obvious early use of this technology is repository searching. Although some but by no means all repositories allow you to subscribe to search results as RSS feeds, the ability to search across multiple repositories in this way could offer considerable benefits. It’ll be interesting to see if this simple front-end approach overtakes repository back-end interoperability.

I’ve created a few example Pipes to try this service out. In the UK the HE community has a national repository called JORUM. Unfortunately, though understandably, you need to sign-in via Athens to access this so apologies for those who can’t access this resource.

JORUM repository search – selected sub-set of MeSH

Aggregated repository search

The first Pipe searches a sub-set of the JORUM repository, the second searches an aggregate of JORUM and another UK repository, Intute, (formerly the Resource Discovery Network).

For all you non-Brits out there unable to log into JORUM, here’s a Pipe for you:

Aggregated public health repository search

Because users can make these kinds of custom searches very easily for themselves it is going to ask some important questions of repository providers. Do you open up your repository systems to allow for user-defined RSS-based search applications? Or do you close these interfaces down because of unforseen use of content stored within? If you were a user, would you look elsewhere if a repository didn’t allow you to access its contents using RSS?

RSS as commodity

Now I want to share these RSS feeds. So I send you my feed on RSS resources […] You receive it, like it, but want to add some of your own links and re-annotate some of mine. By doing so you then make a new feed that can be shared back with me or with a 3rd party and so on. The RSS feed becomes a commodity.

As I wrote in 2003 now looks possible with Yahoo Pipes. In case you haven’t seen the service, Yahoo Pipes allows you to aggregate, filter, combine, and republish RSS feeds. You subscribe to a number of feeds and filter them all for your favourite subject then republish a new feed containing just those items. It’s a copyright nightmare of course but ‘meh’, in a web 2.0 world where user-generated content was made for sharing, we need services like this to find new ways of adding value to content. Once again the web challenges traditional publishers of content to adapt, and the best of them surely will.

What interests me most about this service and those that will inevitably follow is the ability to create a semi-permanent record of a variety of information sources and publish this as a trail that others can follow. At present, RSS is transient. It presents a moving window of time, a snapshot of the blogosphere for example with items that quickly get replaced as new items are added. Take your favourite weblog for instance. You’ve probably subscribed to its RSS feed in your aggregator. What you’ll likely have therefore is the most recent 10 or 20 posts. The rest, the older posts, are history and no longer show up in the feed. Now that’s not a problem to most people, largely because of the ephemeral nature of weblogs. But my point is that RSS could give us so much more.

Suppose I’m interested in a health topic. I could search a database of published literature to find the latest evidence for a new treatment, and if I’m lucky I can save that search as an RSS feed (although every time new evidence is published in this topic the new data will push the old data out of the feed). I can also subscribe to a variety of other information sources on the same topic. I can aggregate for myself at least some of the information I’m looking for. It is not so easy though to then pass this information on to you, and certainly not in a way that you can add value to and pass it on to others. I think this is where Yahoo Pipes, and future similar services with a slightly more intuitive interface fit in.

One final example. Suppose I’m learning about a topic as part of a course, or maybe I’m the teacher. I find some great resources scattered across a number of RSS feeds, plus many resources that aren’t yet in a feed (because sadly most academic sources of content such as libraries and repositories are slow to pick up on RSS). Add to this some resources that I might have created for myself. What I’d really like to do is to share my resources as a trail of content links for my fellow learners. This is a great application for RSS. It’s important to recognize that this isn’t the same as blogging about them and having people subscribe to my blog’s RSS feed. Not the same at all. I believe we’ve only just started to see the usefulness of RSS, and Yahoo Pipes is one of the first services to show us new uses.

Getting the URL of an email message in mail.app using AppleScript

I’ll not tell you how much time I’ve wasted trying to find a way of using AppleScript to generate a link (file path or URL) to an individual email message in Mail.app. There are a number of solutions on the web but most involve invoking a shell script to run a Spotlight query from the command line. Clever but cumbersome.

There is an easier way providing you use the MailTags extension to Mail.app in combination with AppleScript.

The message id of an email message can be combined with the ‘message://’ protocol to specify a URL for individual email messages. The simple AppleScript snippet below shows you how to easily get the message id for a selected email message in Mail.app. You can then use this URL in your own applications. For example, embed a link to an email message in an iCal event or todo, or even use the URL in web-based applications. I’ve used message URLs to link email messages to actions in my custom-built PHP-based GTD system. Nice.

Copy/paste the following AppleScript into Script Editor. Then run Mail.app, select an email message then run the script. Adapt the script for your own purposes.

tell application "Mail"
set theSelectedMessages to selection
set the selected_message to item 1 ¬
of the theSelectedMessages
set message_id to the message id of the selected_message
end tell
set message_url to "message://" & message_id
open location message_url

This trick only works if you use Mail.app because of the reliance on MailTags. Without it you can use AppleScript to get message ids but MailTags is required to have Mail.app open message URLs. If you use Mail.app anyway then MailTags is a highly useful extension and well worth getting.