Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Change zoom behavior depending on context #46

Closed
2 of 4 tasks
anarchivist opened this issue Dec 23, 2017 · 9 comments
Closed
2 of 4 tasks

Change zoom behavior depending on context #46

anarchivist opened this issue Dec 23, 2017 · 9 comments

Comments

@anarchivist
Copy link

anarchivist commented Dec 23, 2017

We received some stakeholder feedback that UV's zooming behavior when navigating between search results returned from a IIIF Content Search API endpoint is really disorienting. This is especially true if you zoom out to get a fuller view of a line or page to view the match in context, and seems to be a particular problem when UV is at a smaller size (e.g. when embedded in Spotlight).

TODO

  • Document potential implementation

Current UV behavior as embedded in a Spotlight exhibit

Embedded UV

Acceptance criteria

Adapted from sul-dlss/content_search#33.

  • When a search is performed in the viewer (or pre-populated as described in Content search UI recommendations sul-dlss/content_search#33), the document is initially shown at 100% zoom-level, not zoomed in on the hit as the viewer currently does.

  • The zoom level stays at the current zoom level as the user navigates through matches using the prev/next icons.

If the user changes the zoom level to, say, 150% at some point, the zoom level stays at 150% as the user uses the prev/next icons. This is the case even if navigating the matches takes the user to a new page in the document (this is so the user's focus on matches is not disturbed by a change in zoom level when moving to a new page). So, for example, if the user had zoomed in on page 8 and was using the next icon to move through the hits in the mockup until reaching the last one on the page (hit 20):

when next clicking the next icon they'd see the page change to this for the next match (hit 21):

  • However, if the user navigates to another page in the document, either by clicking a page thumbnail or by clicking one of the arrow icons, the newly displayed page is shown at 100%, even if the user was currently viewing at at a zoom level other than 100%.

This is so the user can see the complete context of hits when jumping to a new page, since they have already lost some focus on the hits by manually changing pages by means other than the prev/next icons. So even if the user was zoomed in on page 8, if the user then clicked page 9 in the sidebar or clicked the page 9 hit indicator arrow, they'd see page 9 like this:

@mejackreed
Copy link

Partial technical approach resolved by a configuration setting in: sul-dlss/sul-embed#849

The second part: > The zoom level stays at the current zoom level as the user navigates through matches using the prev/next icons.

still working on.

@mejackreed
Copy link

Unassigning myself on the final piece of this issue.

@mejackreed mejackreed removed their assignment Feb 7, 2018
@aeschylus
Copy link

aeschylus commented Feb 8, 2018

I can see a path to implementing the third part of this requirement, but I think will require an upstream change.

There is a UV option called "preserveViewport" that lets the user keep the zoom level fixed while changing pages. You can see this in one of the UV demos: http://universalviewer.io/uv.html?manifest=https://damsssl.llgc.org.uk/iiif/2.0/4389767/manifest.json

If you click the settings icon in the top right, you'll see the option to freeze the zoom level. Now, changing pages won't zoom out before loading the next page.

There's an example of toggling this here: https://github.com/sul-dlss/universalviewer/blob/master/src/extensions/uv-seadragon-extension/SettingsDialogue.ts#L103-L107

It may be possible to intercept an event in sul-embed and change this setting outside UV, but would seem to be easier to implement as a new config option that implements the behaviour as an intrinsic part of searching (though with the drawback of upstream change).

@jkeck
Copy link

jkeck commented Feb 9, 2018

I wonder if just having that checkbox in the settings/options is good enough for our use case? Does this need to be default behavior for all objects or can we educate users about the ability to preserve their zoom level in the setting, and allow them to use UV's built in functionality?

@anarchivist anarchivist self-assigned this Feb 10, 2018
@anarchivist
Copy link
Author

Two questions, knowing that I'll be out this week because of Code4lib:

  • Can someone succinctly write up the proposal to use the UV settings only to maintain the zoom level? I think I know how to communicate this to the stakeholders but would like some assistance in figuring out how to explain this.
  • My understanding from @snydman is that the team came to a decision about the remaining work on zoom on Friday in the part of the UV planning call that I missed because of another conflict believe someone (maybe @ggeisler) was supposed to write up that remaining work. Can we make sure that happens?

@ggeisler
Copy link

@anarchivist:

Can someone succinctly write up the proposal to use the UV settings only to maintain the zoom level? I think I know how to communicate this to the stakeholders but would like some assistance in figuring out how to explain this.

I don't think there is a proposal to do this. It was just a question and I believe in our team discussion last week we concluded that this wasn't a viable approach.

My understanding from @snydman is that the team came to a decision about the remaining work on zoom on Friday in the part of the UV planning call that I missed because of another conflict believe someone (maybe @ggeisler) was supposed to write up that remaining work. Can we make sure that happens?

I don't think we decided on any major changes to our recommendations for zoom behavior in UV. @snydman did request that I separate our recommendations for content search zoom behavior from our recommendations for content search-related UI updates (so that the zoom work could be done sooner than the UI updates). So there is now:

I haven't adjusted UniversalViewer#529, which is the original ticket that encompasses both the UI and zoom behavior recommendations, because it also contains some useful discussion on the topic of passing query terms to the viewer. Not sure how we want to handle that at the moment. The tickets above also kind of make redundant sul-dlss/content_search#33 and this ticket but again, not sure how you might want to handle those since they are all in different repos.

@anarchivist
Copy link
Author

Thanks, @ggeisler. My suggestion would be to potentially edit UniversalViewer#529 to add references to the three other tickets and to split out the passing query terms discussion as a new ticket, linking back to the comments on UniversalViewer#529. We can then close UniversalViewer#529, sul-dlss/content_search#33, and this ticket. I think the broader question is how to track those tickets with regard to the project board.

@anarchivist
Copy link
Author

Per 2/20 sprint planning, we'll add cards for that link to the UV repo issues and put them on the board to track for feedback.

@ggeisler
Copy link

This ticket involved several features that we decided might be better approached as individual tickets, in the UniversalViewer/universalviewer repo. So I'm closing this ticket in favor of these tickets:

  • #545 - Desired zoom behavior for content search, with current UV UI
  • #546 - Explore more optimal approach to zoom level of first matched page
  • #547 - Update highlighting style for current match versus other matches in content search
  • #548 - Update UI elements involved in content search
  • #550 - Passing query terms to UV

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

5 participants