Title level: display explanatory info about Bound-with parent

marlo-longley commented 1 year ago

So that a user isn't confused when they ultimately receive the parent item. The user should expect to receive the parent item with their requested child item bound inside.

See https://github.com/sul-dlss/SearchWorks/issues/3200 for more context

Could test this out by sending a query param, even without editing the button from SearchWorks.

This is the view:

dbranchini commented 8 months ago

Screens have been designed to display a bound-with item request. These are examples when there's no item selector screen. See screenshot below:

Child item request:

Parent item request:

dbranchini commented 8 months ago

Child item request

Follow this prototype flow and click "Request":

https://www.figma.com/proto/W3GIkPyGLeO5xMojmkZuTX/SearchWorks?page-id=453%3A2788&type=design&node-id=453-4106&viewport=2247%2C883%2C0.5&t=QreQwn6LHRwmydST-9&scaling=min-zoom&starting-point-node-id=453%3A4106&show-proto-sidebar=1

NOTE, we are on the child item, "Heart damage" in baled jute, and you click request, the title on the request app screen is the child item for consistency, "Heart damage" in baled jute, with a note regarding it's parent item, The gases of swamp rice soils....

Parent item request

It goes to the parent item (no change), and now there's a display of what's bound with this parent item. (We should consider limiting this display or adding a vertical scroll to the list when there are several items. Chris found records with 100 child items.)

Call number display is the primary change from the previous layout for both parent and child requests.

dnoneill commented 8 months ago

@dbranchini Does it make sense to include some information about what bound-with means. I am not sure that it is necessarily clear to the user what that means. It definitely wasn't clear to me when I first found out about them.

dbranchini commented 8 months ago

I had some designs with this, but on the SearchWorks side, and we decided it was too crowded. But long story short, I like your idea of adding it to the requests app somewhere. I couldn't agree more that it's confusing to users. I'll work on that. Thank you for the suggestion!

marlo-longley commented 8 months ago

@dbranchini these are great! In the case of the child request, the design totally makes sense to me.

I'm curious about the choice to include the extra info in the parent item request. In that case, does the user need to know all the other titles it's bound with? That item's title will be the one used, so the request should match expectations. It's a lot of extra info.

dbranchini commented 8 months ago

@marlo-longley and @jcoyne both had this question. It's a good question. One of the primary reasons we decided to display child records on the parent is because there are some record views with a complicated mix of both parent and child bound withs and we wanted to group them by parent because that is how they're shelved. For a patron that might want to go get an item off the shelf themselves, this would be important. Here's an example record that has this complication - https://searchworks.stanford.edu/view/5488000. V.3:NO.3 is bound with an item that's not on this record view, but V.4:NO.4 is bound with V.4:NO.1 (same record and shown on this page) and V.5:NO7-8 is bound with V.5:NO.1 (also same record and shown on this page). We could consider special treatment when these (most likely) more unusual cases arise, but I'd like to meet with the stakeholders, which is happening later today (3/4) to discuss the changes, before making that call.

dnoneill commented 8 months ago

@dbranchini I still working on a lot of the styling but I am assuming the note would go below the bound withs? Also for something without bound withs is it going to be confusing having so much red text?

dbranchini commented 8 months ago

@marlo-longley and @jcoyne both had this question. It's a good question. One of the primary reasons we decided to display child records on the parent is because there are some record views with a complicated mix of both parent and child bound withs and we wanted to group them by parent because that is how they're shelved. For a patron that might want to go get an item off the shelf themselves, this would be important. Here's an example record that has this complication - https://searchworks.stanford.edu/view/5488000. V.3:NO.3 is bound with an item that's not on this record view, but V.4:NO.4 is bound with V.4:NO.1 (same record and shown on this page) and V.5:NO7-8 is bound with V.5:NO.1 (also same record and shown on this page). We could consider special treatment when these (most likely) more unusual cases arise, but I'd like to meet with the stakeholders, which is happening later today (3/4) to discuss the changes, before making that call.

The stakeholders decided to keep this view was valuable and want to keep it.

dbranchini commented 8 months ago

@dnoneill , maybe it's not ideal, but since we'll be looking at the requests app more holistically very soon, it's fine to keep it. I think it'll work better once the "Bound with" info is encapsulated in the gray box with more spacing too. Thanks for pointing this out though! These are the things I need to keep in mind for the redesigning of the requests app.

dbranchini commented 8 months ago

Also note, the stakeholders asked us to remove the colons on our bound with headings because we don't use them anywhere else. And the text for a child item request with parent info should read, "This item is bound and shelved with".

As far as the layout goes, @dnoneill and I decided to keep the stacked view for both the parent item and child item requests for consistency and ease of maintenance since there's no real differentiation in that layout behind the scenes. We'll also remove the label "call number" from either view for the bound-with info boxes only (not the title).

dbranchini commented 8 months ago

Lastly, here's my attempt to provide some CSS direction:

Gray bound with info box:

The width of the gray bound with info box should match the width of the yellow box below it
It should have the same corner radius as well. Background is Access-Fog-Light or #F4F4F4
8px padding all around
Border bottom (or top depending on how it's coded) is Primary-Black-20 or #D5D5D4
4px between rows

Fonts are all Source Sans 3 or Dejavu Sans.

Title of the item:

H2 and Primary-Cardinal-Red or #8C1515 and it's 22px (or the equivalent rem or standard H2 in the requests app)

Call number (in red):

Primary-Cardinal-Red and 14px

Bound with "heading":

Primary-Black-100 or #2E2D29
500-weight font

dnoneill commented 1 week ago

closed with https://github.com/sul-dlss/sul-requests/pull/2439

sul-dlss / sul-requests