I’ll be further exploring the Bookleteer API in a future post. The code for the experiments can be found on the Bookleteer blog.

One of the subjects that came up in my thinking for SXSW, and which I mentioned briefly, was the question of souvenirs. I said then that I don’t think digital does souvenirs—I can’t think of examples of what I consider to be real souvenirs which are not discrete and tangible. And as more of our activity takes place in the realm of the virtual and the digital, there’s a growing disparity between our experience, and our records of that experience.

These records—souvenirs—are important because they serve as touchstones, aides memoires, and visual quantifiers. They remind us of where we’ve been, keep experiences in our minds, enable us to learn from them through reinforcement.

Russell Davies has written about “the way we use these little objects to say stuff about ourselves. And, in saying those things, to understand ourselves.” And in response to a brief on that topic he set last year to the Interaction Design students at the AHO Institute of Design, Svein Inge Bjørkhaug came up with a system of physical blocks that represent your activity online:

[Photo by jørngeorg on Flickr]

Your computer activity is monitored and every week you’re sent a little collection of these blocks. Quite soon, this becomes a very real representation of a virtual activity, and a set of objects to be reckoned with.

I was reminded of this project when thinking through my previous assertion that books are souvenirs of themselves. When people complain that they don’t want to read ebooks, I think a lot of this is due not to the reading experience itself—as everyone discovers eventually, the format disappears when you get stuck into a good story—but due to the other affordances the book offers.

Because the life of a traditional book is not just in the reading of it. It’s more like this:

And there’s a cognitive dissonance going on with ebooks, that they don’t fulfill those other cases, as well as the general problem of the tracelessness of electronic reading.

There’s another intersection here as well: the social timeline of the book—the reviews you read before you buy it and the conversations you have with your friends about it and so on. This line crosses the one above at the point of reading—which is also where Bkkeepr sits.

So it seemed natural to use Bkkeepr as the platform for experimenting with Bookleteer’s API, which allows automated access to its Diffusion eBook and Storycube generators.

For a while I’ve been meaning to add the ability to auto-generate inserts (or perhaps Moo stickers) that put your bkkeepr data back into the real world, and into your books once you’ve finished them:

Bkkeepr is intended to eventually (cough) evolve into a scrobbling-type service not just for the books you read, but for the ebooks you read too. And it makes sense that Bkkeepr should therefore supply you with the souvenirs of this experience too:

These cubes are auto-generated from Bkkeepr data using the Bookleteer Storycube API, currently in private beta. The Storycube API takes a set of images and returns a net in pdf format (there are more pictures of the cubes and the process at Flickr):

They represent a couple of months reading, and while I own physical copies of these titles, the intention is to stand for the ebooks I also consume, but which leave no physical trace on my shelves, and thus too easily slip from memory:

You can see how an avid ebook reader would quickly amass sets of these, which could line up along shelves vacated by the absence of physical books.

I like the bookcubes very much as physical instantiations of a virtual activity. However, as avatars for ebooks, they do strike me as a bit obvious (as well as fiddly). I think it’s probably possible to do better.

Other examples of physical souvenirs, alongside Svein Inge Bjørkhaug’s above, include the Sound Advice project, or RIG’s datadecs. These seem more abstract and less representational than getting stuck in the same book jacket trap all over again. (It still bothers me that we use book covers as the main symbol for books bought online, and even for ebooks.)

I noticed in Apple’s iBooks demo that there’s a progress bar on every page of the book:

Which is good and something I’ve argued for for a while (it’s quite prominent in Enhanced Editions) because a sense of progress is important when you’re reading a long-form piece. And perhaps this approach is applicable to a couple of other bookish problems: how do you represent the book when it doesn’t have a cover and is no longer an advert for itself, and how do you make the invisible value of a book – the time spent on it by writers and editors – visible and thus communicate that value?

Can we include metadata about the creation of the book into the book itself? (And while I’m showing and thinking with paper books and pencils here, I’m talking about ebooks.) Could the book contain the details of how long the author spent working on it, even embed its own, dated changelog?

And we’re getting into the realms of data visualisation here too, like Stefanie Posavec’s visualisations of On The Road: could we use representations not only of the text, but also of the author’s energy, to sell the book—representations which evolve further and merge with the experience of the reader to create souvenirs? Digital abstraction and re-instantiation beats tired physical nostalgia.

