RSS

booktwo.org

Archives (bkkeepr)

11/08/09: Amazon API Changes, Bookdata, PHP (Sorry)

Warning: deeply dull post ahead. But, we’ve had a lot of discussion about bookdata, APIs, and Amazon on this blog, so it would be remiss of me not to post this.

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…

08/04/09: Inter-operative bookmarking; Gracenote for books.

bookmarks

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.

11/02/09: The Velocity of Reading (powered by bkkeepr)

velocity

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.

20/01/09: Away

map

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.

06/01/09: Get Satisfaction

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.

24/10/08: The bkkeepr API

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.

22/05/08: Introducing Bkkeepr

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.



Switch to Regular Style
James Bridle
booktwo.org
james@booktwo.org