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

Enhance details of search results panel #2683

Closed
13 tasks done
ggeisler opened this issue Jun 11, 2019 · 8 comments
Closed
13 tasks done

Enhance details of search results panel #2683

ggeisler opened this issue Jun 11, 2019 · 8 comments
Assignees
Labels
ContentSearch 🔎 IIIF Content Search API

Comments

@ggeisler
Copy link
Collaborator

ggeisler commented Jun 11, 2019

After the work to display basic content search results has been done via #2670 has been completed, here are some additional details.

Assuming the case where the search service returns a list of complete list of hits (e.g. https://contentsearch.stanford.edu) and not paged results:

Screen Shot 2019-06-11 at 12 05 23 PM

(For reference, I used these results for the mockups, although note that sometimes I adjusted the result text displayed for space reasons, so things don't always map precisely.)

Note A: Hit navigation

  • Use the chevronLeftSharp and chevronRightSharp icons, with padding: 12px; for next and previous hit navigation.
  • Icon tooltips: "Previous result" and "Next result".
  • Between the next and previous icons, the text x of y, where x = currently selected result item and y = total number of result items/hits.
  • Center the hit navigation with the panel header.
  • Probably obvious, but the next and previous navigation is intended to enable the user to move through the results without having to select items in the panel body directly. So as the user uses the previous and next buttons, the panel body should update (changing the selected result item highlighting) and the page shown on the canvas should update (to show appropriate page and hit highlighting on canvas) accordingly.

Note B: Hit counter (#2699)

  • Result items displayed in the panel body are numbered consecutively, where the number of the result item matches the hit navigation counter described above.
  • Use headline 6 typography for the number.
  • For the background radius, I think radius: 50%; might do it. If not, try something like 16px.
  • Use #bdbdbd or Gray400 for the background color of the counter.
  • When the result item is the currently selected result item, change the background color of the counter to the same yellow we use for outlining the selected annotation on the Annotations panel. (The color is intended to match the hit highlighting color on the canvas.)
  • When the result item is on the same page/canvas as the currently selected result item, but is not the currently select item, change the background color of the counter to the same blue we use for outlining the non-selected annotations on the current page when on the Annotations panel. (The color is intended to match the hit highlighting color on the canvas.) See the mockup in the "Example: Two hits on same page" section below.

Note C: Canvas label (#2702)

  • Display the canvas label of the parent canvas of each result item, using the same headline 6 typography used for the hit counter number.

Note D: Hit content

I assume this is done in #2670, with the truncation aspect handled in #2671.

Example: Two hits on same page

This is the same document used in the mockup at the start of this ticket, but here the user has navigated to result item #3. Note that the background color of the result item hit counter for result item #4 is blue, because it is present on the currently display canvas.

Screen Shot 2019-06-11 at 3 29 36 PM

If the user was to navigate to the fourth result item, its hit counter background color, and hit highlighting on the canvas, would change to yellow, while those elements of result item #3 would change to blue.

If result item label is provided

If the search service returns a label associated with each result item (see https://exist.scta.info/exist/apps/scta-app/iiif2/lon/search?q=contradictio for an example), the label values should be added to the panel content described above.

  • Add the label value as a new line just above the result item content (highlighted in the mockup below), as subtitle 2 typography.

Screen Shot 2019-06-11 at 3 37 04 PM

@camillevilla
Copy link
Member

Picking off Note B: Hit counter if anyone wants to pick up other parts of this.

@mejackreed
Copy link
Collaborator

Picking off A

@mejackreed mejackreed self-assigned this Jun 13, 2019
@cbeer
Copy link
Collaborator

cbeer commented Jun 13, 2019

I guess I'll take C.

@jkeck
Copy link
Member

jkeck commented Jun 13, 2019

I'll snag the If result item label is provided section.

@jkeck
Copy link
Member

jkeck commented Jun 14, 2019

@ggeisler which label are we talking about wrt If result item label is provided. I'm trying to find where this is defined in the spec, but perhaps I'm missing something. I see where label can be provided as part of the autocomplete response, and where it can be used w/i the Target Resource Structure but that seems from the examples to be talking about the manifest / larger structure and not necessarily about the annotation itself.

In the example manifest given, that's not the label that is provided (however I'm not seeing that level of label described in the spec). I just want to make sure I'm doing this for the correct label before going down a rabbit hole. (or is this one of those things that can exist anywhere and we just need to deal w/ that?)

@ggeisler
Copy link
Collaborator Author

@jkeck Maybe I'm incorrect in suggesting the label be included. You're right that the label I am referring to is not the ones the search spec talks about. Mu suggestions comes from seeing a label included with each response in the results here: https://exist.scta.info/exist/apps/scta-app/iiif2/lon/search?q=contradictio

and assumed that since a label can be included as a property of any IIIF resource (at least, that's what I interpret this part of the presentation spec to say), which is the scenario in that search service response, and since if a label is included with each hit response it seems to relevant to the user, we should display it.

In other words, in https://exist.scta.info/exist/apps/scta-app/iiif2/lon/search?q=contradictio that search service response comes in the form of resources and label is a valid property for a resource so it seemed relevant to display to the user.

But perhaps that is not a valid assumption?

@jkeck
Copy link
Member

jkeck commented Jun 14, 2019

Okay, as long as I know specifically that we're talking about the resource label, I can add that. Just wanted to make sure I was doing the right thing and got confused by the other references to label specifically in the content search spec.

@ggeisler
Copy link
Collaborator Author

👍 Yeah, I probably should've been more clear about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ContentSearch 🔎 IIIF Content Search API
Projects
None yet
Development

No branches or pull requests

5 participants