That is what I have been thinking about lately. Many thanks to Bookleteer for providing me with the tools to do so. I’ll be exploring their Diffusion eBooks next.

From August 15th, Amazon requires all API requests to be signed, which to the layman means that you need to add a timestamp, and a ‘signature’, which is a hash of the entire request, and your private Amazon key.

There are a bunch of PHP examples for doing this on the web, but because I had to tweak them all slightly to get them to work, I thought I’d put it out there to be helpful – I’ve just implemented this on bkkeepr and Bookseer and a few other places…

<?php

// Build your request string, e.g.
$request = 'Service=AWSECommerceService&'.'AWSAccessKeyId=[YOUR AWS ACCESS KEY]&'.'Timestamp='.gmdate("Y-m-d\TH:i:s\Z").'&Operation=ItemSearch&Title='.$title.'&SearchIndex=Books';

// Encode and sort the request string
$request = str_replace(',','%2C', $request);
$request = str_replace(':','%3A', $request);
$reqarr = explode('&',$request);
sort($reqarr);
$string_to_sign = implode("&", $reqarr);

// Append endpoint
$string_to_sign = "GET\necs.amazonaws.co.uk\n/onca/xml\n".$string_to_sign;

// Create signature hash
$signature = urlencode(base64_encode(hash_hmac("sha256", $string_to_sign, '[YOUR AWS PRIVATE KEY]', True)));

// Append signature to original request
$request .= '&Signature='.$signature;

// Append endpoint to original request
$request = 'http://ecs.amazonaws.co.uk/onca/xml?'.$request;

// Make request
Append signature to original request
$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, $request);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1);
$book_data = curl_exec($curl_handle);
curl_close($curl_handle);
return $book_data;
?>

It’s actually pretty simple when you get your head round it, although Amazon has done an atrocious job of helping people make the change. You need to be quite the developer – or, in my case, read piles of unhelpful documentation and a hell of a lot of helpful blogs – to get your head round it, but I hope that helps someone.

Remember, you can make your own changes to the $request string in the example above – don’t forget the Timestamp, it’s important – and change the endpoint from .co.uk to .com, .fr etc. There’s also a slightly helpful Amazon helper here.

If anyone has questions, I’ll try to help – but not promising anything…

Shared bookmarks are one of the primary drivers of conversation and socialisation on the web. Simple pointers to information are the basic currency of networked communication, and one of the most desirable functions of the future book. But, in the book, they’re pretty hard to achieve.

I’ve hit this problem already on bkkeepr, and that’s just with physical books. If two people are reading the same book in two different editions (hardback or paperback, modern or ancient, even in different translations) then the same text doesn’t occur on the same page. (This is one of the main reasons bkkeepr bases itself on ISBNs rather than titles or “works”, but it’s unwieldy and has been, mostly rightly, criticised.)

The problem gets harder with ebooks. My Sony Reader lets me bookmark pages, but there’s no way to transfer or even translate these to another epub reader, let alone another format or edition. I’ve been lurking on the epub-interop group for a while, which has been considering this issue, as well as things like reliable identifiers for epub books, and just keeping your place in different editions (a subset of the bookmark problem).

So, to first principles: a bookmark is a location, right? But it’s a location in an existing text, and the problem comes down to defining a location in a text that moves about, covers different numbers of pages, appears in different formats. But here’s the rub: it’s always the text. (Well, not exactly, but we’ll come to that later.)

I do something quite similar a lot, when I’ve read a newspaper or journal article offline, and want to find the online version. I just pick a string of words from the text, that feels like it contains a reasonably-unique (don’t pick me up on that, you know what I mean) set of words or phrasing, and google it in quotes. Works a charm.

Going further, it seems likely you can bookmark anything given a string of sufficient length to be unique (I’m getting something in the back of my head about whole files, and the best model of something being itself, but we’ll ignore that).

This is where an idea I’ve been toying with for a while comes in: do we need a Gracenote / MusicBrainz for books? A big database containing everything – or at least some kind of hash of everything, a set of unique signatures for each book? Could you be able to take a string-of-a-certain length from anything, submit it to this DB, and get back a title, like holding your phone to the music with Shazam?

