Tag Archives: jiscri

Image Based Quotes from WriteToReply Using Kwout

One of the things we discussed with respect to embedding WriteToReply/JISCPress quotes in third party applications was whether or not we should support an “imagified” embedding – that is, convert a paragraph to a JPG or PNG image format that can then be easily embedded in the third party site.

The advantage? Even if the third party site disallows script, object or embed tags, it will probably allow img tags…

So for example, extending the range of output formats suggested in Taking the Conversation Elsewhere – Embedded Quotes, we might consider something like an &output=png switch that allows us to construct an image embedding code along the lines of:

<img src=”http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER&amp;output=png” longdesc=”http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER”&gt;

Once again, there’s a trackback issue, although it’s easy enough to wrap the image tag in an appropriate anchor tag:

<a href=”http://docserver.example.com?p=POSTNUMBER&para=PARANUMBER”><img src=”http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER&output=png” longdesc=”http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER”></a&gt;

However, this facility was seen as non-essential, so I looked on the web for a solution – and found it in the form of the kwout API which can be used to generate an image based representation of text found in a specified div tag (by ID) on a given web page, which can then in turn be embedded in an arbitrary web page. Although the image may be hard to read, this can work to our advantage: it might drive traffic back to the site that originated the quote 🙂

The following javascript snippet uses the Kwwout API to generate an image based representation of a single paragraph from a WriteToReply republished document:

javascript:window.location=’http://kwout.com/grab?address=’+encodeURIComponent(“http://writetoreply.org/pluralnews/2009/07/03/section-1-securing-plural-sources-of-news-in-the-nations-locally-and-in-the-regions/&#8221;)+’&block=contentblock_10′

In the API call, “contentblock_10” is the id of the block element to be quoted. Here’s what the kwouted image looks like:

kwouting a paragrpah from writetoreply http://kwout.com/quote/nbj4nife

And here’s the original paragraph on WriteToReply:

http://writetoreply.org/pluralnews/2009/07/03/section-1-securing-plural-sources-of-news-in-the-nations-locally-and-in-the-regions/#10 Writetoreply orginal quote

Note that the link that the kwout script generates is back to the page in the above case, so to link back to the actual paragraph we’d need to specify this in the link:

javascript:window.location=’http://kwout.com/grab?address=’+encodeURIComponent(“http://writetoreply.org/pluralnews/2009/07/03/section-1-securing-plural-sources-of-news-in-the-nations-locally-and-in-the-regions/#10“)+’&block=contentblock_10′

As a step on the road to full integration (a use of the Kwout API which may or may not be in line with the stated terms and conditions? I don’t know, I haven’t read them…!) is this bookmarklet that should let you highlight a paragraph number on a WriteToReply document, and then take you straight to the Kwout embed page for that paragraph:

javascript:(function(){var l=location.href; window.location=’http://kwout.com/grab?address=’+encodeURIComponent(l)+’&block=contentblock_’+window.getSelection();})()

Actually, that looks a little cluttered, and the usability is a little off. So a better solution maybe to suggest that the user clicks on the paragraph link to get the “paragraph in focus page” page, and then click on the following bookmarklet:

javascript:(function(){var l=location.href;l=l.split(‘#’);window.location=’http://kwout.com/grab?address=’+encodeURIComponent(l%5B0%5D)+’&block=contentblock_’+l%5B1%5D;})()

(What this does is pull the paragraph identifier out of the URI and then construct the Kwout API call out of it as a result.)

Or if you want the link to go to the “paragraph in focus” page, rather than the top of the page:

javascript:(function(){var l=location.href;window.location=’http://kwout.com/grab?address=’+encodeURIComponent(l)+’&block=contentblock_’+l.split(‘#&#8217;)[1];})()

(Note that neither of these bookmarklets is ideal – a production stable bookmarklet should be able to cope (or fail gracefully) with the lack of hash separated paragraph identifier in the URI.)

Hmm, maybe we need a “labs” area on WriteToReply where we can collect these micro-utilities?

Advertisements

Taking the Conversation Elsewhere – Embedded Quotes

As part of the JISCPress effort, one of the things we’ve been considering is the granularity of appropriate “consultation elements” or “discussion elements”, those pieces of content that people might actually want to reference, question or chat around as compared to a whole 200 page document, for example.

The page and paragraph levels fall out of the CommentPress theme (and its descendants) quite naturally – WordPress gives us the page level (along with a single item RSS feed at the page level), and the theme gives us URIs at the paragraph level.

(Hmmm… I wonder – would it also be useful to provide a multi-item RSS feed, at the page level, with a separate item for each paragraph on that page? Or do we do that already?!)

In many cases, the paragraph level seems to be the most natural chunk for discussion, particularly in an ongoing conversation about a particular document. So a major question for us is how to put those paragraphs to work?

One of the features that Eddie’s been working on as part of the JISCPress project is the ability to embed paragraphs from a document in third party web page. This feature will allow us to increase the surface area of the document by allowing third parties to re-present that content elsewhere, whilst also (hopefully) providing a means to link that external conversation directly back to the original document.

So what benefits does embedding have to offer to:

a) the person grabbing and using the embed code;
b) the publisher/whoever’s running the consultation from which the embed code was grabbed

In a discussion on the JISCPress group, Joss suggested the following:

For the user:

1. More portable transformation of document content into raw data.
2. Personalisation, presentation and ‘ownership’ of documents within their own publishing environment (which is one of the benefits of slideshare/scribd).
3. Direct joined up quoting rather than copying. More aligned with the ideals of the web and linking data. This could also be a benefit to publishers concerned about unattributed copying.

For the publisher:

1. Greater possibilities of content dissemination
2. Greater potential of attracting engagement via trackbacks
3. Further possibility of using JISCPress as an underlying ‘document store’ where authoring, dissemination and engagement occurs mostly remotely via XML-RPC, syndication, embeds and trackbacks.
4. Possibility of site analytics being hooked into embeds so the reach is measurable???? (Analytics can track document types, I’m not sure whether they are used to track embeds…)

So where are we at? Embedding is currently in testing and has the following mechanic. Hovering your mouse cursor over one of the paragraph numbers in a document raises a floating panel that contains a link to the current paragraph, and an embed code. (The panel remains open whilst the cursor is over it, so you can easily grab a copy of the code.)

Embedding in digress.it

Using the embed code in a third party page embeds the corresponding paragraph in that page.

For testing purposes, the pattern we are using for the embed URL is of the form:

http://docserver.example.com?p=POSTNUMBER&digress-embed=PARANUMBER

The POSTNUMBER identifies the actual page (i.e. http://docserver.example.com?p=POSTNUMBER is a valid page URI) and the PARANUMBER identifies the paragraph to be embedded. Note that this is subject to change.

Unfortunately, the simple embed strategy does not trivially generate a linkback (such as a trackback or pingback) to the original document. For these reverse links to be generated automatically, an actual anchor tag linking back to the original page must be present in the page creating the linkback. One commonly used strategy for achieving this is to provide an embed code of the form:

<div>
<object /&gt
<a>Quoted from etc…</a>
</div>

That is, a link is explicitly included in the embed code, although it is easy enough for the person embedding the quote to strip that anchor tag out.

(Although it complicates matters, as the embedded object is being pulled from the document server, I guess that means we could, in principle, generate a linkback by observing the referrer page URIs for requests made on the server for particular embeddable objects and checking those against the current list of trackbacks? Or maybe the embedded object could generate an XML-RPC back to the trackback server itself whenever the page it is embedded in is loaded? [Note to self: can we easily get analytics on third party embeds?] I think Eddie is working on this, so I won’t embarrass myself further wittering on about things I don’t know anything about!;-)

Note that a similar problem arises when using a Javascript (<script> tag) based embed code: there is no explicit anchor link present. Script tags also have the additional problem that they are often sanitised (i.e. stripped out) of web pages in many institutional web publishing systems. (In some circumstances, a workaround for the institutional case may be possible. For example, if a variant of WTR/JISCPress was running as a white label solution in an institution, a shortcode plugin could be provided that allowed authors to embed paragraphs from documents in that environment within other documents in that environment. See the WordPress shortcode API for more details.)

As well as the straightforward embed code, we’ve also been considering other ways in which paragraph level content can be published so that third parties have convenient access to it in a format that is appropriate for their needs.

And this is what we came up with – an output switch that can be appended to the end of a paragraph URI that allows the paragraph level content to be published in a variety of formats:

  • &output=html
  • &output=rss
  • &output=txt
  • &output=js
  • &output=json

As and when these come on stream, we’ll publish use-case examples for each of them.

If you have any comments on our “paragraph republishing” strategy, please post a comment below.

JISCPress: A document discussion platform for the Higher Education Community

We’re very pleased to announce that JISC have agreed to fund JISCPress, a six-month, £32,500 project led by the University of Lincoln, in partnership with the Open University and based on WriteToReply. JISCPress will provide a scalable community platform for publishing and discussing project calls and final reports, in order to support the grant bidding and project dissemination processes.

As you may know, WriteToReply is run in our spare time – lots of late nights and busy lunchtimes. Since launching the re-publication of the Digital Britain – Interim Report, we’ve been looking for ways to bring benefits from our work on WriteToReply, into the Higher Education community where we work. JISC fund much of the UK development and innovation in the use of ICT in teaching and research and in March, announced their Rapid Innovations funding call.

We quickly re-published the call on WriteToReply to demonstrate the benefits of publishing funding calls in this way and then went on to submit a bid which proposed a community platform for the JISC funding call process, based on our experience of setting up and running WriteToReply. As with WriteToReply, this will be an open, public project and all documentation and code will be available under open licenses.

JISCPress is a platform aimed at people working in UK Higher Education, but the platform itself could be easily adapted for other uses, just as WriteToReply is primarily focused on government consultation documents. The final platform will be available as an Amazon Machine Image so anyone will be able to host their own multi-document discussion platform with all the benefits you see on WriteToReply plus the additional features we’ll be developing throughout this project. We’re already advocating the use the platform in our own universities for the open (and closed) discussion of institutional strategies, for the critique of texts by students and for peer-review of research papers. What might you use it for?

Over on the JISCPress project blog, you’ll find links to a mailing listwiki and code repository. Feel free to join us if this WriteToReply spin-off appeals to you. If you know anyone that might be interested, please do let them know.

You’re probably already aware that WriteToReply uses WordPress Multi-User and CommentPressEddie Tejeda, the developer of CommentPress will be working with us on the project and this will result in significant further development of CommentPress 2. So, if you’re interested in WPMU and CommentPress (as many people are), please consider following, contributing to and testing JISCPress.

We should also note that while the project is a spin-off of our work on WriteToReply, neither Tony or Joss are personally receiving any funds from JISC.  The contributions from JISC to cover our time on this project are paid directly to our employers and does not result in any financial benefit to us or WriteToReply (which is in the process of being formalised as a non-profit business).  In other words, while WriteToReply is a personal project, JISCPress is part of our normal work as employees of our universities (both Tony and I are expected to routinely bid and win project funds – you get used to it after a while!). Money has been allocated to fund dedicated developer time to the project, which will pay Eddie and Alex, a student at the University of Lincoln, for their work as freelancers.

Anyway, on with the project! Here’s the outline from our original bid document:

This project will deliver a demonstrator prototype publishing platform for the JISC funding call and dissemination process. It will seek to show how WordPress Multi-User (WPMU) can be used as an effective document authoring, publishing, discussion and syndication platform for JISC’s funding calls and final project reports, and demonstrate how the cumulative effect of publishing this way will lead to an improved platform for the discovery and dissemination of grant-related information and project outputs. In so doing, we hope to provide a means by which JISC project investigators can more effectively discover, and hence build on, related JISC projects. In general, the project will seek to promote openness and collaboration from the point of bid announcements onwards.

The proposed platform is inspired and informed by WriteToReply, a service developed by the principle project staff (Joss Winn and Tony Hirst) in Spring 2009 which re-publishes consultation documents for public comment and allows anyone to re-publish a document for comment by their target community. In our view, this model of publishing meets many of the intended benefits and deliverables of the Rapid Innovation call and Information Environment Programme. The project will exploit well understood and popular open source technologies to implement an alternative infrastructure that enables new processes of funding-related content creation, improves communication around funding calls and enables web-centric methods of dissemination and content re-use. The platform will be extensible and could therefore be the object of further future development by the HE developer community through the creation of plugins that provide desired functionality in the future.

Subject to user requirements, our planned project deliverables are:

  • A WordPress Multi-User based platform for authoring and publishing JISC funding calls in a form that allows paragraph-level comment and discussion either locally or remotely.
  • A meta-site that aggregates all document data into a single site for search, navigation by categories and tags and can syndicate searches, tags and categories.
  • Develop CommentPress to meet WCAG 2.0 accessibility guidelines, meeting public sector requirements.
  • Evaluation and integration of “related content” utilities to dynamically link related project calls and reports based on content and/or semantic analysis.
  • Evaluation and possible integration of remote, realtime messaging services such as Twitter and XMPP integration.
  • Evaluation and possible integration of enterprise authentication services such as LDAP and Shibboleth.
  • Evaluation and possible integration of OpenCalais, a semantic tagging service.
  • Documentation on how to exploit the benefits of AWS and clone the project instance for other uses.
  • A documented suggested workflow for document authors
  • Documented examples of how to fully exploit the platform for data extraction and syndication.
  • Documented ‘user stories’ for the JISC funding call process.

If this sounds interesting, please do take a look at the full project proposal and join us on the mailing list.