Revise the sitemap and site flow diagram so that the project team would know about the content that would exist on the site and the possible ways they are connected in a more comprehensible way to meet their needs

revised the map structure to make it easier to read
separated "content" from "features"
color coded page hierarchy by levels (0-4)
visually identified "potentially out of scope" pages and content and features
removed details for the two pages that are "potentially out of scope" and new in concept

Questions for you:

Can you read this map?
Does separating content from features make sense to you in this way?
Please read through all the "content" and "features" and tell me, are there items that are categorized incorrectly? If yes, what are they?
Does this map answer any questions for you? What are they? Are there questions it's not answering for you?
Does this level of detail make sense to you?

@rlskoeser @thatbudakguy please read the above, view the revised sitemap and respond to the questions

Also, when calling them "content" vs. "features", "features" doesn't really make sense to me because when on github, everything is a "feature" – what about "capability"? Or do you have any other suggestions?

Can you read this map?

Yes, very readable to me. I'm not sure how much the color coding adds since the hierarchy is already conveyed based on placement within the graph. I like the dashed borders for the potentially out of scope pages. (I think maybe I expect the colors to convey different information, like maybe differentiating kinds of pages? Although I also know for accessibility it's not good to rely on color alone for information.)

On content vs features, you're right that feature is too vague. What about functionality? I wonder about interactivity, would that be more specific / accurate? Does it exclude anything we mean.

Does separating content from features make sense to you in this way?

I think so, although you're not dividing content and functionality the way I would in all cases.

It's kind of nice to show explicitly on the content pages that there is no functionality, although I wonder if there's a more efficient way to indicate that. (This is where I might think of using color-coding to indicate content-only pages.)

Please read through all the "content" and "features" and tell me, are there items that are categorized incorrectly? If yes, what are they?

On browse results, I would consider these content and not functionality:

citation/scholarship checkmark, fragment thumbnail

I'm waffling on whether keyword highlighting is functionality or not, maybe that one is fuzzy. I'm not sure what contextual FAQ is yet, but it sounds like that is correctly placed.

My list for search results is basically the same, except also transcription checkmark which you put as content on browse but feature on search.

I'm not sure what "keyword count in each cluster's description" and "keyword count in each cluster's transcription" are in the search results.

On document details: I think transcription belongs under content (unless I'm misunderstanding what you mean); image thumbnail and link to citation/scholarship would also be content.

On Citation/Scholarship records: I think it's also fuzzy whether the dataviz is a functionality vs strict content; leaning towards calling it out as functionality even if it isn't interactive because it's a synthesis we need to generate, vs. just outputting content from the database (with minor adjustments: excerpt, checkmarks to me are still content and not functionality). I don't know what "send scholarly work" is exactly, but it does sound like functionality and not content.

Does this map answer any questions for you? What are they? Are there questions it's not answering for you?

I'm not sure what questions this chart answers because I think I already had a fairly good grasp of the structure you were proposing before.

One question I have that isn't answered (although I'm not sure it should be answered here): this doesn't tell me what the contextual FAQ is or why it's only some pages.

Another question: why are browse results and search results different? I think it's because they are really "browse clusters" (or maybe cluster detail? is this the display of one cluster?) and "search documents" but that isn't clear in this diagram. I mention this because when we're building the site it matters which type of object (cluster, document, fragment) we are listing or displaying.

Does this level of detail make sense to you? Yes

building on rsk's answers...

exact same as RSK; it's very readable but I feel like the color doesn't add anything (the hierarchy is already represented visually) and I half-expect it to mean something else. dotted stuff for out of scope is great.
yep, makes sense. the term "feature" doesn't bother me, but "functionality" or "capability" are equally good (no preference). calling it "interactions" or even just "actions" is kind of interesting also. for content-only pages I think you can just skip the functionality/features/whatever box entirely and have only the content box.
agree with all the instances RSK mentions but nothing else to add.
i think i know what "contextual FAQ" is (although i could be wrong) - i assume that's where certain terms or interactions that we anticipate people having questions about will have a small icon/link that takes you to a related FAQ entry (like for S&Co). i'm interested in an semi-automated way of doing this, so that we don't have to keep track of everywhere we use a particular term (like "fragment") and manually turn all of them into contextual FAQ links. i think there are still tricky questions though about what deserves an FAQ and what doesn't.
this level of detail makes sense.

@rlskoeser @thatbudakguy Thank you for the comments!!