… although I’m realising that Google Book Search is pretty much working on that – and it has an API, so. I might put a wrapper on that. (The geek version of a donk.) Unless someone has already… ? (For more on Google Book Search and unique strings, see Dance of the Concords.)

So if you have a string of sufficient length, you’d get a single result, and be able to find the bookmark in a text, even if you didn’t know what the text was before. That’s quite interesting, and new. I think.

There are serious issues with this approach of course, not least that books are edited and do change more than just their page numbering over the course of time, but some kind of clever, fuzzy search or simple string-lengthening might deal with this. And then there are translations: could you bookmark cross-language in this fashion, given a sufficiently clever translation engine?

Thoughts?

Photo of bookmarks by FlickrJunkie, used under Creative Commons.

The above is a graph of my reading for the last year from bkkeepr, as generated by the first application powered by the bkkeepr API: The Velocity of Reading.

TVR calculates statistics and draws graphs based on your reading habits, counting pages read and hence your average reading speed. All you need is a bkkeepr username (and a few weeks reading under your belt). I’m incredibly pleased to see the API in use, and this is exactly the kind of application I had in mind. A big hand to Tristan Ferne for building it.

With the recent launch of LibraryThing’s Twitter input, I was concerned that people might use this service instead of bkkeepr. However, I think apps like this demonstrate that an internet of small pieces, loosely joined offers far more possibilities than a small number of large, enclosed systems, and I’ll keep working on making bkkeepr better, and more open.

I’m off to India for a couple of weeks: don’t expect too many posts, but I’ll have lots to tell on my return.

No time to write up the excellent experience that was Bookcamp last weekend – keep your eye on the Penguin blog for more reports. There will be more to come.

Very pleased to see Bookkake and bkkeepr (twice) on the map above that’s doing the rounds. 2008 was a good year, and there are many more plans for 2009. See you in February.

It’s rare that I out-and-out praise a service, particularly here, but if you’re running any kind of customer-facing service on the web I can’t recommend Get Satisfaction highly enough. In fact, if you’re not using it, you’re doing it wrong: it’s up there in a select set of absolutely essential tools like Google Analytics, Feedburner and Campaign Monitor (or equivalents, but they’re my picks) that should be set up and running for your project / website / shop before they launch.

Get Satisfaction is “people-powered customer service” that provides a trackable single point of contact, organisation, reference, feedback and ongoing management of customers for your product. It does it in a properly 2.0 way too: it’s free, with email notifications, RSS feeds, transparency and good design.

I’ve been using it from the start for Bookkake (which hasn’t done much, but glad to have it) and more especially for bkkeepr, where it has proved invaluable, particularly as the service is fairly hands-off most of the time. I get notifications of issues before I’ve noticed them, technical advice on upgrades, and even great tips on how to improve the service, some of which I’ve actually implemented. And where I haven’t implemented them, I can explain why, and keep those ideas in an easy-accessible place. This kind of dialogue with your users is pretty much essential.

There are nice extras features too, like monitoring Twitter for you – which you can do with Twitter search as well, but essential for a product like bkkeepr, and a good idea for pretty much any web-based product these days (along with Google Alerts). And the new Feedback tab – which isn’t for everyone, but fits in really well on bkkeepr – is a truly excellent invention, a brilliant execution which keeps users on your site while they give you feedback, and has produced a very noticeable increase in useful contributions from users.

So thanks to all the wonderful bkkeepr users who have contributed via Get Satisfaction. Sorry I haven’t implemented all the ideas, but the feedback has been invaluable, and all ideas are considered. If you have a similar site, or anywhere where users spend more time interacting your site than you do – which is pretty much everyone – you should be using it too.

I’m pleased to tell you that bkkeepr, my project to create a Last.fm-alike for reading (and more besides) now has an API.

An Application Programming Interface (API) is essentially a machine-readable version of an application, and more specifically, the data in contains. bkkeepr is first and foremost an application that does stuff with data, and bkkeepr.com is the human-readable version of that application. What an API does is allow third parties to build small applications, widgets and so on that utilise that data in new and different ways. (This is another post, but I pretty much believe that everything should have an API. And not just everything on the web. E.G.)

bkkeepr is itself built on Twitter‘s API, and uses data from a wide variety of other web services, including LibraryThing, Google, Amazon and others, via their APIs. So opening up bkkeepr’s data in turn is something I’ve intended to do from the beginning.

