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

Make document search available in entity preview #3879

Merged
merged 11 commits into from
Nov 4, 2024

Conversation

tillprochaska
Copy link
Contributor

@tillprochaska tillprochaska commented Oct 17, 2024

We frequently receive feedback about the search flow requiring too many clicks in the following use case:

  1. User searches for a term.
  2. User finds a document (e.g. PDF, Word) that might be relevant in the search results.
  3. They click on the search results and the preview is displayed.
  4. In case of documents that are longer than a few pages, most users don’t want to go over the entire document, instead they want to skim the relevant sections.
  5. In order to find relevant sections, users currently need to click on the "Expand" button in the entity preview. After clicking expand, the document search is available.
  6. Users then need to enter the search term again in the document search input.

This PR simplifies this flow as the document search is now available from within the entity previews. That means users can click on a search results, search within the document inside of the preview, and can easily return to the search results.

In a follow-up PR, I plan to prefill the search input for the document search with the value of the previous search or provide another easy way to reuse the search query so users don’t have to retype the entire query.

Screen.Recording.2024-10-21.at.16.58.57.mp4

From an implementation perspective, the main changes are in 52c706c. In addition to these changes, I’ve used the opportunity to refactor the EntityViews component as it was quite big and slightly confusing.

For this reason, I’d recommend reviewing the commits individually. The commit messages also provide additional details.

Document search has always been a little difficult to discover, as it's hidden in entity previews. Additionally, when coming from a global search, searching for the same search query inside of a specific document requires more interactions than necessary (first need to expand the entity, then copy/paste the search query into the document search input.

As a first step, this commit moves the search bar from the `PdfViewer` component up into the tab list in the `EntityViews` component. This makes it always available, no matter whether the entity is displayed in preview mode or not. This also saves some vertical space.
I can’t say that I fully understood why these styles where applied in the first place, so I'm not entirely sure this isn't breaking anything, but at first look everything seems okay.
The `render` method for this component was huge. I’ve decided to split it up which should make it easier to understand what’s going on and to make changes.
This removes unnecessary indentation levels and just makes the code a little easier to read.
The previous solution was manually rendering just the markup for a tab panel outside of the `Tabs` component (because we don’t want a visible tab button in addition to the search input).

This solution is a little more resilient, as it doesn’t rely on manually rendering HTML markup but uses the `Tab` component instead. Also, it provides a label for the search tab that can be used by assistive technology.
@tillprochaska tillprochaska marked this pull request as ready for review October 21, 2024 19:00
Comment on lines +95 to +99
className={c(
Classes.ICON,
`${Classes.ICON}-document`,
'PdfViewerSearch__icon'
)}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why doesn’t this use the Icon component?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For future reference:

The document icon from Blueprint looks like this: a single page. That’s what we want in this case.

Screenshot 2024-10-23 at 12 53 28

However, we also have a custom set of icons, e.g. for the different FtM schemata which can be used with the Icon component in addition to the default Blueprint icons. As there is an FtM schema called Document, when using <Icon icon="document" /> you get this custom icon which is a multi-page document:

Screenshot 2024-10-23 at 12 53 03

Because both the custom schema icon and the Blueprint icon are named document, this seems to be a workaround to get the default single-page icon from Blueprint instead of the custom multi-page icon.

This should be unnecessary as the reference modes aren't rendered in the first place in the top-level `render` method if `references` hasn't been loaded yet.
@tillprochaska tillprochaska merged commit d93a04b into develop Nov 4, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants