search

ProjectMirador / mirador

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.
https://projectmirador.org
Apache License 2.0
558 stars 255 forks source link

Manifest List Page sorting/filtering/faceting #513

Closed rsinghal closed 4 years ago

rsinghal commented 9 years ago

Users have requested the option to sort objects in manifest list page by institution. Performance can be a concern, but adding a ticket to encourage discussion.

azaroth42 commented 9 years ago

The list page should use Collections, thereby potentially allowing many different sorting and description options. Otherwise you're just reinventing the wheel we created to solve your problem in the first place at the Harvard meeting.

On Fri, Apr 10, 2015 at 8:04 AM, rsinghal notifications@github.com wrote:

Users have requested the option to sort objects in manifest list page by institution. Performance can be a concern, but adding a ticket to encourage discussion.

— Reply to this email directly or view it on GitHub https://github.com/IIIF/mirador/issues/513.

Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305

azaroth42 commented 9 years ago

Example: http://dlss-dev-azaroth.stanford.edu/prezi/colls/top.json

regisrob commented 9 years ago

Basic example here: http://demos.biblissima-condorcet.fr/florus/manuscrits-florus/mirador/index.html

aeschylus commented 9 years ago

I don't understand what these are supposed to be examples of. How are collections supposed to allow filtering of manifests by institution?

Let's get together some "as a manuscript scholar/art history student/neurosurgeon I want to filter images by ???".

If there are few enough categories, perhaps some buttons are in order. Right now, the text filtering is only filtering what is actually displayed to the user, the (plaintext repo name, plaintext title, plaintext item number). I will reproduce some thoughts on a collections interface from the mirador-tech list below, for additional context.

In the past, if a collection was added to the manifest panel, mirador would go down one level and get the manifests and plop them in the list flat like all the others. Of course, this makes the inaccurate assumption that collections are one level deep.

The collection you linked has about 3 levels it seems, having followed one of the branches. Providing a coherent UI through the whole tree of collections, which is of an unknown depth, is going to be a bit of work. Because the tree is of unknown depth, and because for any one collection there may be n manifests/collections, there is the potential for a polynomial explosion of requests that would overwhelm the browser. Only one layer of the hierarchy should be dereferenced at a time, and the spidering behaviour needs to be exposed to the user as part of the UI. Otherwise we would be faced with the reality of having to save an unknown, expanding number of complete manifests of unknown size, and make the user wait on this to build out the collection navigation interface. Even with promises, updating thousands of invisible spinners with rendering templates will lock up the UI.

What I have imagined is: any top-level collection appears in the manifest list interface as an item, with a slightly different structure and style reflecting what is known about the collection from the collection's own metadata alone. Clicking this collection expands the object so it becomes a sticky header of the manifest list page. The user is now essentially "locked" inside of this collection until they do deeper, or go up a level to the original manifests listing. Manifests from more than one collection cannot be saved along with all the others, but should be cast away and would have to be re-loaded once the user returned to that depth in the interface again. Requests for a collection's contents are dispatched only on the user's entry into each deeper layer, and thrown away when exiting (perhaps after a brief time-out).

Solving this issue (#513) could be done as easily as filtering with a "sort by source" button, assuming a location is provided. Currently this is not calculated from the manifest, but added in the config. New items would either need to be editable, or grouped at the bottom of the re-organised list as "unknown".

camillevilla commented 4 years ago

This ticket is being closed as part of the Mirador 3 issues review. We encourage all Mirador 2 implementers to try out Mirador 3 and leave feedback in new tickets.

This hasn't been implemented in Mirador 3, but it would be worth revisiting this discussion within the current manifest / collection selection UI.