The bkkeepr API is very basic at the moment, allowing you to do two things: get all of a particular reader’s reading data, and get all the reading data about a particular book. There’s more information about it here.

The most important function of the API, to my mind, is that it gives users control over their own data. It’s not locked up in a database over which they have no control, and they can pull it out and store it elsewhere any time they like. I’ll say that again: it’s their data, not mine, and they should have control.

It also gives people the opportunity to build cool things. Here are some examples, some dull, some fun, that I’ve been thinking about:

• bkkeepr ‘bestsellers’ – hot books, favourite books, the most read. Charts, and suchlike.
• Find a friend – who’s reading similar things? I like this particularly as it would allow you to branch back to Twitter – or any other service – and find new people with similar interests there.
• Better widgets (because frankly, the current bkkeepr badge is pretty basic).
• Reading speed – silly, because I don’t think the speed at which you read means anything, as long as you read at all, but, like Dopplr’s personal velocity, it’s a neat data toy, and could be implemented fairly easily with book page numbers from Amazon’s Associates API.
• Pretty stuff with covers and calendars (in the spirit of the awesome LastGraph).
• I’d love to see booksites implement a ‘who’s reading this now?’ widget, but realistically I think bkkeepr needs a few more users to see that happen…

There are a tonne of possibilities, and I’d love to see people do interesting stuff. bkkeepr currently has just over 500 users – not many, but I’m hoping adding features like the API and its results will draw more in. To those who say that an API is just a way to outsource the development of an application to those with more time on their hands, I say: yes. Yes, it is. Have fun.

Back in February, I sketched out this idea on the back of an envelope. I’m pleased to say it is now a reality.

Bkkeepr allows you to track your reading and make bookmarks via text message and the web. It uses Twitter as it’s source, generating a timeline of everyone’s reading, as well as pages for people, and pages for books. Once added, users can add their books to the LibraryThing account, check library availability, and much more. There are also all the RSS feeds and widgets you’d expect.

I particularly like the bookmarking feature which allows me to remember not only my favourite thoughts and phrases from books, but to see what everyone else thought too. A step towards real social bookmarking, and a help to blogging all dog-eared pages.

Bkkeepr came about initially because I was always forgetting to add my books to LibraryThing, mostly because I wasn’t in front of my computer when I was reading. I can now text bkkeepr when I start and finish a book, and add to LT at my leisure. But the idea behind bkkeepr is something more than this: it is an attempt to provide an API for the physical book, to enable the creation of services around the enjoyment of literature; a Last.fm for books.

Like Last.fm, it is meant to be as simple and unobtrusive as possible, and as open as possible. I intend Bkkeepr to be as much a platform as a website, to enable interesting things with books on the web. As Last.fm has resulted in a range of mashups and services, so I’d like to see Bkkeepr generate charts and graphs of literary opinion and activity, to create a window on the lit zeitgeist. Despite the proliferation of book-related material on the web, the act of reading itself, because of its inherent disconnectedness, has remained almost invisible on the web, leading to a perception of its decline. I hope bkkeepr does something to change this.

For the geeks, there’s a lot more about bkkeepr on this development blog (which I’ll continue to update). I learned PHP to build it, it’s entirely built with open-source components, including the CodeIgniter framework, and uses freely-exchanged data from Amazon Web Services, LibraryThing, WorldCat and others. I’ve learned more about ISBNs than I ever wanted to know, and I hope it holds up.

Bkkeepr is currently ‘sponsored’ by Little, Brown, who I owe a debt of gratitude for taking a gamble on the site. I’m not much of a fan of advertising, but the ongoing hosting and bandwidth of the site need support, a publisher is the right partner, and I hope to continue to find sponsors who are sympathetic to its aims.

Finally, I built bkkeepr because it was a good idea (I think) that needed doing. It didn’t take long, it wasn’t the hardest thing ever, and it didn’t cost anything. I frequently detail on this site the troubles that publishers and the book industry in general are having figuring out what they should be doing on the web. I think that this sort of thing is one area where their energies could be focussed: not trying to compete with Amazon et al on sales or metadata, but providing meaningful services and experiences for book-lovers in the same way they’ve been doing through their content for years.