Allow the order in which manifests are displayed in the loaded manifests menu to be specified in the configuration.

[aeschylus]

As-is, the order is determined by the order in which AJAX responses for the manifests are completed, with the most recent at the top. Users can then filter the list by text in the search field. There were also designs for user-defined ad-hoc orderings of the list.

There are a few reasons we originally made this decision. They mostly have to do with the usability implications of having so many asynchronous unknowns. As a tool, Mirador doesn't know if or when any requested manifest will arrive. It doesn't know where those servers will be or even what their capabilities will be ahead of time (until getting info.json responses for thumbs). This means that, if any particular ordering is applied (whether the array ordering of the options, or another pre-filtered ordering like "alphabetically by institution") it is very likely that the user would be staring at a blank list with one or two populated options (assuming we have placeholders for items). Some of the requests may never finish, so the state of the request would need to be communicated (similar to how the thumbnails display their loading state).

I have a nearly-completed system for this in a branch involving the standard enter=> update=> exit cycle in d3. This adds a placeholder template for each manifest and a load status indicator showing the number and status of remaining requests. As components of the manifest entries load, the placeholders are filled according to the order of request resolution. Failed requests fill in placeholders at the bottom of the list.

I would love to hear of other ways to handle the problem, and I also recognise that a lot of this will be changed by the considerations engendered by collection support.

Related:
#287 (change design of manifest panel)

Mirador-tech entry about collections

[rsinghal]

Instead of creating placeholders, which could potentially be empty if a manifest doesn't load, we could attempt to enforce order by not just always placing the most recent manifest at the top, but within the context of the already loaded manifests. That could mean placing it at the top, bottom, or in between two manifests depending on the current state of manifests that have been added to the manifest gallery.

[rsinghal]

For some reason, this isn't working again. Investigate.

[rsinghal]

@jpadfield I looked at this a bit closer and I think I understand why you are encountering an issue. In the data part of the Mirador configuration, there are a list of manifest URIs. After Mirador requests the manifest from that URI, it uses the @id from the manifest for everything going forward. If the manifest URI in the data array is different than the @id within the manifest, then we can't put it in order because they don't match. So, if manifests are not displaying in order, check that first. I'm going to close this issue because it's a data issue, rather than a bug in the code, as far as I can tell. If you are still having issues, please include the data array you are passing to Mirador.

[jpadfield]

I have adjusted things as indicated and it is now working, thank you.

Joe

On 19/10/16 16:05, Rashmi Singhal wrote:

@jpadfield https://github.com/jpadfield I looked at this a bit
closer and I think I understand why you are encountering an issue. In
the |data| part of the Mirador configuration, there are a list of
manifest URIs. After Mirador requests the manifest from that URI, it
uses the |@id| from the manifest for everything going forward. If the
manifest URI in the |data| array is different than the |@id| within
the manifest, then we can't put it in order because they don't match.
So, if manifests are not displaying in order, check that first. I'm
going to close this issue because it's a data issue, rather than a bug
in the code, as far as I can tell. If you are still having issues,
please include the |data| array you are passing to Mirador.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#570 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ7Hta71nIOyW7f0wyOKqdWdGkmrnn8Dks5q1jHTgaJpZM4FK_b1.

Joseph Padfield
Conservation Scientist
Scientific Department
The National Gallery
Trafalgar Square
London WC2N 5DN
+44 (0)20 7747 2553
http://research.ng-london.org.uk
http://www.twitter.com/JoePadfield