You can do most of these things via existing platforms; Goodreads being the canonical example. You can track your reading, write reviews, join reading groups, and browse curated book lists. But like all private, walled gardens, it comes with a few predictable catches:
- Your library data belongs to Goodreads and you'll have trouble ever getting it out again. If Goodreads goes down, it'll take all your books, groups, and connections with it.
- You have no power or agency as a user to adapt or extend the Goodreads system to fit your own needs. You have to accept and use whatever features and affordances the product managers, designers, and developers of Goodreads deem important.
This doesn't make Goodreads evil. It makes it unappealing for people who care about long-term resiliency, open data on the web, and end-users having agency over their tools.
The pop-up session focused on exploring alternatives to closed platforms; what pieces of infrastructure might enable us to build a 'decentralized Goodreads'? Plenty of us publish personal libraries to our own websites, but rarely in common formats that can talk to one another or pool data into communal centres to find connections and relationships.
You can read the we all took during the session on the IndieWeb wiki.
Data Exchange Formats
Most of the pop-up focused on the issue of data exchange formats. How do we get independent websites to agree on a common format for books? This includes both the format the data is passed between sites in (RSS, JSON, OPML, CSV), and the shape of the data itself.
My and book collections on this site are perfect examples of poorly formatted data that can't be automatically read by other sites. They're currently generated by an object in :
I have a title, author, a cover image in a local image folder, and a link to the book record on Google Books. This might be all I need to display a bunch of books on my library page, but it's poorly designed from an interoperability standpoint.
I'd never considered the limitations of this approach before the event, only because I hadn't thought ahead to the possiblity of publishing this list in ways others could consume it.
How could we improve the formatting of this data to standardise it? First, we'd have to make sure each book entry had a set of properties that would help identify it in a larger context. Title and author are useful, but they're not enough. We'd also need a UID (unique identification) number like an ISBN to make sure we don't misidentify books – duplicate titles and author names are uncommon but not unheard of.
People in the pop-up session suggested adding a number of optional, nice-to-have properties like reading status (to read, reading, read), page count, related notes, reading start and end dates, rating (out of 5), and genre/tags.
These would be harder to standardise than the core properties and factual metadata, but hold much more potential for enabling rich social interactions around books.
A few people reasonably pointed out we'll never have a single, unified format. It's better to pursue forgiving and flexible standards that enable people to publish books in a variety of formats. And instead build tools that can translate between formats and map properties from one type to another.
Prior Art and Existing Systems
This problem space isn't new and plenty of people have built bits and pieces of potential solutions.
There are a number of existing standard formats for books:
- Schema.org has a with an extensive list of properties
- Google has a for surfacing books in search results
wrote a piece proposing - a standard format for book data exchange. adapted it to using the properties defined on the Schema.org book type.
Publishing feeds in either JSON or RSS would allow us to create streams of books and subscribe to them using existing systems. Working with RSS feeds and writing JSON isn't the most user friendly interface though. Most people outside the world of web development would need something closer to a traditional GUI to manage their collections. Some people suggested spreadsheets as an accessible interface format.
Another possibility is encouraging people to shift from platforms like Goodreads over to more open platforms with API access. The Internet Archive has setup which is a non-profit, open-source book catalogue. They provide both a user-friendly interface for creating book lists, and have that allows you to fetch book information like covers, authors, and lists (currently reading, best sci-fi novels, etc.).
Frankly, these data exchange issues are outside my wheelhouse. I'm glad other people get a kick out of standardising schemas. I'm just here for the UX design challenges and social implications once we've sorted out how to surface this data.
Ad Hoc Reading Groups
An idea I brought to the event and ended up hosting a session on was ad hoc reading groups – discussions and meetups facilitated by our public bookshelves.
Personal bookshelves on website are a jazzy feature, but it's sometimes unclear what they're for. What does publishing a personal library to the web do for us?
They certainly help lay contextual groundwork for people visiting our personal websites. They tell others what kind of ideas we've encountered and what disciplines we've studied.
They also work well as invitations. Books are an easy starting point for conversation; "oh you read that too!". People frequently reference a book from my shelf when they first send a Twitter DM or email.
They could do more though. Publishing a book to a public library could be a way to signal you want to talk to other people about it. We all have at least a few obscure or niche titles on our shelves, and it can be hard to find other people willing to read and discuss them. Why not simply start with the people who are already interested in that book?
Bookclubs and reading clubs are obviously well established social formats we can borrow from to imagine how this could work. Usually you gather a group of people, then muddle through some democratic system of voting on books, and eventually everyone compromises on what to read. This is slightly easier with fiction, but non-fiction gets particularly tricky, unless you gather a group based on a specific discipline or domain.
Taking a book-first, rather than a group-first approach would enable reading groups who don't have to compromise on their book choices. They could gather only once or twice to discuss the book, then go their seperate ways. No long-term committment to organising and maintaining a bookclub required.
We would need a system that enables people to:
- Publish a list of books they would be willing to discuss with other people to the open web. – collections of books you haven't read yet but would like to read – are particularly well suited to this proposition.
- See which books people in their social network want to discuss, and/or subscribe to other people's lists
- Be notified when 4+ people in their network have the same book on their discussion list – possibly via an email thread?
- Coordinate and schedule a time to read and discuss the book with that group.
There are plenty of troublesome assumptions and unanswered pragmatic issues in that sketch. What's a "social network" (are using the Twitter API to check for mutuals)? What kind of system is scanning for book matches between lists? Is it capable of firing off group email chains once it finds one? How would it handle keeping email addresses private and double-checking people want to opt-in to a particular discussion group? Could people see upcoming groups and choose to join one opportunistically?
The more I think through these questions, the more it feels necessary to have some third-party intemediary service in the middle to match up book lists and email out proposed discussion groups to people. Not a "platform," but a mediator of independent websites. Ideally one with minimal maitenance costs and moderation work, lest someone try to turn it into a 'startup'.
I have to think about it more. My friends over at are experimenting with models and infrastructure to quickly spin up clubs and peer-to-peer learning groups – some of which could be part of the solution.
If you have ideas about how we might duct-tape together internet protocols or existing services to make something like this possible, I'd love to read them. Preferably as a public essay instead of a DM, but I appreciate that's not everyone's MO.