Design a way to paginate between images

[gissoo]

• note: no pagination is necessary when the all items within one record type are displayed (for instance: all images)

[gissoo]

@rlskoeser Please take a look at the pagination styles on the transcription panel – Marina suggested that on mobile we display only one set of records on each page, unlike desktop where we display two. After much contemplation I decided to keep the pagination display the same on desktop and mobile. What this means from my pov is: on desktop "1/2" means you're viewing page 1 of 2 which contains two sets of records, and on mobile it's "1/4" which means you're viewing page 1 of 4 which contains one set of records. Let me know if this is disastrous – I'd like to avoid changing pagination formats between desktop and mobile.

[rlskoeser]

@gissoo thanks for flagging this. I understand the logic and can see how this approach makes sense for the user.

It definitely makes the implementation more complicated. I'm not sure whether it's disastrous exactly... But it will require a different approach than typical responsive css. I can see a few ways we might approach it, although I'm not sure how well I like the ideas I'm coming up with now. (e.g., do we have redundant logic/pagination in the html that we disable/enable based on screen size? do we paginate entirely in javascript? neither one seems ideal.)

The starting point question for me about implementation is how much of this functionality can we reasonably implement (and should implement) without javascript and then how can we progressively improve that version. i.e., if you look at the page with javascript disabled, do you see an unpaginated version? the mobile version?

I really like the idea of showing two pages at once on desktop, but I can see why that doesn't work on mobile. How much extra value does the two page layout give to the researchers? Is it worth the extra complexity to implement and design, or would it be better to keep it more consistent?

[rlskoeser]

(unrelated to the question you asked, but it's so exciting to see these designs and think about implementing them)

[gissoo]

@rlskoeser thank you for your thoughtful comments and questions, super helpful.

@mrustow @richmanrachel, updates on where we are with pagination: following our discussions on Wednesday which led to questions on displaying fragments that are not part of the document and how that might potentially affect pagination, Rebecca and I talked. We both think fragments that are not part of a document should not really be part of the transcription panel, however, my proposal is whenever there is a fragment that’s not part of the document, we visually indicate its existence in the order it’s supposed to be and link to its document detail view or (anywhere else when we can), but indicating it would be helpful – in other words, we don’t fully display its image or display it faded/slightly different in visual style from the others. Rebecca mentioned that this would also address the "other documents on these shelfmarks" section, so we could remove that section from the page.

• Rebecca suggested that we do not paginate for now, as it would help us handle all the cases with fragments/documents that will affect the display.

Let us know what you think about the above.

[richmanrachel]

@gissoo and @rlskoeser - I like this in theory, but am worried about it creating more problems:

1) Would we have to go through every single image and delete/remove the manifest of the verso image for all documents that just are on the recto, for example? We do not have the metadata delineating where most of our documents are on the fragment, so this would be a massive datawork problem that requires someone with decent paleographic skills to determine.

2) Is the transcription model already strong enough to highlight areas on the image, so that if the verso contains the address for document 1 on the recto, we keep the whole verso image but highlight the address?

3) Most documents really are on a single fragment, so not paginating will usually be okay. But @gissoo, have you tried a mockup of the Sa'adya bifolio or one of the multi-page docs to see if this will be okay at the extreme end?

[rlskoeser]

As discussed in the meeting today:

I propose we use the existing "side" information in the database (recto/verso/both) for now; we can consider using transcription information in future (can possibly use the "side" information as an override when transcription information isn't sufficient).

Additional details / related information:

• PGP team will align their recto/verso with owning library designation and document in description where they disagree semantically on ordering
• I suggest we visually highlight the selected image in the admin interface somehow (initial thought was an outline on the thumbnails shown on the inline in django admin)
• we should use side information to improve the image display on the search results; Marina requests that we display the main side first but still display the other side in the stack of images
• when testing features that rely on side information in the database, we will supply Rachel with a list of ids that have side information to test with
• we should identify test cases to keep them in mind when testing and reviewing functionality related to pagination, selecting images, etc.

[gissoo]

@rlskoeser @richmanrachel @mrustow documenting:

1. Marina agreed with not paginating for now so I've removed the pagination. @richmanrachel, I looked at that bifolio and I think not paginating is fine for now, it will give us a chance to understand the various cases better.
2. Marina also agreed on suppressing the irrelevant fragment from the transcription panel in cases where possible – and agreed with a display where the fragment is faded out with language that directs users to library sites or our own document detail view pages to read about the document on that particular fragment. I'll create a new design issue for this so we can track it separately.
3. Highlighting the parts of the fragments that make up the document would be very helpful. I'll track that work in a separate issue as previously discussed with Rebecca.

I think I can close this issue.