Tag Archives: Technology/Internet

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.