Create a low fidelity mock up of a document detail page to communicate the content structure on the page to the project team

[gissoo]

• Design the structure + nav of all the pieces that belong to this section in this issue
• Include preliminary UI – e.g. potential position of features and content on the page.

Here is the link to the document detail view

Note:

• I have placed an orange "note" on the spots that make each screen different from the one next to it to make it easier to view the variations.
• I have added notes in blue where more context was needed. Please read.
• The decisions in these designs will need usability testing.

Description:

• Designs include:

  1. Everything discussed in the "Document Detail View" on the sitemap, and nav to "Scholarship Records"
  2. Variations with the side nav: horizontal and vertical (act as tabs)
  3. Variations with the image controls: top and bottom
  4. Exploration of introducing the user to "fragments" and "documents"
  5. Transcription view

• Designs do not include:

  1. interface for "Explore Fragments", "Suggest Description", "Suggest new Transcription", "Suggest an edit", "Scholarship Records", "External Sources", and "Shelf Read".

• Context about the page structure:

  1. After exploring more, I am leaning towards a page structure where the page wouldn't get too long and everything won't be on one page. This structure makes it easier to navigate through the information.
  2. I feel strongly that the description and the image should be immediately accessible so they are on the landing page.
  3. I also currently feel strongly that the transcription would be by the image, it's the most intuitive but needs usability testing.

How the proposal/idea can fail:

1. The image controls may not work in the way I hope depending on the tool we use.
2. The horizontal nav bar may not be a good design if we happen to add more tabs.
3. The interaction/flow from "Transcription" to the landing page may not work if we are limited somehow.
4. The left side of the page may not work if that part of the page can't be scrollable by any chance.

Note: I probably did more than you needed here, but couldn't stop as I already got into it. We don't have to agree on everything right now.

Questions:

1. Does the idea and/or the design make sense to you? If not, please say why
2. Is there anything that you expected to see and is missing?
3. We don't have to agree on everything at this point. Let me know what you specifically need right now and we can agree on those first.

Once you review, I will ask Marina and Stephanie to review as well.

[gissoo]

@rlskoeser @thatbudakguy this issue is ready for review.

[thatbudakguy]

1. all of these designs make sense to me!
2. i think i see pretty much everything i expect, except the parts from the sitemap that you already noted aren't represented here.

3. the only (potentially) major thing i want to raise at this point is how to replicate the side-by-side look of this UI on mobile. it seems like the mobile UI would need to be quite different in order to accommodate everything, and we might need to compromise in some way on having the transcription or description next to the image, which is a shame. but i'm sure you can think about this more and come up with something - just mentioning because it's worth considering at this point (in my opinion).

   other notes...

   • about the horizontal vs. vertical nav menu, it seems like there are benefits and drawbacks to both...in vertical, the text tends to wrap unless the menu items are very short. but in horizontal, as you noted we may not know how many items are there or run out of space. this seems like a good thing to usability test.
   • thanks for the yellow "notes"! they are super helpful.
   • i saw that in one of the mockups, the fields on the document are labeled in bold (e.g. Shelfmark above the shelfmark), but most of the other mockups don't have this. i don't know whether this is helpful or not – maybe it's obvious from context what the shelfmark is, or maybe it's helpful to have the label. this seems like another good thing to usability test/ask the team about (or maybe you already have?)
   • overall, this UI feels like an application to me and a bit less of a web page (e.g. I expect it to fill the screen). this isn't bad at all, just maybe a somewhat new thing for us. i do worry a little bit that it implies a certain smoothness of transitions and other interactions, which it might be tricky for us to achieve without using a lot of javascript. if we were building it using a library like react or vue, we could achieve something very close to a "web app" where there are no full-page loading events, but we're not planning on doing that as far as i know.
   • related to the previous; these UI mockups remind me a lot of google's material design UI. I know they're obviously not final, but if we do want to achieve this look, maybe it would help to actually use parts of that library or one like it. for the record, I think it's a good look! not opposed at all.

[rlskoeser]

1. in general the design makes sense to me. A few things:

   • I wasn't quite clear as to whether the nav you're showing in vertical and horizontal options specific to this document or site wide. (Some of them seem specific but some don't so I wasn't sure.)
   • I am concerned that the transcription text is not visible without an additional click. I understand about not wanting the page to be too long, but I think transcription text is important enough to show by default.

