Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canonical Books Pages: Merging Works + Editions UI #684

Closed
mekarpeles opened this issue Dec 22, 2017 · 16 comments · Fixed by #3553 or #3557
Closed

Canonical Books Pages: Merging Works + Editions UI #684

mekarpeles opened this issue Dec 22, 2017 · 16 comments · Fixed by #3553 or #3557
Assignees
Labels
Lead: @mekarpeles Issues overseen by Mek (Staff: Program Lead) [managed] Module: Books Page Needs: Breakdown This big issue needs a checklist or subissues to describe a breakdown of work. [managed] Priority: 2 Important, as time permits. [managed] Type: Epic A feature or refactor that is big enough to require subissues. [managed]

Comments

@mekarpeles
Copy link
Member

mekarpeles commented Dec 22, 2017

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

@LeadSongDog
Copy link

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?

@mekarpeles
Copy link
Member Author

mekarpeles commented Dec 23, 2017

[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?

@LeadSongDog
Copy link

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.

@tfmorris
Copy link
Contributor

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.

@LeadSongDog
Copy link

LeadSongDog commented May 9, 2018

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.

@mekarpeles
Copy link
Member Author

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

@LeadSongDog
Copy link

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?

@mekarpeles
Copy link
Member Author

mekarpeles commented May 10, 2018

You're right. I'm moving it over

EDIT: https://github.com/internetarchive/openlibrary/wiki/Canonical-Books-Page

@tfmorris
Copy link
Contributor

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.

@BrittanyBunk
Copy link
Contributor

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.

@BrittanyBunk
Copy link
Contributor

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)?

@BrittanyBunk
Copy link
Contributor

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 mekarpeles added this to the Active Sprint milestone Feb 4, 2020
@mekarpeles
Copy link
Member Author

@mekarpeles to re-spec for this month

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Lead: @mekarpeles Issues overseen by Mek (Staff: Program Lead) [managed] Module: Books Page Needs: Breakdown This big issue needs a checklist or subissues to describe a breakdown of work. [managed] Priority: 2 Important, as time permits. [managed] Type: Epic A feature or refactor that is big enough to require subissues. [managed]
Projects
None yet
9 participants