MDiMeo
commented
7 years ago Some other image viewers to check for comparison (some with personal notes, gathered through conversation with others):
https://wellcomelibrary.org/item/b19703181#?m=0&cv=14&c=0&s=0&z=-0.0787%2C-0.0364%2C1.1575%2C0.7271 (This is the reference to the Wellcome Library in @jrochkind's post above. It was originally cited in #312 and I'm just repasting it here so it's all in one place.)
http://records.cmoa.org/things/55dd1b6e-9b61-469c-8084-3b52ca69d88b/
- viewer stays on page with metadata, intuitive design, only appears to work with two items
https://www.digitalcommonwealth.org/search/commonwealth:4j03d9202 (single image) https://www.digitalcommonwealth.org/search/commonwealth:gq67k665h (book)
https://www.wdl.org/en/item/17588/ (book) (Similar to the Digital Commonwealth one.)
https://repository.library.brown.edu/studio/item/bdr:10661/
- different view options; clunky zoom (having to click on the plus sign each time and not being able to use the mouse scroll)
- keeps the metadata and search bar intact but design is too busy and hard to use
http://digitallibrary.hsp.org/index.php/Detail/Object/Show/object_id/7742 @catlu worked with this viewer at HSP and is familiar with its problems but always liked the scrolling functionality for flipping through multi-page books
http://universalviewer.io/examples/#?c=0&m=0&s=0&cv=2&xywh=-1%2C-116%2C4872%2C3603
- Universal Viewer was discussed above in great detail in @jrochkind's post, but @archivistsarah also mentioned potential for OCR & searching within works (via keyword search at the bottom)
http://books.northwestern.edu/viewer.html?id=inu:inu-mntb-0005986331-bk https://collections.nlm.nih.gov/bookviewer?PID=nlm:nlmuid-66310800R-bk
http://digitalcollections.lib.washington.edu/cdm/compoundobject/collection/iww/id/43/rec/5
- thumbnails on the left, with current image highlighted; zooming isn’t smooth – reloads entire image; can’t scroll or click to zoom
https://dlc.library.columbia.edu/catalog/ldpd:113779
- metadata parallel to the image, image displayed in the record as something larger than a thumbnail, pop-out viewer is sleek & minimal, like that the thumbnails for multiple files in work (in the pop-out image viewer) disappear/appear on mouse-over, only seems to handle two items
http://library.duke.edu/digitalcollections/hasm_a0011/#info
- info button at the top that jumps you down to the metadata, arrows appear upon mouse-over & let you click through the work, same for the image # that appears bottom left (eg, “3/6”); like filmstrip thumbnails; didn't expect clicking on image takes you to a new tab with just the image & no metadata
- Title at the top, filmstrip thumbnail viewer with highlighted image to show you where you are in a multi-file work, images display large by default when viewing the work; if you “view as book” the way to get back to the work record with the metadata is not immediately clear; zoom button instead of click or scroll to zoom (also the button gets bumped off the screen once you click it, so it isn’t immediately clear how to zoom back out); breadcrumbs at the top before the title not terribly informative (“Item”)
jrochkind
hackartisan
We need to redesign our work "show" page (what you get when you click on a work in search results or from a collection; or from google or facebook or a bookmark) to meet our understanding of user needs. While we can redesign it in the smallest ways possible or more significantly, some redesign is needed to meet goals expressed in #312, which I'd also summarize as:
And:
Because of the 'in-browser zoom' requirement, our page will need to involve a JS-based pan-and-zoom viewer, which is probably tile-based (IIIF, DZI, etc), since our individual full-res images even encoded as JPG are, I think too big to deliver to the browser effectively all at once. (3M and up I think, for full-res jpgs of our images, which I think is probably too large to just deliver in whole without tiling).
When I consider possible designs from examples and our discussions, I think there are two major categories: 1) The JS "Viewer" embedded directly on the page you see as soon as you get to it; vs 2) An additional click on the initial page is needed to open the 'viewer'.
Both have advantages and disadvantages. I think one key question, is: Are most users most of the time (possibly weighted by personas/user groups of higher priority for us) coming to the individual Work page (by click on search results, google, facebook, etc):
I'm going to show a few basic wireframe mock-ups of different possibilities in both these categories. The intention is to stay away from the individual micro-details of each, but focus on these general macro-approaches as alternatives, and start thinking about possibilities. Likewise, while I'm listing some brief implementation considerations for context, they are not meant to be the focus.
It's also possible none of these are in the right direction, or that this document/exersize is not actually helpful to us -- I'm open to that!
A page where viewer is NOT on original page, but takes another click
I think this can be a very attractive and straightforward (easily comprehensible by users) page, which makes immediate sense to give you an idea of the work on landing on it. BUT it will require an additional click to get actual pan-zoom viewer. You can click on the large 'representative' image, or on the smaller thumbnails for other pages to get a viewer. (ALL pages be on the page, as they are in our current production; or there might be some pagination or limits).
You can possibly download various formats directly from this page; or from the viewer; or both.
My hypothesis is that the current "File detaisl" pages (eg https://hydra.chemheritage.org/concern/parent/cn69m4595/file_sets/mg74qm57b) are of use only to staff, not to the end-users. Staff might need a way to get there (from original page or viewer), but end-users don't need these pages -- they need the Work page, and the image viewer. I carry this hypothesis through all the 3 designs shown here.
Once you click on a thumbnail, you'd get a viewer (perhaps in a 'pop-up' window, perhaps a navigation), that looks something like:
Note you do still get thumbnail browse on the viewer page; a form of it was also on the original page as important overview.
The viewer page would look much the same on tiny mobile screens too -- on the smallest screens might have to skip the thumbnail browse and just have next/previous.
The original page above will of course have to look somewhat different on a small/mobile screen, since it uses a wide horizontal layout. On a smaller screen, maybe:
Implementation notes
The original page is perfectly straightforward html. The 'viewer' would probably use openseadragon, but not neccesarily "universalviewer" or similar, we should be able to build it ourselves from openseadragon, it's not complicated.
Especially if using openseadragon directly, we could consider/explore using a cloud hosted image server like imgix instead of a local riiif server.
An immediate viewer, fairly basic/naive approach
The Wellcome Library has been suggested as one example. See example page.
This takes something much like our current design, and just plunks a viewer down near the top of the page. The Wellcome Library happens to use (and have originated) the Universal Viewer javascript package.
I personally find this design not very successful:
One advantage can be it needs little design work -- just plunk the viewer at the top of our existing page, for now. And it at least hypothetically needs little implementation work -- just use the already existing Universal Viewer.
Implementation notes
"Just like wellcome library" would naturally use the UniversalViewer JS package.
Looking just a bit at the UniversalViewer, I'm not actually completely sure how customizable it is. It's somewhat under-documented, but it looks like customization (including theming) is done by forking the source code and customizing, and then using git merges to try to keep up with upstream changes. This is not ideal, but could work.
It's unclear how hard it will be to customize other parts of the UI -- different 'content' window, different 'download' links, etc.
I think integrating the UniversalViewer, even just as it is, could take significantly more implementation work than just "install it and turn it on" -- but necessarily will of course be less work than using the UniversalViewer and doing more complex changes to our pages, instead of just plunking it in.
Single-page on-screen viewer.
Following up on the thought that the on-screen viewer above is in a sense "asking" to be the entire viewport, I investigated a design that is more "app-like", where you have a viewer app that takes up your entire browser window and is more 'interactive' than a typical web page (implemented with javascript, naturally). In a sense, it's the UniversalViewer just blown up to the be the entire page -- this is, recall, what people are going to see when they click on a search result (or arrive from google/facebook) -- but I just did a basic wireframe design that differs in some ways, instead of just copying UV.
This takes up your whole viewport -- although not neccesarily each column having equal width. On a really large monitor/browser screen, the central image column would probably take up most, giving you a area column to pan and zoom in, with the side columns being narrower. But there is no whole browser-window scroll bars, horizontal or vertical.
Both side columns do have their own vertical scrollbar. The left one is more or less the info on our current textual 'work detail' page, perhaps redesigned somewhat -- you can scroll it independently, the image stays where it is. The right one is your list of all thumbnails, giving you browse/skim/overview and quick navigation.
You could choose to hide some of the columns, be looking at just one or two instead of all three at once. UI device for this not sure yet, but I bet we can come up with something.
On a very small (mobile) screen, you couldn't fit all three columns at once, you might only be able to look at one at a time, but still some UI device to switch back and forth. Not sure which would be the initial/default column/tab on a small screen.
implementation details
Potentially we could just take the Universal Viewer and manage to make it take up the whole viewport. Not totally sure if this is feasible. We'd probably want to customize the "More Information" tab (eg Wellcome Library), if this really is the entire 'work detail' page it needs to be more carefully designed, not just a list of labels/values. Again, not sure how feasible customization of UV is in general, but it may very well be.
We could also probably do this with OpenSeadragon for the central image pan/zoom, and the rest ourselves with our own JS, without too too much trouble. Probably.
Thinking outside the box (literally!)
One more, just to push the envelope, as they say.
All these examples let you skim/browse/navigate through pages by giving you a list of thumbnails (in one format or another), which you click on to load the page.
What if instead we wanted to support one big scroll through ALL the pages -- like google books for instance, see: https://books.google.com/books?id=x2CqiwsSg_wC&pg=PA18&dq=kropotkin&hl=en&sa=X&ved=0ahUKEwit1K-26vfTAhWpgFQKHZPKAT8Q6AEIMzAC#v=onepage&q&f=false
When you want also to be able to pan/zoom each page, this gets challenging from both implemenatation and UX perspective. But -- image if it were like one giant canvas with all the pages on it, prezi-style? Believe it or not, this is actually quite feasible -- once you've put an OpenSeadragon tile-based-image viewer in, you can totally have an enormous prezi-style canvas that you move from page to page on. Although it would get tricky figuring out which page you are currently on for your 'download' links.
Overall, I think this approach is probably too "experimental" for us right now, too much uncharted territory, even if theoretically technically possible. I thought it was cool so wanted to throw it in as a more experimental alternative pushing the boundaries though.
We could also imagine offering users multiple "Work detail" pages, they can toggle between. But one still has to be the initial/default one (which many/most users are unlikely to change), and I think we probably have to start with one of them anyway and don't want to commit to more than one before soft-launch, so I think that's also a potential future enhancement (which may or may not be a good idea) to put away for now.