Design document detail pages so that researchers can learn more about a particular document and the fragment where it belongs

This issue is created mainly to communicate with RSK so that we can catch any inconsistencies that might exist between the goal of the designs/users' needs and the database design.

@rlskoeser I'm still dueling with some of the document metadata and options/features for image viewing, however I'm sharing this right now so you can mainly see how I'm thinking about displaying and interacting with transcriptions.

Notes:

thinking of this the same way as contextual notes, however a more static/stable version so that the information can stay in one place.
thinking of both one chunk of transcription and line-by-line/more fragmented.
also still unsure about line numbers in the designs, I'm not 100% sure or intentional about them with regards to how they currently look.

please let me know what you think about this.

In terms of the design and possible database mismatches:

I still don't understand what "associated shelfmarks" are. Can you elaborate? Do you know if this is something the current database design accounts for?
It hadn't occurred to me to list scholars work in a way that separates them out by type (is that what you intend in the design?); however, the footnotes structure does include a source type that would let us do this if it's important to users.

In terms of the transcriptions; it's helpful to see what you're thinking of since I'm still trying to figure out how to convert the TEI data and figure out how we would want to handle new transcriptions. I like the idea of being able to select a line on the image or a line in the text and see the corresponding image or transcription highlighted — those are good goals. Did you think about including line numbers on the image at all? (I'm not certain how practical or technically feasible that is, but I was curious).

Have you thought about how do to handle documents that appear on multiple images?

In terms of the design and possible database mismatches:

* I still don't understand what "associated shelfmarks" are. Can you elaborate? Do you know if this is something the current database design accounts for?

@rlskoeser Here are the revised designs now (please ignore the UI/visual arrangements)

I have revised this, what I had wasn't making sense. But what I have added now in the doc title and metadata piece I also need to check on whether the database would support it.

* It hadn't occurred to me to list scholars work in a way that separates them out by type (is that what you intend in the design?); however, the footnotes structure does include a source type that would let us do this if it's important to users.

they don't have to be separated by type, I have proposed three versions now – just thinking about these as possibilities.

In terms of the transcriptions; it's helpful to see what you're thinking of since I'm still trying to figure out how to convert the TEI data and figure out how we would want to handle new transcriptions. I like the idea of being able to select a line on the image or a line in the text and see the corresponding image or transcription highlighted — those are good goals. Did you think about including line numbers on the image at all? (I'm not certain how practical or technically feasible that is, but I was curious).

I have not thought of of including line numbers on the image, that might be helpful but yes, a bit tricky in terms of readability and navigating on mobile.

Have you thought about how do to handle documents that appear on multiple images?

I have now included some more examples of how I think about the entire image viewer and possibilities with the transcription. Please let me know what you think. I was thinking can we potentially reuse what we have built for S&Co with regards to the image thumbnail and nav?

@gissoo thanks for sharing these revisions.

In the document title and metadata section, why is one of the tags highlighted?

Is it important to differentiate documents in the same fragment and documents in the shelfmark? Won't they usually be the same?