re: colors coding – I was doing that for the project team – it's more helpful because not everyone is immediately familiar with the idea of "levels" with pages – but I have also specified "Level 0" through 4. In the future I can remove the colors in the process for you if you feel strongly it's mainly that I'm trying to minimize the number of customization for each audience.
I like "Functionality" much more – I really don't like "Interactivity" because to me even a link is "interactive" but often it's considered content so it doesn't make sense to me.
@rlskoeser Please tell me more when you say: "I think so, although you're not dividing content and functionality the way I would in all cases." – how?
@rlskoeser to answer this "I'm not sure what questions this chart answers because I think I already had a fairly good grasp of the structure you were proposing before." – I think I want to know if this is a good format to approach the sitemap in the future – I'm trying to use this issue to both converse with you on what sitemap would be most helpful for this project and in general for other projects and to also to use it to revise the geniza sitemap as documentation for the long-term.
Re: contextual FAQ: I can revise and define this as well as the "send scholarly work" – I like @thatbudakguy 's idea on semi-automating it!! – I was thinking if it's a short description about the content/feature it could be displayed there on the same page, but linking to the specific section of the FAQ would be helpful (not just the FAQ page, that's not really where I was going with this).
@rlskoeser Yes! I meant "browse clusters" BUT my confusion is you can "browse clusters" or "search documents" on the same page – what's really different is once you have browsed a cluster and once you have searched a document, therefore I wanted to have the "results" in the labels. how about "Results – Cluster Browse" and "Results – Document Search"?

Note: Once you respond I will close this issue next week by Thursday and will revise the sitemap based on the comments.

@gissoo — would it be worth asking the project team if the color coding was helpful to them? I would expect people have encountered some kind of hierarchical diagram before and would understand it even if they might not know exactly what it means for a website yet. I agree we shouldn't customize these for different audiences. I do feel fairly strongly that the colors are more distracting than helpful.

Functionality seems like a good word choice. Interesting point that even a link can be interactive — that makes sense. I think what we care about from the development perspective is functionality we have to build ourselves vs things we get for "free" based on the technologies & environments we're using, like links in a browser.

Regarding dividing content and functionality: I provided a list of the specifics I saw in my comments. Were there any that you disagreed with or didn't make sense to you?

Yes, this sitemap is a useful format for understanding the site structure you're proposing, and I think it will work well in future.

Your terminology about the browse clusters and search documents labeling is still not as clear as I'd like... I guess the search landing page technically is the browse clusters page. You can initiate the document search or select a cluster from that page. I think including "results" in the label for document search is helpful, but it doesn't make as much sense to me for the cluster browse (because it isn't a search). Is it a cluster detail page? Or browse documents by cluster? This feels like a quibble, but I also remember from other projects that it's really helpful if we can all agree on and use the same names for pages and views when we're creating visual specs and writing code.

@gissoo — would it be worth asking the project team if the color coding was helpful to them? I would expect people have encountered some kind of hierarchical diagram before and would understand it even if they might not know exactly what it means for a website yet. I agree we shouldn't customize these for different audiences. I do feel fairly strongly that the colors are more distracting than helpful.

@rlskoeser After giving this more thoughts I think I feel strongly that it's helpful when quickly looking at them during a meeting, because there can be so many ways of reading maps like this – it's a common practice to color code levels in addition to labeling them with "L1..." – I'll remove it for the dev version since you have that context and don't need the color coding.

Functionality seems like a good word choice. Interesting point that even a link can be interactive — that makes sense. I think what we care about from the development perspective is functionality we have to build ourselves vs things we get for "free" based on the technologies & environments we're using, like links in a browser.

Agreed! will use "Functionality"

Regarding dividing content and functionality: I provided a list of the specifics I saw in my comments. Were there any that you disagreed with or didn't make sense to you?

Those made sense to me – I thought there were more that you didn't mention.

Yes, this sitemap is a useful format for understanding the site structure you're proposing, and I think it will work well in future.

Your terminology about the browse clusters and search documents labeling is still not as clear as I'd like... I guess the search landing page technically is the browse clusters page. You can initiate the document search or select a cluster from that page. I think including "results" in the label for document search is helpful, but it doesn't make as much sense to me for the cluster browse (because it isn't a search). Is it a cluster detail page? Or browse documents by cluster? This feels like a quibble, but I also remember from other projects that it's really helpful if we can all agree on and use the same names for pages and views when we're creating visual specs and writing code.

I wouldn't call that a "cluster detail page" – "Browse documents by cluster" makes sense! Yes!! I agree that we should agree and use the same names – It was super confusing to me in S&Co – I hope we can do that for Geniza – let me give it some more thought.

@gissoo I don't think you should have to make a dev version without color coding. I can live with the color coding.

"Browse documents by cluster" sounds very clear to me!

I was also remembering the confusion of not using the same names for things in past projects and hope we can do better in future!

Princeton-CDH / geniza

Revise the sitemap and site flow diagram so that the project team would know about the content that would exist on the site and the possible ways they are connected in a more comprehensible way to meet their needs #57