search

chicago-tool-library / circulate

A lending library management system
Other
83 stars 66 forks source link

Librarian view: on Member page, allow tool look-up to happen not just through item #, but through tool name as well. #160

Open rkim00 opened 4 years ago

rkim00 commented 4 years ago

As a librarian, when I check out items for members, I want to be able to look up items by name in addition to by number, so that I don't have to remember or look up the numbers of items in order to check them out.

E.g., https://circulate-staging.herokuapp.com/admin/members/589 , the "Lend or Hold Item" white box at the bottom of the page only take item numbers, not text. Make this searchable by name as well.

Current functionality:

  1. Librarian types in the number of an item
  2. App displays some detail about the matching item, with "Lend" (check-out) and "Hold" buttons.

Suggested new functionality

  1. Librarian types in the name or number of an item
  2. App displays in the page matching results from which Librarian can select the correct item.
  3. As above, app displays some detail with "Lend" and "Hold" buttons.

Some implementations on the site that you could borrow from:

The eventual solution could largely the same as on the View/Edit Appointments page or the deprecated /holds page, or could be a combination of some of these approaches; some room for creativity here.

matisnape commented 4 years ago

Hi @rkim00 that staging environment you mention in the description, is it accessible somehow?

rkim00 commented 4 years ago

Hi @rkim00 that staging environment you mention in the description, is it accessible somehow?

Yes, https://circulate-staging.herokuapp.com . You should be able to use the credentials in db/seeds.rb . Does that answer your question? Let me know if you need any further assistance.

matisnape commented 4 years ago

@rkim00 Thanks, can I give it a go? :)

rkim00 commented 4 years ago

It's yours! Let me know if you have any questions; this is a bit open-ended and tricky, so feel free to reach out.

matisnape commented 4 years ago

@rkim00 I'm looking at app/views/searches/show and I'm curious - why there are 2 tables for results by number and by name items? https://github.com/rubyforgood/circulate/blob/development/app/views/searches/show.html.erb#L9-L17 It results in this funny view image image

Shouldn't these be combined on controller level?

rkim00 commented 4 years ago

Good question. I assume there are two tables because of search query optimization—essentially, that searching by number is faster than name. But it also might just be an artifact of how things got built at different times. @jim might know more.

Good catch—I agree it's strange behavior for the user. What's your recommendation for fixing?

matisnape commented 4 years ago

@rkim00

My thoughts on double search in /search: That search combines results from 2 kinds of search methods - one scoped directly in model, the other using more complex pg_search_scope. The number_contains scope is more universal than pg_search, because it looks for matches in any part of the number, not just the beginning (prefix) (this is also relevant for my task here, see below).

So I think there are 2 possible solutions here: 1) we merge @items and @items_by_number in controller and then sort by_name 2) we add number to :search_by_anything pg scope or create a new one like :search_by_anything_and_number

(Fun fact: I see that in /admin/search the search with number_contains has been commented out, leaving only the search_by_anything one - this makes me wonder if the non-admin search was just forgotten)

As for my task, I think we would need first decide what would be the desired best experience for the user when looking for lend or hold item. So: 1) Is the use case that admin should be able to get multiple results for the query to choose from or should it always be only one? Like in the Appointments with that select narrowing down options as you type. 2) Should the query be exact or should it match by partial match? Like with the number_contains and name_contains scopes. Now I see that you have to provide a specific number. For name it could be harder to find item, if the name is longer.

At the moment I'm leaning more towards number_or_name_contains results rendered in that section, but there's the possible issue of very long list of items to choose from - something that could be solved with limit and additional info if limit is exceeded, e.g. there are more results, please narrow down your search.

So these are my musings, let me know what you think :)

rkim00 commented 4 years ago

Great musings! Thanks for all of the thoughts, sorry for the delayed response—I was thinking on it all!

Maybe let's not worry about fixing the main search for now. It's a bigger issue, and while we should have that discussion, we should rope @jim and maybe some other people into it; maybe we'll do that in the #circulate channel in Slack (would you like to join? https://rubyforgood.herokuapp.com/ ).

Regarding the look-up on the Member page, in answer to your questions:

1) the admin doesn't not need to always get one result. I think, in fact, a better experience is if the admin gets several results, so that they can have some sense of the different options to choose from.

2) I think the query should match by partial match if possible. I'd hate to have librarians have to type "screwdriver" and not match on "screw", or to type "screw" and not match "screws."

However, I think there's a bit of a space constraint on that page that you'd have to work within. I could see where a pop-up screen might be useful, or just implementing the pull-down on the Appointments page.

What do you think about keeping the existing number look-up, and just adding a separate name look-up below it? The number look-up will be familiar to librarians and very quick, and so there's some value in keeping it as is, but the name look-up is also very helpful.

As for what that name look-up should be—what do you think at the moment? Is there more information you'd like from me to make a recommendation?

matisnape commented 4 years ago

@rkim00 Thank you for your pondering :)

Separate search for names seems like a good idea 👍

As for pull-down/infinite scroll of the results - is this already implemented somewhere? I see that stimulus is used for dynamic stuff, shall I go for that? I'm not very fluent in JS, so that will require a bit of research on my side :D Or maybe you have other recommendations?

rkim00 commented 4 years ago

I think easiest would just be to add something similar to what's on the Appointments page above

On View/Edit Appointments ( https://circulate-staging.herokuapp.com/admin/appointments/7 ), "Item" box

Does that work? I don't know about stimulus... if it's used elsewhere on the site I think that would make sense. I'll try to scare up another opinion or so.

jim commented 4 years ago

What if we add a button to lookup form that opens a large modal (it could cover most of the page), and inside that modal we can have the search interface? That way we can have more space to display items, include photos, etc. There could be a button that, when clicked, closes the modal and shows the "lend/hold" view to the admin for the selected item.

This could be done using mostly backend code with a little bit of stimulus to handle opening the modal, etc. We could start with using the existing search functionality and then move to something more find-as-you-type over time.

matisnape commented 4 years ago

@jim what about pull down then? should we load all search results if there will be many? Do we have modals anywhere else in the app?

jim commented 4 years ago

@matisnape I don't think so. We can definitely do something simpler like the pull down to start 😄.

The existing thing we have that is similar (for adding an item to an appointment) is here: https://github.com/rubyforgood/circulate/blob/805c74cf5bf50ee1be111e090087823efb95c68f/app/views/admin/appointments/_checkouts.html.erb#L40-L45

matisnape commented 3 years ago

Will make it another go 🙈