To Link and Link Not

on

Nick Carr wrote a post a couple of days ago about the distracting effects of hypertext anchors when reading text. He referred to the increased cognitive effort that in-line anchors impose on readers, but as Mark Bernstein points out, the cognitive effort article was published in the 1980s, and these claims were not supported in further hypertext research.

Patricia Wright’s work on cognitive prostheses suggests that hiding information behind links made it less likely that people would use that information compared to showing it directly. Her argument (presented as a keynote address at Hypertext ’91) is that the cognitive overhead of link following makes people less likely to follow links, not that the presence of link anchors is distracting. Of course the implication is that the further from their context you move the anchors, the less likely that people will follow them. This is the point that Daniel Tunkelang makes in his response to Nick’s post.

Of course embedded anchors are just one way to manage links to other documents: Nick Carr preferred a “related links” end-notes section (not unlike that found in traditional academic papers). In XLibris, we implemented a dynamic hypertext system that identified promising links based on annotations made on the text and placed them in a “related links” section associated with a document; another possibility is to place anchors in the margin, a document annotation style that goes back to the Talmud.

Since the aspect of hypertext that Nick is objecting to is the interruption of reading, there are ways to manage that as well. Bookmarking is not an effective interface for this purpose, for reasons related to what Patricia Wright reported. Other, lighter-weight techniques, however, can improve this process. Hypertext research literature from ten years ago is full of examples of interesting ways to manage anchor display and link traversal. Unfortunately, ten years of web-based interaction have homogenized that diversity into a rather small set of expected interactions.

Tabbed browsing solves the problem partially, but the number of open tabs can get large, making it harder to find the documents related to your current reading. Another solution, mentioned by JD Thomas in a comment on The Noisy Channel, is to use Javascript to make it possible to defer link-following to a later time without losing track of promising links. This is related to an idea we had for XLibris, which allowed people to mark link anchors with free-form digital ink, thereby making it easier to revisit those promising links later.

A rudimentary JavaScript version is relatively easy to implement; in fact, it works on this page. I cobbled together a short jQuery script that marks up all anchors within the body of this post with extra anchors. Clicking on these added anchors adds the associated links to the “saved links” reading list for the given page. This is just a rough prototype, of course: if you refresh the page, the browsing history will go away, and there is no way to pool links across pages, saved links should contain some textual context from the article, etc. All of these (any many other) features could be implemented simply through a WordPress plug-in. I just wanted to try a quick-and-dirty experiment to see if it works.

Let me know what you think.


2 Comments

  1. Gene, that is exactly what I had in mind! I know this is a rudimentary implementation and as such, its great!

    Off the top of my head there are two other things, that I would do to increase usability and value:

    1. Title the items in the saved links list wiht already present title tag value so “Comment by JD Thomas | The Noisy Channel” would show instead of the anchor text “comment”.

    2. The secondary link denotation. Since this is not a common thing there is no established glygh to indicate this feature. When I read your piece I got all the way to the bottom before I realized what you had done since that particular graphic instinctively (after years of MediaWiki use) think it was just an indicator that it was an off-site link or a way to automatically open the link in a new tab.

    The next step, while harder, would be to get the links list mailed or stored somewhere for retrieval by the reader.

    As a WordPress Plugin it could perhaps be stored in as a comment and then the link to the comment shared via something like the AddThis API so the link would include both the original post and the bookmarked links.

    That could create a lot of clutter of course unless you used a common value in the comment and suppressed them in the normal loop, or even applied them as a comments to a specific (supplementary) post that doesn’t appear in the loop so you could have “Article XYZ” as a post and “Article XYZ – Links” as a post with a category or tag used to filter it out of the normal frontside post loop and archives page.

    If you decide to go the WordPress Plugin route and want testers, I’d be happy to test it for you on a couple Information Today, Inc. blogs.

  2. Thanks for the comments! I like your idea of using the title text for the title!

    Thinking about the WordPress plugin, it worries me a bit to store an unbounded amount of data for readers, which I think I would need to do to make these saved links persistent enough to refer to them with a URL that something like AddThis could use. It might be better to create add-this style links to individual URLs. I am trying to coax javascript to do this.

Comments are closed.