Design the "related documents" page (instead of the external links page)

[gissoo]

• look at the examples Zohar sent on Slack

[gissoo]

@rlskoeser @mrustow @richmanrachel

• Here is my proposal for the "related documents page" – it would be most consistent if we display it similar to the search results page – Rebecca mentioned we might want to group the documents by shelfmark, what you see in the designs are just placeholders, I'll be reaching out to her to understand better.

• What information would you expect to see on this page that's not currently displayed?
• Is there information you absolutely do not want to see on this page that you're seeing now?

[richmanrachel]

@gissoo - I like the idea of using the format from the search page. Would it be possible to include the whole description, though? Since there will usually be only one to two other documents on the same fragment, this will not be too long. Users will still want to click to get to the other document detail page for transcription, etc., but having the full description here would be very helpful.

[richmanrachel]

Here's an example of a bifolio with four different documents (though currently only 2 PGPIDs) that you could use for your mockup: https://geniza.princeton.edu/en/documents/1562/

[gissoo]

@richmanrachel I think that's possible, especially since we had discussed doing that on search results (through expanded/collapsed behavior)? I defer to Rebecca since I'm not sure how hard it is on the implementation side.

One more thing: @richmanrachel @mrustow, during my conversation with Rebecca I gained a better understanding of the meaning of "related" in "related documents", I think the term "related" is confusing, and feel some inconsistencies from our previous conversations, might be worth to rethink the name.

[richmanrachel]

@gissoo - great!

You're right that there's some ambiguity, but it's partly because we still have not made a decision about whether the Related Documents tab will be just be "other documents on this fragment" or whether it should also be a place to find/utilize the "uncertain join" feature from the admin site. I'll see if I can squeeze this into tomorrow's agenda

[rlskoeser]

Displaying the full description is technically possible and should not be very difficult.

Discussing the scope and naming of the page at our meeting would be helpful! Can we discuss grouping then as well? (should fragments be grouped, if so how do we group and label the groups)

[richmanrachel]

@rlskoeser - I forgot that I had already put this convo down as a meeting agenda item, so we will definitely discuss! Could you say more about grouping fragments? What do you mean?

[gissoo]

@rlskoeser @richmanrachel Here are the designs for the related documents page on desktop and on mobile – I'm using the example that Rachel linked to earlier, so it would look like the mock ups if we go through with the changes.
@mrustow please feel free to check out the mobile version since I didn't have it last week.

Note: in order for the designs to make more sense I went ahead and mocked up what this document's document detail view page would look like as well.

Marina and I agreed on the following changes:

• repeat the document title even if it's all the same (as would be in this specific example)
• make the PGP ID bold on this page because it's often the only thing that immediately sets them apart from each other. (note: I made up the other PGP IDs)
• make the document title (the doc type) regular weight instead of bold, so we draw less attention to it.
• place a H2 style as a way to group the content based on the type of "relation" – Marina mentioned we'll have to identify the types of "relations" and come up with language (a series of phrases that take no more than one line) that can be applied for the different cases.
• Marina mentioned general context about the bifolio will also be given in each document description, e.g. "this is part of a bifolio, on its x side...".

Please let me know if you notice any issues, or would like me to try different documents.

[rlskoeser]

It seems a little weird to me to make the document title not bold and the PGP ID bold (I wondered if there is a different way to highlight the id), but I understand the rationale and @gissoo if you think this works then it's ok with me. Technically these adjustments should be pretty easy to make.

Everything else looks good to me.

I'm fine with determining the relationship headings later, just a reminder that we'll have to be able to identify related documents somehow by information or structure that's available in the database.

[richmanrachel]

@gissoo - I agree with @rlskoeser that while the rationale for bolding only the PGPID makes sense that it looks funny, and perhaps we could do something other than bold to make it clearer?

Everything else looks good to me too! I think some of the headings might be:
"Other documents on this fragment" and "Potential Joins"

[rlskoeser]

@gissoo I had couple of ideas for other ways to visually highlight the PGP IDs:

• background color (although I think you were thinking of adding this to the tags for accessibility reasons; IDK if it would conflict semantically or visually with that usage)
• a colored bar to the left, like we have on metadata labels on the document details page

[gissoo]

@rlskoeser We took a turn here for this issue – we won't highlight the PGP ID in any way here instead we have revised the formatting of PGP ID and input date so that: (please see designs here)

• revised input date to this language to match the detail view and this capitalization: "in PGP since x"
• revised spacing between PGP ID and the #, now it's 8px
• the space between PGP ID and "in PGP since x" is 2px and these two fields are 12px below the document date field
• the font size of the two fields is smaller now – 16px on desktop and 14px on mobile.

Note: these changes would also be applied on the search results page
and we will need to revise the "input date" language in the sort options as well.

[rlskoeser]

I'm fine with all these changes. Can update search at the same time as we implement this page.

Someone needs to provide language for the sort options to match the "in pgp since" language, but it's easy for us to update once we have it.