Openlibrary: Canonical Books Pages: Merging Works + Editions UI

Created on 22 Dec 2017  路  16Comments  路  Source: internetarchive/openlibrary

The average user goes to Open Library to find a "Book" -- the term work and edition can be confusing to their experience.

This is especially jarring when throughout the Open Library experience a user can either be dropped into either a Work page or an Edition page.

In 2018, we plan to release a new type of Canonical Book Page which simplifies the user's experience to a single page where users find information about a book, and about a specific edition at a time (from the same single page).

Similar to how good reads operates, this Canonical Book Page will show all the data you'd expect from a Work page and appear as if a specific Edition is selected. An option will be provided (described below) to show a list of all selectable editions, but this table will not be rendered as a Work page (as is currently the case).

These changes are especially important given that we're not just talking about work and edition pages. We're also talking about all the times a work only has one edition and then we render yet another type of page.

In addition to impacting the design (there will only be 1 books page, instead of edition + work), this change will also entail a change in url routing and how we generate sitemaps:

Axioms

Proposal
1) Today a work page is accessed as /works/OL...W/slug.
Moving forward, accessing this work page will redirect to the Canonical Book Page with the "best" Edition selected. Best in this case means (1) the edition available for borrow, (2) a public domain readable version of the book, (3) or the edition with the least waitlist. The following url is an example of a Canonical Book Page after this redirect occurs:
/works/OL...W/:slug/OL...M

2) Today accessing a specific "edition" is doe via a url of the form /books/OL...M/:slug
In the future, this url will expand to /works/OL...W/:slug/OL...M -- which is the same as from point (1) except in this case we decide the Edition, whereas in (1) the "best" edition was selected for us

3) Currently, if you want to access a list of editions for a work, you go to the work page: /works/OL...W/:slug
Moving forward, /works/OL...W/:slug/editions will show a standalone table with other editions of this book which can be opened using the Canonical Book Page

These are big changes and we plan on getting feedback from the community to make sure we address any concerns which arise during this transition. Our goal is to preserve all existing functionality, not make the experience worse for people who want to use Open Library as a catalog, and to make the platform easy for the vast majority of users who simply want to find a book and will get confused if functions are split between multiple pages.

See more @ https://github.com/internetarchive/openlibrary/wiki/Canonical-Books-Page

Related: #685

cc: @tfmorris, @cdrini, @bfalling, @leadsongdog, @hornc

Books Page @mekarpeles Breakdown 2 Epic

Most helpful comment

So, at https://openlibrary.org/books/OL19132054M/Krucifix-m%C3%A4starna_i_Link%C3%B6ping it shows "1 edition" (linked, top left), but the link is to itself, rather than the corresponding work at https://openlibrary.org/works/OL87755W as would be expected:
editionrecursion
Perhaps Worksbot created the work but never linked it from the edition? In any case, it is misleading to sometimes show an edition link and sometimes a work link but have both labeled as an edition.

All 16 comments

The idea is interesting, but Is the slug in the URL really necessary? It seems to be more of a problem than a solution. It forces a redirect. When a title is amended it invalidates the cache. It exposes titles to even casual snooping in browser history. Why not just leave it out?

[edit] Sorry, the mobile UI posted this prematurely.

Navigating to a Work today already automatically causes a redirect to include the slug, so this part wouldn't be a change.

It would be challenging to implement these changes without a change in routing because right now the search engine returns Works not Editions and our intention is to show users editions essentially. So we'd still need to still do a redirect (from Work urls to an Edition) if we don't change the routing. From a user's perspective, its nice to be able to see the Work ID and the edition ID in the same url.

Another way of thinking about this change is, we're not changing works, rather deprecating stand-alone edition pages and making it so a selected Edition is "featured" within the work page.

I'm not sure I fully understand the argument around cache invalidation in this case. I suspect we won't cache the Work endpoint (because they will need to be up to date with the work's archive.org borrow availability in order to have accurate data to redirect the reader to the best featured edition). We can cache the fetch of the Work + Edition's data from solr but I am not sure we'll want to cache the Editions page in its entirety either. I imagine we might want to cache the /works/OL...W/:slug/editions page (i.e. the one which renders the table of all the work's editions).

