Show "Want to Read" button for books on search results page.

[jimchamp]

Describe the problem that you'd like solved

While searching for books in Open Library, a patron may find several books that they would like to read in the search results. In order to add all of these books to their "Want to Read" list, a patron would have to open each book's page, click the reading log button, navigate back to the search results, and repeat.

Proposal & Constraints

Add a button (or a similar type of UI element) to each of the search result items that allows patrons to add a book to their "Want to Read" list with a single click. It would also be nice if clicking the component again would remove the book from the list.

It should be clear to patrons that clicking the button will add the book to their "Want to Read" list. If a signed out patron clicks the button, they should be directed to the login page.

Additional context

Stakeholders

[chrich2118]

I'd like to see this feature added as well.
Charlie

[mekarpeles]

One thing @jimchamp and I noticed during our call today is that we actually do have "Want to Read" button implemented for a List view already on the My Reading Log page.

It's worth noting that this version of the "Want to Read" button only covers the Reading Log and not a patron's Lists.

I'm proposing we have 2 separate buttons:

1. The green Want to Read Button which combines lists & reading log and currently exists on the books page (for now, the only way to add a book to a list)
2. The Reading Log Button which currently only exists on My Reading Log page (but, as per this issue, could easily be adapted to go on the Search Results + My Lists pages). This Reading Log Button won't include Lists, just switch Reading Log shelves.

Regarding point #2, we may want to make the styling more consistent between 1 and 2 (currently 2 is a grey bordered white button and 1 is a green button).

@jimchamp mentions it would be great if we could use the same component and consolidate 1 & 2, but @mekarpeles says, as a first step, we're already using (1) on the books page and (2) on the Reading Log page, and presumably it's going to be the same amount of work to turn (2) -> (1) on the Reading Log page as it will the Search Results + Lists page -> (1).

cc: @mheiman, @Sabreen-Parveen, @jimchamp, @cdrini

[mekarpeles]

@Sabreen-Parveen let us know if you have interest + time in this one, now that we have a fairly easy approach, otherwise, there may be another member of the community who may wish to give it a try. Thank you all!

[Sabreen-Parveen]

Yes @mekarpeles I want to work on this issue.
Can we just use the reading log button from the reeading log page, as it will be a lot easier work to do and is in consideration with our current use case?

[mekarpeles]

Let's please push up a draft if that's ok!

[mekarpeles]

@cdrini noticed a case where if we deselect the "Already Read" the text "Already Read" remains

[jimchamp]

@cdrini noticed a case where if we deselect the "Already Read" the text "Already Read" remains

Let's consider the new experience before labeling this a bug. Previously, whenever a book was added or removed from the reading log, the page would reload. Given that behavior, it makes sense for the button to have the default "Want to Read" value when the book is not on a reading list.

Now that pages do not reload on reading log updates, does it make sense to switch to the default "Want to Read" value if a book is removed from a "Currently Reading" or "Already Read" shelf? I would consider behavior like this to be a bug if I encountered it on another website.

[tuminzee]

Irrespective of the page reloading, the behaviour/action shouldn't change.

I think if should follow an order, if a book is in Current Reading, and if I remove it it should be tagged Already Read.
And if I remove a book which is in Already Read, it should be tagged Want to Read

What do you think @jimchamp @mekarpeles

[mheiman]

I agree with @jimchamp that the current behavior isn't a bug. The "Want to Read" button is functionally just a set of three linked ON-OFF toggles with a fourth NO SELECTION state. When you load a new page, the text "Want to Read" represents NO SELECTION, but when you've just toggled from ON to OFF without a reload, it makes sense to show the OFF state of the current value.

I was a little puzzled at first when I tested the behavior, but I realized that it's a design problem rather than a technical problem. The OFF state of the toggle (solid bright green) is considerably stronger visually than the ON state (gray with a checkmark), so even though I know intellectually what happened, my emotional response was to wonder at first if I'd done the opposite of what I intended.

[mekarpeles]

Got it, ty @jimchamp + @mheiman