Custom sort subsets of the collection

[snydman]

@jkeck @cbeer An upcoming collection has the requirement of producing custom "galleries" from subset of the collection that must display in a specific and custom sequence. What are the possibilities for enabling this in Spotlight?

One idea: exhibit creator creates a "gallery sequence" field, the manually populates that field with an alphanumeric key that will be used to enforce the sort order. Like:

mlk0001 mlk0002

Exhibit creator then creates saved search for those items, possibly based on some other tag.

Presumably this would also require a new feature allowing the exhibit creator to enable custom fields as sort fields, and set default sort order.

What are your ideas on the best way to support this story?

[ggeisler]

@snydman Just addressing the user interaction aspect of this, I'd rather allow the gallery creator to drag and drop to create a preferred ordering, versus manually entering a key sequence. We do this in Revs (a user can order items in a gallery; a curator can order featured collections, etc.). The user just drags and drops and visually sees the order immediately; the sort order is saved on the backend by updating the order field value for each item based on the new placement.

[cbeer]

And this sort order isn't part of the existing metadata at all? And it only needs to be in this order when displayed in a Spotlight exhibit? And the order is specific to a gallery, not the collection as a whole?

[jkeck]

I guess this really depends on what the use case is.

@ggeisler are these collections that are being re-ordered in Revs paginated, or is it always a gallery of items on one page?

@snydman is the use case that we're talking about a paginated collection of objects w/ a custom sort?

I'm not sure how effective of a user interaction a drag-drop interface would work for 5 pages of 20 gallery records.

Ultimately, I think we need to support both use cases: 1) User can create custom field, user can create custom sort, therefore user can sort on their own custom data (assuming we're not forcing the custom fields to be multi-valued). 2) User can generate a single page gallery w/ drag/drop sort-ability. (this would most likely just be an enhancement on the current 5 item object grid we have now)

[ggeisler]

@jkeck True, drag and drop is not good when you are ordering a paginated collection. So in Revs, when the user goes into "Manage gallery" mode (change order, add item notes), we change from paginated to single-page display. Admittedly, that can make for a long page, but I think the immediate feedback of reordering a list that way is more intuitive and less prone to error than having to manually keep track of a sequence number.

[jkeck]

Totally agreed. I guess my concern would be that a user would do something like create a saved search that returns thousands of results and then try to order them by hand in that interface (which not only would take a long time, may not even work at all).

[jkeck]

Perhaps just some instruction that it may not be stable w/ large result sets would be sufficient.

[jkeck]

@snydman, back to @cbeer's point. Is the sequence something that's present in the metadata somewhere already (or should it be)? It seems like sequence order could actually be something important that shouldn't necessarily only live in a single application (like Spotlight).

[snydman]

@ggeisler @jkeck @cbeer @jvine Thanks for your discussion on this. I've posed some questions to the Fitch team to help clarify the requirement. But it seems (a) feasible and (b) generalizable enough, given the Revs experience. I like the idea of a drag and drop interface, especially if its already partially built.

This is also functionality that applies to displaying sets in SearchWorks and elsewhere.

[snydman]

@ggeisler @jkeck @cbeer @jvine In the current use case galleries are likely to be anywhere from 25 images to 200.

[ggeisler]

I believe the specific use case that prompted this ticket will be handled by #675. At this point I don't think we have any other requirement for curator-specific sequencing that wouldn't be handled by the proposed solution to #675.