Does this help clarify any of the above points? Did I misinterpret any of the points you're making?

I was thinking more of permanence. Without the slug the URL is stable With it it targets a page that ceases to exist on a punctuation correction, whether for a work or edition.

I don't think the slug affects the routing (ie it's ignored), but a redirect from a slugless URL to one including the slug sounds like a waste to me. What is the user-provided value to compensate for the increased latency?

As far the original proposal goes, I'd need to work through it in more detail, but some of the questions that come to mind include:

  • how is "best" defined? A publisher thinks their edition is the best. A reader may have a different definition of best than the people who run IA.
  • how are language preferences factored in to edition selection? does they affect "best"?
  • what happens to the JSON API?
  • is there a mockup of the new page(s)? that would help understand whether all the information is still there, but rearranged, or if stuff is getting dropped

Generally I agree with the goal of simplifying the user experience. But the devil is always in the details for things like this.

So, at https://openlibrary.org/books/OL19132054M/Krucifix-m%C3%A4starna_i_Link%C3%B6ping it shows "1 edition" (linked, top left), but the link is to itself, rather than the corresponding work at https://openlibrary.org/works/OL87755W as would be expected:
editionrecursion
Perhaps Worksbot created the work but never linked it from the edition? In any case, it is misleading to sometimes show an edition link and sometimes a work link but have both labeled as an edition.

Related: Overview of current thinking re: approach for Canonical Books Page https://docs.google.com/document/d/1DDb2VX-otD5jPMbF_6ccI_wv8nrWMpNAWSBc4kXud2k/edit?usp=sharing

Is there some reason for putting that overview on google docs instead of on the open wiki under https://github.com/internetarchive/openlibrary/wiki

I am quite concerned that (hitherto-work) information will be lost, misplaced or never captured if one arbitrary, transient edition is seen as being canonical. We have dozens if not hundreds of editions for some works. Pick the wrong one as canonical and what happens to all the classification, subject, authors, etc.? It's already apparent that many of the edition records are not linked to the work record where these things are captured. How are these to be demystified with only a title and date but neither authors nor useful identifiers?

The thing that a wiki doesn't do as well as a Google doc is tracking comments and suggestions. Where should comments on the proposal be put? Here? Somewhere else?

I remain concerned with the idea that there's a way to pick a single "best" edition for any work. It's going to vary by user, at a minimum.

I agree with @tfmorris . "Best" is subjective. There isn't a good way to pick the best edition of a work.

@mekarpeles I'm labeling this issue backlogged since it looks like it's deadline has been punted a few times. Let me know if you agree or disagree.

I've edited the original issue description, to tag a related issue

So, at https://openlibrary.org/books/OL19132054M/Krucifix-m%C3%A4starna_i_Link%C3%B6ping it shows "1 edition" (linked, top left), but the link is to itself, rather than the corresponding work at https://openlibrary.org/works/OL87755W as would be expected:
editionrecursion
Perhaps Worksbot created the work but never linked it from the edition? In any case, it is misleading to sometimes show an edition link and sometimes a work link but have both labeled as an edition.

Those pages are seriously confusing. I only figured out yesterday (after much digging) that those are work-less editions. I wish there was something somewhere that said something about how it's a workless edition, so that people know. Idk if that's a github issue or not or should be one, but I feel the need to discuss it here first.

I remain concerned with the idea that there's a way to pick a single "best" edition for any work. It's going to vary by user, at a minimum.

Can't best be newest (as it's the best work - due to being the most updated) or oldest (like the original's the closest to the author's intent)?

The average user goes to Open Library to find a "Book" -- the term work and edition can be confusing to their experience.

This is especially jarring when throughout the Open Library experience a user can either be dropped into either a Work page or an Edition page.

How I first assumed the website's wording to be was "work" means "series or books" and "editions" means "books" (is the original language I used in my head when coming here. I'm assuming that's what most people use when coming here). So it relates to the whole missing series/volumes. #2751, #2452, #2746, #1586, #561.

@mekarpeles to re-spec for this month

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jdlrobson picture jdlrobson  路  5Comments

dcapillae picture dcapillae  路  4Comments

bitnapper picture bitnapper  路  4Comments

cdrini picture cdrini  路  4Comments

cdrini picture cdrini  路  4Comments