For the image viewer, I think we're likely to use a IIIF viewer for this one since we want to take advantage of the IIIF annotation functionality. The one I was testing with will let us display thumbnails and configure where they are shown; I don't know how easy it is to customize beyond that, but probably possible. All that to say — I don't expect we'll be able to reuse the image thumbnail navigation we built for S&co. I think we'll have to evaluate the existing IIIF viewers with the functionality we need and choose the one that's the best solution for us, and then configure and customize as needed. (Possibly helpful to look at the IIIF viewer on the test site — but I also wonder if this isn't kind of early to be thinking about that level detail on this page?)

In the image viewer, why are there thumbnails at the top and bottom? Is the top one navigation panel? It looks redundant and a bit confusing to me; I wonder if these documents are big enough to require a navigation panel.

I love the idea of having some kind of visual like a radar chart to give people a quick sense of what kind and how much research has been done on a particular document.

@gissoo thanks for sharing these revisions.

In the document title and metadata section, why is one of the tags highlighted?

here is the revised design
thanks for pointing this out! It was wrong, I have fixed it now.

Is it important to differentiate documents in the same fragment and documents in the shelfmark? Won't they usually be the same?

Sorry I have fixed this. It's not "shelfmark" it's "folder" or "binder" meaning for instance this is the shelfmark: "AIU VII.D.38" – these are the folders/binders "AIU VII.D" – I can share more once I talk to more researchers about it, I just had a conversation with two researchers about it.

For the image viewer, I think we're likely to use a IIIF viewer for this one since we want to take advantage of the IIIF annotation functionality. The one I was testing with will let us display thumbnails and configure where they are shown; I don't know how easy it is to customize beyond that, but probably possible. All that to say — I don't expect we'll be able to reuse the image thumbnail navigation we built for S&co. I think we'll have to evaluate the existing IIIF viewers with the functionality we need and choose the one that's the best solution for us, and then configure and customize as needed. (Possibly helpful to look at the IIIF viewer on the test site — but I also wonder if this isn't kind of early to be thinking about that level detail on this page?)

Great, I was suggesting that because I am trying to think about "reusing" – as long as we can show thumbnails that is great! I'll look into the IIIF viewer on the test site – I don't know if it's too early to think about that since generally everything a researcher wants to do with images and documents have come up very frequently in the research findings but also I want to make sure I bring them up so we can expect to work on such issues to help plan for them/anticipate them in the future.

In the image viewer, why are there thumbnails at the top and bottom? Is the top one navigation panel? It looks redundant and a bit confusing to me; I wonder if these documents are big enough to require a navigation panel.

I agree! They are not big enough for that. I have removed the top one, it was a navigation panel.

I love the idea of having some kind of visual like a radar chart to give people a quick sense of what kind and how much research has been done on a particular document.

great! Will work on it more as I get into the generous interfaces, not sure if this version is exactly doing what I intended.
Also, I don't know if you noticed the "rearrange images..." section here – I have revised it and made my intention more clear. Let me know if you have thoughts on this.

Good to know about folders/binders. I'm not sure if/where we have access to that information right now. (Can we / will we settle on a single term and not use the slash?)

Oh! Rearrange images is a visual join editor? I'm very interested in implementing something like this, but it's way out of scope for this phase of the project. When and if we're able to get to it, I'm not sure if it would be on a single document view... unless it is for a document that's already been identified as a join and is available in two parts with two different manifests? (This is good for me to think about; I hadn't thought yet about how to display items that are on multiple fragments that are digitized in parts be represented by different manifests...). Are there other uses cases for rearranging images besides joins?

(Maybe not worth getting into now, because I don't think we can prioritize this for quite a while, but can't help thinking about this functionality: Which users do you imagine would want to / be able to rearrange images? Can anyone do this? And then who would be able to see their arrangement?)

I had been thinking before that rearranging images would more likely be done across digitized fragments, possibly from different collections. One possible use case for the generous interface of exploring fragments visually could be identifying fragments that belong to together (e.g., if you're able to sort them by size and filter them in some way — location, date range). It would be neat to allow users to select fragments from that might belong together and go to some kind of interface like this to see if they fit.

Good to know about folders/binders. I'm not sure if/where we have access to that information right now. (Can we / will we settle on a single term and not use the slash?)

Yes! I will be following up with project team to understand which one makes more sense and why.

Oh! Rearrange images is a visual join editor? I'm very interested in implementing something like this, but it's way out of scope for this phase of the project. When and if we're able to get to it, I'm not sure if it would be on a single document view... unless it is for a document that's already been identified as a join and is available in two parts with two different manifests? (This is good for me to think about; I hadn't thought yet about how to display items that are on multiple fragments that are digitized in parts be represented by different manifests...). Are there other uses cases for rearranging images besides joins?

Right, I don't mean it for the current phase. I think I'm thinking of it for documents that are already identified as a join and available in two parts. I think it still makes sense to show both of the fragments in each of the document detail pages. However, many aspects of your comment has encouraged me to revise my process of research --> design, so let's pause on this for a bit.

(Maybe not worth getting into now, because I don't think we can prioritize this for quite a while, but can't help thinking about this functionality: Which users do you imagine would want to / be able to rearrange images? Can anyone do this? And then who would be able to see their arrangement?)

My intention is that anyone can do this – it's just for them, I wasn't thinking that it would be seen by anyone! It would be nice if the person can save the image, or if they can at least take a screenshot of it once they have rearranged it. It's helpful to view the full fragment if someone is spending more time on revising or writing transcriptions or if they would rather keep the fragment as one whole image it on their own documentation or paper or presentation. – This is a way to reduce the steps that are currently needed to achieve this. But I have more thoughts on proposing ideas like this after reading your comments.

I had been thinking before that rearranging images would more likely be done across digitized fragments, possibly from different collections. One possible use case for the generous interface of exploring fragments visually could be identifying fragments that belong to together (e.g., if you're able to sort them by size and filter them in some way — location, date range). It would be neat to allow users to select fragments from that might belong together and go to some kind of interface like this to see if they fit.

this is interesting – I'm on it :) – I thought about generous interfaces for images after Alan's comment which had never come up!!, and then what you pointed out, it's a bit tricky in that I hope we won't be redundant in search pages... but it's very interesting, and I need to find out about this from more researchers before going too far.

I'll close this issue for now since more reconsideration is happening.

Princeton-CDH / geniza

Design document detail pages so that researchers can learn more about a particular document and the fragment where it belongs #34