Listing pieces of evidences in place URI pages?

[tutebatti]

Connected to #144 and #146, a reason to generate reports is that it is the only way to have access to the detailed pieces of evidences. The visitor seemingly wanted to create reports to read about the different pieces of evidence of a specific place. What would you say, @rpbarczok?

[mfranke93]

Reusing the code from the reports to list the evidences in the same way as in the report would be a possibility. There are some things you should discuss and decide on, though:

• Where would the list of evidences be in the place URI page? Currently, the sections are: Names in other languages, external links (URIs), religions, persons, sources, how to cite.
• The place URI page is at the moment a (relatively) short page with an overview of data. Listing the evidences explicitly will dramatically increase the length. Keep in mind that in the reports, there are usually many filters active. Here, only one filter (the place must match) would be active. For example, for Halab in the testing database, I currently get 141 evidences. Are you okay with inflating the page sizes that much? This also affects where the evidence list would be placed (point 1), because it would need to be scrolled past to get to the rest.
• Related to point 2, the place URI pages for places with many evidences will also need considerably longer to load, as a lot more data has to be collected, calculated, and rendered.

[tutebatti]

Thanks. These are the right questions.

Regarding your third bullet point: I didn't know they were automatically generated. With a growing database, this makes a lot of sense, of course. But I assume there's no easy way to have a similar mechanism regarding generation, deletion, and changes for the place URI pages compared to the reports.

[mfranke93]

I didn't know they were automatically generated.

What do you mean by that? Where else would they come from?

But I assume there's no easy way to have a similar mechanism regarding generation, deletion, and changes for the place URI pages compared to the reports.

You could render them all up front, store them, and serve them on demand. Which does not really make sense, that would just be trading response time for storage space, with a lot of (possibly unnecessary) calculations up front.

[tutebatti]

What do you mean by that? Where else would they come from?

Before thinking about it, I thought they are generated once and stored. Again, with a growing database, this makes no sense of course. So my fallacy.

• Where would the list of evidences be in the place URI page? Currently, the sections are: Names in other languages, external links (URIs), religions, persons, sources, how to cite.

Could you, @mfranke93, please clarify, how exactly the footnotes in the religions list relate to the sources? Sometimes there's more than one footnote. Are these connected to the evidences?

• Related to point 2, the place URI pages for places with many evidences will also need considerably longer to load, as a lot more data has to be collected, calculated, and rendered.

Would it make sense to have a two step process where the visitor first needs to click again some place to list the evidences? What do you think, @rpbarczok?

[mfranke93]

I thought they are generated once and stored.

Now I get what you mean. And in light of that my previous reply sounds very harsh and condescending, so apologies!

By "automatic" you meant "on the fly". Because most content is generated in an automated manner. Even for the start page and other pages with a lot of human-authored content, the end result that is served to browsers is still assembled by the server. And in all cases, this is done on the fly as well, except for the static content that is built into the Docker image. That would be the CSS, JavaScript, and images. Further, the PDF version of the reports. For the HTML version of reports, the content fragment is generated once and stored in the database, but that is still pasted into the rest of the page at the time a browser requests it.

Again, with a growing database, this makes no sense of course.

Yes. See also #8. But I would argue that, even for a static one, it makes sense. Generating all those pages initially and storing them means a lot of computation at that time, and some of the pages might never be needed. The HTML generated is also very verbose (takes up a lot of storage) compared to the template plus database entries that are required to generate the pages on the fly. If we notice that some pages are requested a lot later on, the correct place to handle this would be to turn on page caching in nginx.

Could you, @mfranke93, please clarify, how exactly the footnotes in the religions list relate to the sources? Sometimes there's more than one footnote. Are these connected to the evidences?

Yes. The representation here is very condensed. One time span represented here could come from one piece of evidence, but it could also come from dozens of evidences. All sources related to these pieces of evidence are linked for each time span. We decided on this design because it seemed a better summary of the data than having dozens of partially-overlapping time spans listed.

Would it make sense to have a two step process where the visitor first needs to click again some place to list the evidences?

I think that would be a better place for it, especially concerning the placement and scrolling issue I detailed above. My suggestion would be a link directly under the "Religions" heading: "Show detailed list of historical evidence". This would direct to a separate page (e.g., /place/XYZ/evidence) with just the place name and the evidence list, which would look the same as in the report. Of course, the page would also have a link back to the overview page.

[tutebatti]

And in light of that my previous reply sounds very harsh and condescending, so apologies!

No worries!

I think that would be a better place for it, especially concerning the placement and scrolling issue I detailed above. My suggestion would be a link directly under the "Religions" heading: "Show detailed list of historical evidence". This would direct to a separate page (e.g., /place/XYZ/evidence) with just the place name and the evidence list, which would look the same as in the report. Of course, the page would also have a link back to the overview page.

That sounds like a very good solution to me. I will talk with @rpbarczok soon and we'll let you know what we decided.

[tutebatti]

I talked to Dorothea and Bernd. We can do it as suggested: have the evidences on a separate page.

[mfranke93]

https://www2.visus.uni-stuttgart.de/damast/testing/place/14/evidence

:smile:

[tutebatti]

I also just checked it. Great work, thanks! :+1: Could we add a table of contents? And is it possible to move the short section "Religions" that has a somewhat overview character to the top? (Or maybe there are reasons not to do that?)

Just another remark: On the testing server, before logging in, I have the same problem as #139 while the Add-on "Ghostery" is active.

[mfranke93]

Could we add a table of contents?

Sure. The reason I did not do it from the start is that the main focus should be on the evidences themselves, so I thought it better if they were the first thing. Keep in mind that most of these pages are considerably shorter than the Halab one. But yeah, a TOC is a good idea.

And is it possible to move the short section "Religions" that has a somewhat overview character to the top? (Or maybe there are reasons not to do that?)

Again, the focus on the evidences themselves. The rest is just for reference.

Honestly, this page is 1:1 the HTML version of the report, for one filter (place ID equals the one of the place), and without some of the sections (places, because it doesn't make sense; query description; how to cite (mentioned in parent page)). As such, I kept the order of sections the same as in the reports. Although it ultimately does not matter. If you would like to have the religions first, that is not a huge change to make.

Just another remark: On the testing server, before logging in, I have the same problem as https://github.com/UniStuttgart-VISUS/damast/issues/139 while the Add-on "Ghostery" is active.

Interesting. I was sure I fixed that. I'll look into it, thanks for the heads up!

[mfranke93]

I have now added the TOC and done some minor styling fixes. The current version is on the testing server. Let me know if you still want the religion section first, otherwise I would see this issue as completed.

[tutebatti]

Thank you! In fact, I would put the religion section first: it gives a nice overview. Users not completely familiar with our data structure might be thrown off by repetitions of the same group, e.g. the first two here: https://www2.visus.uni-stuttgart.de/damast/testing/place/114/evidence#religions