2. I would like to see some examples of documents without images. It's not obvious to me how this design will adjust for that (although maybe it is a simpler case?). Also wonder about documents without transcriptions. We may have a lot of combinations of these (image, no transcription; transcription, no image). It also looks like the example you're showing has a particular long description; I've seen a lot that are very short. Have you looked to see what the typical length is? Does that matter for this design? Also, in the database we will have more structured information available for at least some documents (people, places, etc). Are you thinking about where to include them? (I don't know how important they are to show first, just trying to think about what might be missing here.)

Thanks for including the possible ways this could fail. For number 2, I'm curious if you have a sense of how many nav elements is too many and when we would know what they are, or whether it's something we might find ourselves expanding. For number 1 and 3, I think it depends on which IIIF viewer we decide to use and how much time we want to invest in customizing it. It would be helpful to come up with a list of requirements and wants for the viewer to help us make that decision.

Thanks for highlighting the variations. Feedback on some of those:

• I will always vote for leaving the label off fields that are obvious without; I think document type and dates probably don't need labels, but hopefully your research and testing will tell you which ones are important/necessary.
• I wonder whether editor & translator belong on this page; I was thinking of them as part of the scholarship records, but from recent discussion about the admin interface it sounds like it is pretty important to know who has worked on something.
• I like the fragment intro ideas (although not sure I understand completely). It is possible to display small thumbnails of the actual fragment images, although they would likely include the background image around the fragment (I can't think of an easy way to get rid of them).

Like Nick, I'm curious about how this design would need to change to work on mobile.

[gissoo]

@thatbudakguy @rlskoeser thank you both for writing, your comments are super helpful – before I respond to your comments would you please take a look at the list I created of the decisions that need to be made for this section so that you can tell me if the list makes sense to you and what you need from me more immediately (from the list) as I’m revising and thinking about the doc detail view? You had mentioned building a rough interface for the project team to use iirc. How can I help you achieve that goal?

Please also tell me what parts of the content or what functionalities you want me to focus on too if applicable – because the list I have created would apply to all the content and functionalities.

[rlskoeser]

@gissoo thanks for working on a list of decisions. Some questions:

• which of the things you have listed need to be decided in the current phase? It looks like some things on your list apply for the final/full design for this page
• I'm not sure what "explored" / "can be explored more" mean exactly. Does "explored" mean something is finished? Does "can be explored more" mean that you intend to work on these things more, or only that you will work on them more if there is something that needs/merits more work?

In terms of implementing a preliminary document detail page in the short term, I think what I need is the content that should be displayed on the page, in what order, and any language and labeling. (Looking at your list again, I wonder if some of this falls under "content structure", and now I'm not sure what that means either.) I was thinking that for this preliminary version we would use a standard, uncustomized IIIF viewer to display images when they are available; I don't plan to integrate transcriptions yet because we won't have them in the right format for some time.

It occurred to me today that when you said you would work on a "low fidelity mock up", I expected something more like a wireframe. What you have looks more "designed" than that, if that makes sense — I think this may be what's giving Nick and me some difficulty about which aspects we should be giving feedback on.

Similarly, my confusion about the page vs. site navigation — there's no placeholder or indicator of where site-wide navigation would go (other than the "Geniza" in the corner), and some of the links seem like they provide additional information about the current document, but the others don't.

[gissoo]

@gissoo thanks for working on a list of decisions. Some questions:

* which of the things you have listed need to be decided in the current phase? It looks like some things on your list apply for the final/full design for this page

• @rlskoeser thank you for writing, your comment triggered a revision, I have added these: "menu/side bar position on page", "image option menu position on page", "image option menu navigation". I have kept the "styles for menu/side bar", and "styles for image option menu" – I think "styles" is not what I initially meant.

• Re: what I think is important in the current phase are: content structure, page layout and menu/side bar position on page, image option menu position on page, image option menu navigation.

• Correct, I have listed everything that has to do with this section.

* I'm not sure what "explored" / "can be explored more" mean exactly. Does "explored" mean something is finished? Does "can be explored more" mean that you intend to work on these things more, or only that you will work on them more if there is something that needs/merits more work?

• "explored" means I feel pretty confident on the extent at which I have explored a particular aspect – till I do usability testing and find out what needs to be done – I'm always open to exploring more, but I have exhausted the options in my process to reach to what I have proposed

• I just revised "can be explored more" to "needs more exploration" – it's an in progress mode – I have done some but more can be done

• I have revised "needs more exploration" (the grey) category to "has not been explored" – I have not really touched this part yet even though I have thoughts on it and know what I would try to do with it

Do they make more sense now?

In terms of implementing a preliminary document detail page in the short term, I think what I need is the content that should be displayed on the page, in what order, and any language and labeling. (Looking at your list again, I wonder if some of this falls under "content structure", and now I'm not sure what that means either.) I was thinking that for this preliminary version we would use a standard, uncustomized IIIF viewer to display images when they are available; I don't plan to integrate transcriptions yet because we won't have them in the right format for some time.

• great, "content that should be displayed on the page" is "content structure" and "in what order" is "page layout", and "language and labeling" is exactly that in my list :)

• super helpful on transcriptions!! Thanks.

It occurred to me today that when you said you would work on a "low fidelity mock up", I expected something more like a wireframe. What you have looks more "designed" than that, if that makes sense — I think this may be what's giving Nick and me some difficulty about which aspects we should be giving feedback on.

• yes, I understood that – can lower the fidelity for sure, don't want any visual feedback, even though "page layout" will bring up some conversations on the visual side.

Similarly, my confusion about the page vs. site navigation — there's no placeholder or indicator of where site-wide navigation would go (other than the "Geniza" in the corner), and some of the links seem like they provide additional information about the current document, but the others don't.

• when you say "some of the links seem like they provide additional information about the current document, but the others don't." I'm not sure I understand, everything I have shared is about providing additional information about the current document – In the descriptions that I provided for this issue I did note that certain parts are not done yet (like the content structure and layout of the other pages)

• @rlskoeser this occurred to me, so you are mentioning a placeholder for the nav of the entire site, that to me is separate from this issue, because if I'm providing a placeholder that means I should think through it thoroughly and decide where on the page it would appear – do you agree? Should I make a separate issue on that? That is way different than what I was trying to do here. I have thoughts on the site-wide menu but I haven't fully gotten to it yet. Do you similarly need a placeholder for the footer?

[rlskoeser]

@gissoo thanks for your responses. I thought that was what "content structure" meant, but then I started to doubt myself for some reason.

So "explored" means complete for the current phase of design, but could be revised later based on usability testing or new discoveries?

• when you say "some of the links seem like they provide additional information about the current document, but the others don't." I'm not sure I understand, everything I have shared is about providing additional information about the current document – In the descriptions that I provided for this issue I did note that certain parts are not done yet (like the content structure and layout of the other pages)

I'm sort of thinking of it in terms of narrowing and broadening — the scholarship records gives you more information about this particular document (diving in deeper); but presumably explore fragment and shelf read take you elsewhere (broadening, zooming out) — they aren't specific to this particular document, and could be accessed from multiple different documents. (I'm not actually sure what "external sources" is.)

Why are these links not on your proposed sitemap? That would help me understand this better.

• @rlskoeser this occurred to me, so you are mentioning a placeholder for the nav of the entire site, that to me is separate from this issue, because if I'm providing a placeholder that means I should think through it thoroughly and decide where on the page it would appear – do you agree? Should I make a separate issue on that? That is way different than what I was trying to do here. I have thoughts on the site-wide menu but I haven't fully gotten to it yet. Do you similarly need a placeholder for the footer?

Yeah, I wondered about that as I wrote it — I know it's tricky because you aren't working on that part yet and you don't want to put something provisional because it could be distracting or misleading. The footer doesn't bother me as much... I think it's because I feel like I don't understand how the local nav relates to whatever larger nav we will have (which at least partly relates to my comments above — they don't all feel local to me). I'm willing to ignore / wait on that if you tell me to! It feels a little weird to be designing the "middle" of the site first, but this is one of the parts we care most about and probably needs more attention.

[gissoo]

@gissoo thanks for your responses. I thought that was what "content structure" meant, but then I started to doubt myself for some reason.

So "explored" means complete for the current phase of design, but could be revised later based on usability testing or new discoveries?

• correct – in general it's possible to revise if you also catch any risks or potentialities of it failing – but generally "explored" is when I'm really confident about the options/variations I am showing.

• when you say "some of the links seem like they provide additional information about the current document, but the others don't." I'm not sure I understand, everything I have shared is about providing additional information about the current document – In the descriptions that I provided for this issue I did note that certain parts are not done yet (like the content structure and layout of the other pages)

I'm sort of thinking of it in terms of narrowing and broadening — the scholarship records gives you more information about this particular document (diving in deeper); but presumably explore fragment and shelf read take you elsewhere (broadening, zooming out) — they aren't specific to this particular document, and could be accessed from multiple different documents. (I'm not actually sure what "external sources" is.)

Why are these links not on your proposed sitemap? That would help me understand this better.

• ok ok I understand now...so this is something I was thinking to talk to you about – I also wondered that the document detail view in the sitemap looks different from how I'm proposing the page to be ...this is one of the places that shows how messy this process is – In cases like this it's not till I try variations of the page layouts and content structure (and some conversations that come up, like the point about "Fragments" vs. "documents") that would really change the nav within a section like this. I'm happy to talk irt about this – would love to discuss – have a few proposals going forward on this.

• @rlskoeser this occurred to me, so you are mentioning a placeholder for the nav of the entire site, that to me is separate from this issue, because if I'm providing a placeholder that means I should think through it thoroughly and decide where on the page it would appear – do you agree? Should I make a separate issue on that? That is way different than what I was trying to do here. I have thoughts on the site-wide menu but I haven't fully gotten to it yet. Do you similarly need a placeholder for the footer?

Yeah, I wondered about that as I wrote it — I know it's tricky because you aren't working on that part yet and you don't want to put something provisional because it could be distracting or misleading. The footer doesn't bother me as much... I think it's because I feel like I don't understand how the local nav relates to whatever larger nav we will have (which at least partly relates to my comments above — they don't all feel local to me). I'm willing to ignore / wait on that if you tell me to! It feels a little weird to be designing the "middle" of the site first, but this is one of the parts we care most about and probably needs more attention.

• that's totally fine! I think it's worth creating an issue to just get to explore with the site-wide nav a bit while exploring the doc page – it does matter, it wasn't clear to me that you felt this way about it, and we also didn't mention it in our conversations, normally that's how I feel about things :D (want to know the surroundings and not just the middle part).

[thatbudakguy]

i don't think i have much to add to what @rlskoeser wrote, but as usual we see things similarly: the content, structure, and labeling of this page are the things that i think are most important right now. for me, that translates to numbers 1, 2, 3, 5, 6, 7, 12, 13 in the first section and numbers 1, 3, 4, 5 in the mobile section.

mobile is important to me for every page, and i think we need to consider it as soon as we can. designing for mobile forces you to address many challenges you don't have on a bigger screen, and so in a way mobile is the "most pure" version of something because it's the minimum amount of information you are comfortable with. when i work on styles, i write the styles for mobile first, and then layer on top of that to adjust it for bigger screens.

the nav is not as important for me in the context of this page (although it is important generally). if it makes things easier, i think it's fine to put off the question of the structure and placement of the nav since we don't know yet which pages will be in it.

i could see us testing the document detail page by developing an unstyled/wireframe version based on your designs, and then adding a "view on site" button to the django admin so that we can easily check what the page looks like for any document we have in the database, using "real" data. this page wouldn't have to have any navigation at all (since there's no other pages to navigate to) and would just focus on presenting the content/metadata of a single document. it also wouldn't have any interactions (aside from the IIIF viewer).

[gissoo]

i don't think i have much to add to what @rlskoeser wrote, but as usual we see things similarly: the content, structure, and labeling of this page are the things that i think are most important right now. for me, that translates to numbers 1, 2, 3, 5, 6, 7, 12, 13 in the first section and numbers 1, 3, 4, 5 in the mobile section.

• this makes sense – had to revise mobile so that it includes "menu/side bar position on page" and "image option menu position on page" as well.

mobile is important to me for every page, and i think we need to consider it as soon as we can. designing for mobile forces you to address many challenges you don't have on a bigger screen, and so in a way mobile is the "most pure" version of something because it's the minimum amount of information you are comfortable with. when i work on styles, i write the styles for mobile first, and then layer on top of that to adjust it for bigger screens.

• Thank you @thatbudakguy – I totally agree and this makes sense! I was doing it for startwords, don't know why I didn't do it here!! – This issue should have been made specifically for mobile – will need to revise, the issue is currently too big.

the nav is not as important for me in the context of this page (although it is important generally). if it makes things easier, i think it's fine to put off the question of the structure and placement of the nav since we don't know yet which pages will be in it.

• This is helpful! Thanks. I think it's better if I still propose what would go in the nav because it does impact the content structure. (Also, position of nav does impact the page layout a lot :D so I might have to get into it regardless)

i could see us testing the document detail page by developing an unstyled/wireframe version based on your designs, and then adding a "view on site" button to the django admin so that we can easily check what the page looks like for any document we have in the database, using "real" data. this page wouldn't have to have any navigation at all (since there's no other pages to navigate to) and would just focus on presenting the content/metadata of a single document. it also wouldn't have any interactions (aside from the IIIF viewer).

• This would be great! Thank you, this is super helpful to know.

[gissoo]

Thank you for all of the feedback you have given me here – I have taken them into consideration and have taken another approach – focusing on mobile and lowering the fidelity – I have created an epic with issues that it will contain for the document detail view. I'm going to close this issue, but will come back to your comments as I make more progress on the wireframes.