-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
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 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:
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: |
Related: Overview of current thinking re: approach for |
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? |
You're right. I'm moving it over EDIT: https://github.com/internetarchive/openlibrary/wiki/Canonical-Books-Page |
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. |
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. |
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)? |
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 |
The average user goes to Open Library to find a "Book" -- the term
work
andedition
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
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
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 usCurrently, 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 PageThese 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
The text was updated successfully, but these errors were encountered: