Design mobile and tablet wireframes of document detail page to communicate the content structure, page layout, and content variations to the project team

[gissoo]

This issue tracks design work through the CDH design review workflow.

Here is a link to the mobile and tablet wireframes on figma – note: once the page opens zoom out on the Figma page to view everything

Description:

The designs are for the following pages (the revised sitemap is on this figma page as reference):

• document details
• external sources
• scholarship records

also covering variations with:

• no image / one image / more than one image
• no transcription / transcription for one image / transcription for more than one image
• no description
• no external resources
• no scholarship records

Updates: (most of the decisions here need usability testing) + (updates below are same as the ones on #91)

• I have chosen to go with the horizontal nav
• I have also decided to not include "fragments" and "shelf read" in the main nav of this section, I think it makes sense that we have links to the fragment section/page but that it doesn't come next to the other items on the nav of this section
• Also, per RSK's advice I have taken out fragments and shelf read from this issue (I explored them and have some proposals but I also think they should have their own issue, and I have also updated the sitemap per RSK's comments + made fragments and shelf read to be potentially out of scope)
• I have decided to include the "editor" info on the document detail page at least for now till we know more because I think if we include it in the search results it needs to be shown on the landing page of a document
• I have decided to include only the shelfmark, doc type and dates, and the editor info to act as points of reference on the scholarship records and external sources (to know what document the info on these pages is about following Nick's comments on it) – but I think it should be visually less bold here
• the UI for suggesting or editing descriptions and transcriptions are not covered here because it was not part of the goal for the preliminary doc detail view, if you need it please let me know.
• I have made the "viz" on the scholarship record as simple as possible for now, I'll continue to explore data viz for future revisions.

specific designs aspects covered in this issue:

• [x] content structure
• [x] language and labeling of content and functionalities
• [x] page layout – mobile
• [x] menu/side bar position on page – mobile + tablet
• [x] image option menu position on page – mobile + tablet
• [x] grid – mobile + tablet
• [x] page layout when any field is missing, e.g. images – mobile + tablet

How the proposal/idea can fail:

1. I have proposed two ways of using the grid on tablet – one of them is narrower, which is more like the mobile version but I think it will make the page very long
2. Depending on how the content will look like on Scholarship Records, External Resources may not make sense on its own – because this page is only about informing the user about what libraries/institutions hold info about this particular document – it's a bit more general than scholarship records (and I want to avoid nesting them) – but if it can be incorporated as part of Scholarship Records naturally with its content then we may not need that page.
3. I propose that we navigate through images and transcriptions together – selecting to view image 2 will also show the user the transcription for image 2 – this idea is the most preferable usability-wise but it might fail if we can't support it

Questions:

1. Does the idea and/or the design make sense to you? If not, please say why
2. Within the context of this issue, is there anything that you expected to see and is missing?
3. Please let me know what you think about the proposal for the grid on the tablet – including tablet as it might be helpful, but we don't have to focus on it if you don't need it now
4. Can we do this?: for the user to select a line of text /area of text on the image (that is already outlined) which would visually focus/highlight the piece of transcription that corresponds to it?
5. please view the question on the sitemap about "adding external sources" and let me know what you think.
6. If we are filtering and sorting by input date, I think we'll need to also have it on the doc detail view, what do you think? Below the doc date field?
7. just remembering that we might need a "notes" field on these pages, especially the "doc detail"?

Note:

1. Because this issue and the issue for desktop got a little messy with our conversations on wireframing/fidelity and doing mobile first and uncertainties with how many pages/sections are included in "doc detail view" it's being divided in a messy way this time, the work in each issue will be more structured and appropriately scaled in the future.
2. Since you're now both editors on Figma it should be easier to view the labels I have written for each frame (which should further help with understanding what each page is.

[gissoo]

@rlskoeser @thatbudakguy Please review the designs and answer the questions above.

[thatbudakguy]

1. things that didn't make sense to me:
   • in "document details - without description", i expected to see the "suggest a description" button in the same place that the description is displayed on other screens, i.e. above the image instead of below it. i think the ordering should be consistent even if information is missing in some sections.
   • in general, if a document has no citations/external sources/shelf read/etc, I don't think we need to display the UI options for them, since it would just take users to the equivalent of an empty page.
   • i don't understand how the viz for scholarship records works. it seems to imply that a work can be e.g. "partially a translation", and that we can measure "how much of a translation" a work is. like the proposed viz for the document categories, i think this would be hard to implement.
   • i don't know what the difference between external sources and scholarship records is...but maybe this is just my bad? can't recall if we've talked about this and i'm just missing something. what would an example of an external source be?
   • pages other than the document detail page seem to be "about" (or, in the hierarchy, "underneath") a particular document's detail page, but there's no information on the page about which document you're currently viewing. for example, if i viewed the external sources for a particular document, i can't see the document's shelfmark or other info at the top of the page, so I don't know which document's sources I'm viewing.
2. nope, i don't think anything is missing!
3. if there is a link to "view entire fragment" from a document's page, the fragment page to me is not "under" document details. that page is for the fragment and all the documents that are listed on it, and it doesn't "belong" to any one of those individual documents. conversely, if you can navigate to the fragment's page via a different UI, like "explore fragments", there should still be a link to "view entire fragment" from each document that is on that fragment. I think both modes of access should be supported, and we don't want to privilege one way of getting to the page - just like how you can get to a book in s&co from a person's borrowing list or from the book search.

[rlskoeser]

Hi, @gissoo. As usual, Nick and I have a lot of overlap in our feedback.

1. things that don't make sense to me

The biggest one is that I'm still confused by structure of the pages you're proposing. If you're not ready to put the pages you're proposing into the full sitemap, could you provide a partial/local sitemap for this section? Although I'm not sure I understand why they aren't in the full sitemap; it seems like the sitemap and the designs for this portion should match. (It occurs to me that it might be a good practice to provide a mini sitemap with designs by way of orientation, like a "you are here" map. Curious what you think.)

In particular, I think that "shelf read" should be at a higher level hierarchically than document detail, and "view entire fragment" would probably be parallel hierarchy, not underneath a single document, since it needs to be accessible from multiple documents. From these designs I can't tell how you're thinking about the relative hierarchy of those pages. (Also, have we discussed whether shelf read is in scope? That might be a later phase)

I also was unclear on the difference is between external sources and scholarship records. Do we really need both?

I like the idea of the viz for scholarship, but Nick is right that it doesn't quite make sense the way you have it. Perhaps we could instead provide an aggregate viz showing the total number of each type of scholarship record, to provide a quick way of conveying the shape of the documented scholarship for this document? FYI, the categories they came up with to track in the database are: Edition, Translation, Discussion

You have editor listed on the main page, but this is also part of the scholarship record. Is it important enough to list twice?

2. I think I missed this on your previous iteration of designs: I see the cluster information, but are you listing all tags anywhere? (I just checked and I guess I also failed to notice this was missing on the sitemap content list; sorry 🤦‍♀️ )
3. I like both options for navigating to the entire fragment; the first one is more appealing if we can do it, but I'm not sure how much effort it will be to make it work for all fragments and match your vision. I do wonder why you have this listed before the the document description, image and transcription; is it more important than that information? Should it not be further down the page, as a kind of supplemental reference?

Other comments:

I agree with Nick, I would prefer not to link to empty pages (e.g. documents with no scholarship records); we do this on S&co for the membership activity, and when I'm using the site I find it annoying. Can we either suppress the link or make it visibly disabled? Another option, could we include a number in the nav to give a sense of how many records are available?

I agree with you, I don't think the vertical side nav works as well (although the idea is still kind of appealing for some reason...).

I think designs for shelf read and view entire fragment should be out of scope for this issue, and I don't think shelf read is in scope; would you mark it as potentially out of scope / long term?

Regarding view entire fragment: your current design seems like it's privileging documents more than the fragment. I think you should make a separate issue for this design, but whenever you return to it, I'd be interested to see a design that privileges the fragment over the documents.

[gissoo]

1. things that didn't make sense to me:

* in "document details - without description", i expected to see the "suggest a description" button in the same place that the description is displayed on other screens, i.e. above the image instead of below it. i think the ordering should be consistent even if information is missing in some sections.

• Thanks for writing, @thatbudakguy – getting to these today so that RSK can also have some time to get back to me before next week – I'm all for consistency however the reason it's not in the same place is because experience-wise it does not make sense to have it come before the image in this case – when there is nothing to refer to for understanding what a document is about till the user gets to the image and/or the transcription then they should not be seeing that button till the end of that journey – so I do not agree with this point.

* in general, if a document has no citations/external sources/shelf read/etc, I don't think we need to display the UI options for them, since it would just take users to the equivalent of an empty page.

• This is useful to hear – my inclination is to disable the button for when information is missing but wanted to know your thoughts as well since we did it this way for S&Co.

* i don't understand how the viz for scholarship records works. it seems to imply that a work can be e.g. "partially a translation", and that we can measure "how much of a translation" a work is. like the proposed viz for the document categories, i think this would be hard to implement.

• The viz is intended to be much simpler – it's just a viz showing whether or not a document has any of the four categories of records – and if it does how many it has – but this is just an exploration, will be exploring more with this – want to try new viz, not really wanting to see more bar charts

* i don't know what the difference between external sources and scholarship records is...but maybe this is just my bad? can't recall if we've talked about this and i'm just missing something. what would an example of an external source be?

• I'm going to test this for more specific info – it did come up during my research – will have more on it soon, it's a bit fuzzy now.

* pages other than the document detail page seem to be "about" (or, in the hierarchy, "underneath") a particular document's detail page, but there's no information on the page about which document you're currently viewing. for example, if i viewed the external sources for a particular document, i can't see the document's shelfmark or other info at the top of the page, so I don't know which document's sources I'm viewing.

• this is a great point, thanks, makes a lot of sense.

1. nope, i don't think anything is missing!

2. if there is a link to "view entire fragment" from a document's page, the fragment page to me is not "under" document details. that page is for the fragment and all the documents that are listed on it, and it doesn't "belong" to any one of those individual documents. conversely, if you can navigate to the fragment's page via a different UI, like "explore fragments", there should still be a link to "view entire fragment" from each document that is on that fragment. I think both modes of access should be supported, and we don't want to privilege one way of getting to the page - just like how you can get to a book in s&co from a person's borrowing list or from the book search.

• great! wanted to know your thoughts on this! I agree with your point in general and especially about it not being "under" the document details, that was my intuition as well.
• So something that we have not quite agreed on is whether we want to have a section that is mainly about Fragments on the site – from our discussion during one of our recent meetings we leaned towards being document-centric which opened discussions on how to then introduce fragments when viewing a document – I have been wanting to talk to you and RSK about the conversation during that meeting because I did think it would affect the "potentially out of scope" section of the sitemap for "Explore Fragments" but I didn't get to it – will need to be prioritized

[gissoo]

Hi, @gissoo. As usual, Nick and I have a lot of overlap in our feedback.

1. things that don't make sense to me

The biggest one is that I'm still confused by structure of the pages you're proposing. If you're not ready to put the pages you're proposing into the full sitemap, could you provide a partial/local sitemap for this section? Although I'm not sure I understand why they aren't in the full sitemap; it seems like the sitemap and the designs for this portion should match. (It occurs to me that it might be a good practice to provide a mini sitemap with designs by way of orientation, like a "you are here" map. Curious what you think.)

• Thanks for writing, @rlskoeser – I will add it to the sitemap – I explained why they were originally missing from the sitemap but wanted to have a conversation before adding them, but will add them
• I have actually started bringing in the section of the sitemap when designing that section! I guess I deleted it before submitting it for review for some reason, even though I had thought you might appreciate it!! Put it back in – but will need to revise it to reflect what I have done with the nav on this page.

In particular, I think that "shelf read" should be at a higher level hierarchically than document detail, and "view entire fragment" would probably be parallel hierarchy, not underneath a single document, since it needs to be accessible from multiple documents. From these designs I can't tell how you're thinking about the relative hierarchy of those pages. (Also, have we discussed whether shelf read is in scope? That might be a later phase)

• I totally agree about the hierarchy of shelf read and the fragments
• Re: Shelf read – it's helpful that it might be out of scope – it would be helpful if we can touch on the scope during the meeting when the topic is being discussed – or implement a system in the beginning of iterations to talk or flag to discuss after meetings to not lose track.

I also was unclear on the difference is between external sources and scholarship records. Do we really need both?

• As I mentioned to Nick I'm going to test this for more specific info – it did come up during my research – will have more on it soon, it's a bit fuzzy now.

I like the idea of the viz for scholarship, but Nick is right that it doesn't quite make sense the way you have it. Perhaps we could instead provide an aggregate viz showing the total number of each type of scholarship record, to provide a quick way of conveying the shape of the documented scholarship for this document? FYI, the categories they came up with to track in the database are: Edition, Translation, Discussion

• Thanks for the categories, this is helpful – As I mentioned to Nick I'll be experimenting with more types of viz.

You have editor listed on the main page, but this is also part of the scholarship record. Is it important enough to list twice?

• that's a great point!! – will add for usability testing – think it might be.

1. I think I missed this on your previous iteration of designs: I see the cluster information, but are you listing all tags anywhere?  (I just checked and I guess I also failed to notice this was missing on the sitemap content list; sorry 🤦‍♀️ )

• thanks for catching! I have added it

2. I like both options for navigating to the entire fragment; the first one is more appealing if we can do it, but I'm not sure how much effort it will be to make it work for all fragments and match your vision. I do wonder why you have this listed before the the document description, image and transcription; is it more important than that information? Should it not be further down the page, as a kind of supplemental reference?

• I also like the first option more (I mean "View Entire Fragment" – I'm still hesitating about the order in which it should appear on the page – it's on my list to be tested – this is a bit tricky – I suspect it will need to be positioned lower however I think a hint of it in the beginning is helpful – I'll work on this – there is something about having it appear above/earlier for those who are not familiar with this space.

Other comments:

I agree with Nick, I would prefer not to link to empty pages (e.g. documents with no scholarship records); we do this on S&co for the membership activity, and when I'm using the site I find it annoying. Can we either suppress the link or make it visibly disabled? Another option, could we include a number in the nav to give a sense of how many records are available?

• As I mentioned to Nick my inclination is also to have the option disabled – the number in the nav is a great idea! Was so concerned with spacing that I didn't explore with that.

I agree with you, I don't think the vertical side nav works as well (although the idea is still kind of appealing for some reason...).

I think designs for shelf read and view entire fragment should be out of scope for this issue, and I don't think shelf read is in scope; would you mark it as potentially out of scope / long term?

• sure

Regarding view entire fragment: your current design seems like it's privileging documents more than the fragment. I think you should make a separate issue for this design, but whenever you return to it, I'd be interested to see a design that privileges the fragment over the documents.

• so as I mentioned to Nick: So something that we have not quite agreed on is whether we want to have a section that is mainly about Fragments on the site – from our discussion during one of our recent meetings we leaned towards being document-centric which opened discussions on how to then introduce fragments when viewing a document – I have been wanting to talk to you and RSK about the conversation during that meeting because I did think it would affect the "potentially out of scope" section of the sitemap for "Explore Fragments" but I didn't get to it – will need to be prioritized

• navigation-wise I won't be privileging documents in the sense that fragments will be accessible through multiple documents, but your comment here is a bit confusing and sounds the opposite of what we discussed in a recent meeting – please let me know what you think, curious about your thoughts on this in case I'm misunderstanding.

[rlskoeser]

Thanks for responding, @gissoo. Sounds like there are a lot of things you'll be able to resolve or refine further with usability testing, which is great.

Trying to respond to what seem like the most important things, please let me know if there's anything else you want me to address.

Regarding having a section for Fragments on the site — I think expanding the sitemap would help clarify this a lot. The functionality you're proposing implies to me that there needs to be fragments section in terms of the hierarchy of the pages on the site; after all, shelf read is kind of a limited/special fragment browse, right? (contextual browse? 😉) However, we don't necessarily have to advertise or emphasize that part of the site to users. Until/unless we build an interface to explore fragments, you would only be able to get to those pages through the documents — which seems fine to me. If and when we add that "explore fragments" part, then it would give a new entry point to those pages.

Regarding your last point — my comments were unclear, I apologize! I was referring to the wireframe labeled "View Entire Fragment", not talking about the link from the document detail page to the fragment. I agree that we have determined documents should be privileged overall in the site, but for a page that is intended to view a single fragment, isn't appropriate for it to be more fragment-centric? Right now it looks like a list of documents. Is there a way we could see the images for the fragment with the documents that occur on each part, without repeating the fragment images? (Although that will probably result in repeating the documents in some cases...)

[rlskoeser]

@gissoo one more variation you might want to be thinking about and including in your usability testing: multi-page documents. How to display the images and transcriptions?

[gissoo]

@thatbudakguy I have revised the entire description of this issue and have updated the link to Figma – please read and review the wireframes and let me know what you think or if something is missing. If you don't get to it today, no worries, I will be asking Marina and Rachel to review it for next week (I will be tagging RSK so she can also review it if she has the time/ or finds it necessary because this revision is mostly directly addressing your previous comments from last week)

[thatbudakguy]

okay, going in order of your questions first:

1. still have questions about a few things:
   • I still feel strongly that we shouldn't reorder the sections of the detail page based on whether information is missing. If the "suggest a description" button is with the description when there's a description, but at the end of the page otherwise, we end up writing complex logic like "if A, B, and D are present, put it here, otherwise put it here" which is imo unnecessary complexity. if we do allow users to suggest/change content, the UI for doing that should be where the content would be, even if there's not content there to fill the space.
   • I also don't know what "suggest an edit" does vs. the other "suggest" buttons.
   • still don't know the difference between scholarship records and external sources. you mentioned you were still looking into this, can you explain more? maybe I missed it above.
   • for the info you added to the scholarship records/external sources pages so that the document can be identified, I don't know if we need so much information on these pages. i think we could do something more similar to a person or book detail page for s&co, where the title/name is displayed prominently at the top so you always know which item you're viewing, but the rest of the details are on a detail page. for example, the borrowing activity pages have the member's name at the top, but they don't include any more member details. i think we could do the same thing with shelfmark + pgpid, or some other unique identifier (I still think we need a visible unique identifier for documents, whatever that is).
2. nothing else missing.
3. i prefer the more relaxed grid on tablet. i think making tablet look like mobile is to some extent throwing away the benefits of a larger screen; let's use the space when we have it!
4. i don't know if we'll be able to do highlighting of the image/transcription simultaneously; it might be a long time before we know that. it seems like a complex behavior and something that might not be in the alpha, or even later versions. but it doesn't seem impossible - just complicated.
5. about allowing users to add more sources, this also seems like something we would build pretty far in the future, if we did it. less complicated than the highlighting thing, probably, but still further down the list.
6. are we supporting filter/sorting by input date on the public search? i know we have it for the admin site, but not sure if regular users are interested in that info. if we are, then yes, definitely agree – it should be on this page.
7. iirc the notes are only private for now, so we don't need to display them. I think any public notes would be part of the description?

[rlskoeser]

Thanks to @thatbudakguy for the great comments, you addressed most of this! To explicitly echo/emphasize a few things:

• Thanks to Nick for catching the different order; agree we don't want or need complicated logic about what to display when in different cases.
• I also prefer the relaxed grid on tablet.
• Highlighting image/transcription may be feasible, but is definitely a later thing that depends on the HTR and aligned text blocks. Can we carve out image+transcription display and interaction to refine that later when we know more? What you have here seems like a good starting point. I think that you will likely need to design for whichever IIIF viewer we decide to work with, and there are likely to be constraints that we don't know about yet.

@gissoo I figured out why the external sources is bothering me. It's not just that I don't know what this is — I don't know if or how it's accounted for in our current database design. I don't know if we have this to show.

I also want to expand on Nick's concern about letting users add content — I think we need to be careful how much of this we add, because not only does it mean writing code to support and manage those data submissions; it also means creating workflows for the project team to review and accept submissions and edits. We should prioritize the data submissions they care more about most.

Agree that if any information used to filter/sort on the public search should be visible here. I think Marina was interested in that being available on the public site.

I remember we discussed public notes at some point, but I'm not sure how that's different from description. Would be better if we could stick to one field!

New thoughts from yesterday's meeting:

• We should consider providing a per-document citation, for the transcriptions at least. Marina shared this "how to cite" guidance from the new PGL site. https://genizalab.princeton.edu/pgp-database/citing-pgp
• I wonder about providing a "credits" page for each document; some consolidated version of the admin log showing who input and edited a record and when. (It looks like we will have this information, but IDK how valuable/interesting it would be to users.)

These don't need to be incorporated into the current designs! Maybe can be included in a later iteration if you think it makes sense.

[gissoo]

@thatbudakguy @rlskoeser thanks for the comments:

1. I agree, I didn't before, but then more design principles came to my mind so I sought some advice and I agree with you now, thanks for bringing it up again
2. I agree about the relaxed grid on tablet as well
3. I have written some notes above about "external sources", I think this tells me that my descriptions are too long or overwhelming right now – I wrote: "Depending on how the content will look like on Scholarship Records, External Resources may not make sense on its own – because this page is only about informing the user about what libraries/institutions hold info about this particular document – it's a bit more general than scholarship records (and I want to avoid nesting them) – but if it can be incorporated as part of Scholarship Records naturally with its content then we may not need that page." – can check with the team about this as well and can let them know about what you mentioned regarding the database @rlskoeser
4. I agree with only having the shelfmark on the other pages – but let's not use S&Co as an example here – in general, and visually especially since the site nav and the nav within doc detail are already looking different here
5. The buttons right now are "suggest a new x" vs. suggest an edit to the existing format – we should discuss the wording and whether "new" and "edit" need to be different in the level of the button (because I'm trying to make it helpful for the team as well, where they can easily distinguish when the submission is an edit vs. a totally new suggestion)
6. @thatbudakguy during our meeting when discussing sitemap we did agree on "input date" and the sitemap is only about the public interface.
7. @rlskoeser it's great to know that public notes could be incorporated into the description
8. @rlskoeser thanks for the new thoughts – love the credits page idea
9. @rlskoeser highlighting image/transcription would be super useful and worth the effort - I am ok with starting from and testing with the constraints of a IIIF viewer.

[gissoo]

@richmanrachel @mrustow This issue is ready for you to review – please ignore all the descriptions above. I'll provide all the updated context here: Here are the designs on Figma

1. The designs are for mobile and tablet covering: document details, external sources, and scholarship records (the revised sitemap is on this figma page as reference), also covering the designs for a variety of conditions, for when there is:

   • no image / one image / more than one image
   • no transcription / transcription for one image / transcription for more than one image
   • no description
   • no external resources
   • no scholarship records

2. "External Sources" came up during the ux research phase, as a place where there is a list of the institutions that have the document in their database like FGP or CUDL – RSK has mentioned that we may not have this in the database. Is this possible to do? Or can it be incorporated into the "Scholarship Records" page as one of the sources? Or is it on a different level?

3. Thinking of including a data visualization (that's simple to understand) on the "Scholarship Records" page, but for now I've listed the total number of record types at the top of the pageas a placeholder.

4. We have taken the page on fragments and shelf read out of this issue and as potentially out of scope for now.

5. What should the language be with suggesting a new transcription vs. an edit to an existing transcription? Does having two buttons make sense?

Please let me know your thoughts and if you have questions – my goal is to revise and close this issue this week. Note: these are wireframes, just covering the following aspects of the designs:

• [x] content structure
• [x] language and labeling of content and functionalities
• [x] page layout – mobile
• [x] menu/side bar position on page – mobile + tablet
• [x] image option menu position on page – mobile + tablet
• [x] grid – mobile + tablet
• [x] page layout when any field is missing, e.g. images – mobile + tablet

[richmanrachel]

Hi @gissoo - hopefully I'm reading these correctly (as this is a new genre for my eyes to adjust to)!

1) The main question that comes to mind for me is who is using the mobile site? Is it mainly curious interlopers or @Marina on the train to Princeton? This question was prompted by the placement of the clusters and editor information. If it's casual users, I think the current layout makes sense to have cluster information first. If it's mostly experts, then I might put it at the bottom?

2) "External Sources" does seem to be in the right place, though I think it's only useful for some collections right now. (We can't link to FGP, for example, b/c they require you to log-in to the site). It may be possible to integrate into "Scholarly Records" as an unpublished description/mention of the document.

3) What do you mean by a "data visualization" for scholarly records? I do like that it includes a preview number - I would keep this regardless (because it helps me see at a glance how often others have touched it).

5) As for whether we have two buttons or not, I think that depends on how transcriptions will function on the backend. @rlskoeser - do we have a plan for whether they're staying on bitbucket? If descriptions and transcriptions live in different places, two buttons could make sense, but if everything comes to be located on "our backend" then it should be unified under a "Suggest an edit/description/transcription" button.

Two additional questions;

• What are the orange boxes?
• Is it possible to use a different font, by chance? I'm having a hard time reading this one.

[gissoo]

Hi @gissoo - hopefully I'm reading these correctly (as this is a new genre for my eyes to adjust to)!

• Thanks for the comments, @richmanrachel!

1. The main question that comes to mind for me is who is using the mobile site? Is it mainly curious interlopers or @marina on the train to Princeton? This question was prompted by the placement of the clusters and editor information. If it's casual users, I think the current layout makes sense to have cluster information first. If it's mostly experts, then I might put it at the bottom?

• If we decide to change the order of information it would be changed on all devices. I strongly advise against changing the order of information based on the device on which it's displayed, it would prevent us from maintaining a consistent experience which would prevent the user from learning how the site works and remembering where to look for specific site content. Anyone could be using the mobile site – the global mobile traffic is projected to go up to 56% this year (from 52% in 2020), and there is also a similar data when it comes to students using mobile sites. Another important point about mobile sites is that down the road when the site is publicly launched and announced to the public, on Twitter for instance, for many the mobile site would be their first experience of the site.

2. "External Sources" does seem to be in the right place, though I think it's only useful for some collections right now. (We can't link to FGP, for example, b/c they require you to log-in to the site). It may be possible to integrate into "Scholarly Records" as an unpublished description/mention of the document.

• Thanks for sharing!

3. What do you mean by a "data visualization" for scholarly records? I do like that it includes a preview number - I would keep this regardless (because it helps me see at a glance how often others have touched it).

• Glad you found it helpful – What I mean here with data visualization is using geometric shapes that contrast in length or size with labels to communicate the numbers for each category instead of using only numeric values – so that it's not solely dependent on the numbers and text being read and to be an effective point of entry to the list view on that page. But again these will be tested as well during usability testing.

4. As for whether we have two buttons or not, I think that depends on how transcriptions will function on the backend. @rlskoeser - do we have a plan for whether they're staying on bitbucket? If descriptions and transcriptions live in different places, two buttons could make sense, but if everything comes to be located on "our backend" then it should be unified under a "Suggest an edit/description/transcription" button.

Two additional questions;

* What are the orange boxes?

• the orange boxes signify what is different on each screen.

  • Is it possible to use a different font, by chance? I'm having a hard time reading this one.

• These fonts are only being used for wireframing purposes, we won't keep them at all. Are you talking about the font that is used to show information like the editor information? Or the one used under "Description and "Transcription"? – If it's the former I can change it for the future wireframes so you can read it easily but the latter is not actual text, it's to visually communicate the low-fidelity aspect of the designs.

[mrustow]

1. "External Sources" came up during the ux research phase, as a place where there is a list of the institutions that have the document in their database like FGP or CUDL – RSK has mentioned that we may not have this in the database. Is this possible to do? Or can it be incorporated into the "Scholarship Records" page as one of the sources? Or is it on a different level?

True that we don't have this in the database currently. It might be either very easy or very difficult to provide the information depending on how granular we want to get, but in most scenarios it will be very easy. There are a few issues here:

• we can signal when external information exists. We have a spreadsheet of FGP metadata, for instance, so we know what has info and what doesn't.
• for CUDL, we can link directly.
• even for FGP material, the login problem is likely to disappear in a couple of months as they migrate their database to the National Library of Israel, which I believe is open access. I'll know more in a couple of weeks.
• there are other, minor collections but they should all be straightforward open-access.

2. Thinking of including a data visualization (that's simple to understand) on the "Scholarship Records" page, but for now I've listed the total number of record types at the top of the pageas a placeholder.
3. We have taken the page on fragments and shelf read out of this issue and as potentially out of scope for now.
4. What should the language be with suggesting a new transcription vs. an edit to an existing transcription? Does having two buttons make sense?

Definitely. "Add a new transcription" or "Suggest an edit to an existing transcription" — or less wordy depending on context

I'll write more later.

[gissoo]

@mrustow thanks for writing! This is helpful!

[richmanrachel]

Hi @gissoo - here are the comments Marina and I have from working together:

• For documents that have transcriptions already, we don't need "suggest transcription" as a button.
• In thinking ahead to adding people, we would love named entities to be bolded and linked in the description.
• We're concerned about "Cluster Name" - does this mean we're privileging one cluster over another? How do we determine what counts as a cluster? This is obviously a big can of worms that we probably need to discuss in depth at a meeting. We might even need to include the Geniza Advisory Board to figure out how tagging/cluster search should work.
• MR prefers separate buttons for suggesting descriptions vs transcriptions so they stay contextual. But could we change the language to "Suggest a Description/Edit" and "Suggest a Transcription/Edit"
• We would like "Suggest a Tag" to be added.
• Could we also have "Suggest an Image URL" too?
• We love "View Entire Fragment"
• As for External Sources, MR wants to talk through the contingencies at a meeting.

[gissoo]

Hi @gissoo - here are the comments Marina and I have from working together:

* For documents that have transcriptions already, we don't need "suggest transcription" as a button.

• great!

  • In thinking ahead to adding people, we would love named entities to be bolded and linked in the description.

• I'll ask you about this at our meeting.

  • We're concerned about "Cluster Name" - does this mean we're privileging one cluster over another? How do we determine what counts as a cluster? This is obviously a big can of worms that we probably need to discuss in depth at a meeting. We might even need to include the Geniza Advisory Board to figure out how tagging/cluster search should work.

• I'll ask you briefly about this at our meeting.

* MR prefers separate buttons for suggesting descriptions vs transcriptions so they stay contextual. But could we change the language to "Suggest a Description/Edit" and "Suggest a Transcription/Edit"

• If we are only showing the button for transcription when the document does not have a transcription then "Suggest a Transcription/Edit" wouldn't make sense because there is nothing to edit, correct?

• Also, are you thinking to only have a button for description when a document does not have a description? Or it's the only for the transcription we're doing this?

* We would like "Suggest a Tag" to be added.

• I'll add to the agenda to make sure the dev team is also fine with this.

* Could we also have "Suggest an Image URL" too?

• I'll add to the agenda to make sure the dev team is also fine with this.

* We love "View Entire Fragment"

* As for External Sources, MR wants to talk through the contingencies at a meeting.

• Great!

[gissoo]

Conclusions from the Geniza meeting on April 1:

• Paginating the image with transcription is great, side-by-side layout is great, and seeing transcriptions by default is necessary.
• Agreed to keep the "External Sources" page as is but rename it to "External Links"
• Linking entities from within descriptions is difficult and out of scope for now – possible solution for when those entities are identified is we can have fields at the top of the page along with other metadata and link to the pre-populated search results page for that entity. This will be reflected in the designs once we have identified those entities and once we have decided on the language for the fields.
• We'll get back to the question on cluster later – Marina is assuming that documents belong to more than one cluster. We’ll get back to this – GD thinks we should try to avoid that from happening.
• There needs to be some decisions made regarding user tagging before reflecting in the designs: Whether the tag that a user is suggesting will be public, and incorporated into the database or not?
• Talked about "Suggest an Image URL" – dev team is concerned to be adding too many features for suggestions – RSK noted it would be good to come up with a more generalizable solution where the suggestion button is more generic and would link to email (potentially with a pre-populated email subject she noted later) that would be easier to implement. Designs will not be reflecting this till we have made some decisions on what that button can encompass and what it would be called.

This issue is ready to be closed.