Display strategies for new data tables

[sujato]

Nice! I’m really liking this direction. The main functionality seems to work great, I’ve tried dozens of pages and they all seem fine, although I haven’t tested the data as such.

it’s actually really cool to be able to switch between details pages, I can’t believe we haven’t done this before!

Here’s some details to have a look at:

1. The new tables aren’t picking up “partially parallels”, but just represents them as ordinary parallels.
2. As for the long bookmarks, in most cases the form these are in is just placeholder and should be changed. The most obvious cases are “t-linehead”, which should be removed, and “verse-num-sc” which should be replaced with “verse”. vagga-gatha-num should also be replaced, not sure what with.
3. In some cases, the long bookmarks are due to the genuine complexity of the publishing history of the original material. I’m thinking of the Skt Mu-Sarv Vinaya, for which we have say : Skt Mu Kd 17 #sbvi128-#sbvi136. Such cases should be retained.
4. One detail that just came up with Ayya Vimala. When looking at the new display, it’s not immediately obvious what the difference is between the “whole text parallels”, which appear at the top, and the verse, etc. parallels, i.e. the ones with bookmarks, which appear underneath. perhaps we should have some way of labelling them, but if so, what? We have to avoid confusion with the concept of “partial parallel” …
5. For some reason I’m not seeing the text button for certain texts. On SuttaCentral for example, neithe Dhp nor Divy show any texts.
6. Clicking on the text link for bookmarked texts should go to the bookmarked URL, instead they just go to the generic URL.
7. I assume you know, but anyway the translation dropdown isn’t working; and also, the title attribute for it is wrong.
8. The CSS for the “connector” breaks on “is mentioned in” in some tables and scale sizes. It also breaks at narrow page sizes. The connector obviously needs adjustment, perhaps you have some idea for a more robust approach here.
9. SuttaCentral is an interesting case: as a “range”, it doesn’t have a title.
10. I’m thinking we should adjust the display of the bookmarks. Treat the hashed portion like the secondary text, (font-size: 0.8rem; color: #767676), and not have a space before the hash. Oh, and use en-dashes!
11. It’s also time we can do something similar with the alternative titles we find In Pali, perhaps elsewhere. Instead of Vekhanassa [Vekhanasa] we should have something like Vekhanassa <span class="alt-title" style="font-size: 0.8rem; color: #767676; display:block" title="Alternative title">Vekhanasa</span>
12. Meanwhile, the vertical alignment needs attention. I’m not sure of the most elegant way to do this in CSS. But typographically speaking:

• In the main “related” section, the top line should all sit on the same baseline (i.e. .root-id, the title (which BTW should have a class, I guess), and the vol/page.)
• The line-height for the tables should be reduced to 1.25. This keeps the info connected, so that whitespace is separating things.

9. The target region for .root-id shouldn’t fill the horizontal space. It should be a button. This can be achieved using display:table-cell, although this further borks the vertical alignment. Nevertheless, we should find a CSS solution for this than add more divs. I’ve made a hacky version that works okay in most places, but it breaks in some contexts and is not the best solution.
10. Load this bad boy up: SuttaCentral I’ll have a coffee and get back when it renders. Display per verse instead. (Full div optionally?) This applies to all the Dhammapadas. While we’re on the topic, we should probably use “Pali Dhammapada” as the dhp title. the ID can stay the same, as it is commonly used.
11. Having said which, the performance generally is great. On pingdom, I’m getting load times under 500ms in the US.
12. getting even pettier: you’ve simplified the borders, but that creates a “notch” where the rounded corners meet. We need to use the more complex form.
13. I’ve more and more come to see that we need a divider between ID and title in captions and headings. And, contra my previous opinions, this should be a colon. Luckily it’s easy to add with an :after.
14. In cases where there is no text, we currently display the “button”, with a title saying “no text available”. Would it not be better to just not have the button?
15. Some pages return a 500 error: SuttaCentral

Anyway, here’s the CSS overrides that mostly do what I want. Again, this just a demo, I’m sure there are more elegant solutions.

relationships_table_overrides.css.zip (634 Bytes)

[sujato]

Something for @blake and @vimala to consider. See http://staging.suttacentral.net/ll/sn15.10

Now, SN 15.10 is listed, correctly, and parallel to Iti 24. They are in fact identical, with some minor changes in the prose section.

We also have SN 15.10#6 as parallel with Iti 24#5. This is also correct, but not necessary, as we already have the whole sutta listed as a full parallel. It begs the question, why is this verse individually identified, while the remaining verses in this sutta are not?

Now, presumably, this is because this verse is part of a set of Dhammapada parallels. Again, this is correct, and in parallels for Dhp#191, it should be listed.

Listing it under SN 15.10 twice is not wrong, but it is a distraction. It’s not the cleanest way of presenting this information. Perhaps we could handle this in display logic: if something is listed as a parallel of the whole text, then filter out additional mentions of it as parallel of a section of the text.

[Vimala]

The corresponding json entries are:

“parallels”: [“sn15.10”, “ea-2.30”, “sa-2.340”, “sa-3.11”, “sa947”, “t765.2”, “iti24”, “~kv1.1#158”]

and

“parallels”: [“dhp#191”, “divy#101.021”, “iti24#5”, “sn15.10#6”, “t210.22#vagga-gatha-num-sc22.17”, “t212.28#vagga-gatha-num-sc28.31”, “t213.27#vagga-gatha-num-sc27.28”, “thag21.1#verse-num-sc1269”, “thig7.2#5”, “uv27#27.34”],
“mentions”: [“dhp#191”, “ne37#156”]

I agree that some display logic would be the easiest way to deal with such cases.

But it makes me wonder if the verse dhp#191 also has a parallel in the other full parallels of sn15.10 like ea-2.30, sa-2.340, etc.

[sujato]

@Vimala

if the verse dhp#191 also has a parallel in the other full parallels of sn15.10 like ea-2.30, sa-2.340, etc.

It probably does, hopefully we can have a Chinese speaker look at such cases in the future.

[Vimala]

The only danger of using display logic to take out such entries is with the partials. This should only be done when it is a full parallel.
In the JSON file, there are some specific and some less specific entries of the same thing. Ideally we would like to become more specific with the partials but this will have to develop over time. For instance, you can have two entries:

A is partial to B

and

A#1-#3 is full parallel to B#4-#9

All this has to be carefully looked at before omitting anything; next to the mentioned paragraphs, there might be more sections in A and B that are partial to each other.

[sujato]

We’ve discussed this before, but I still find myself tripping over terminology!

I had a (rare) moment of clarity. Yes! Exciting isn’t it? I realized that the problem with nomenclature, which had been lurking vaguely in the back on my mind, was not just in the naming of “partials”, but also in the naming of “fulls”. We need to clarify both halves, as it were.

From here on, I vow to use the following:

Partial parallels: the old category, consists of:

1. Resembling parallels: Texts that have aspects in common, where these cannot be further specified by IDs; eg MN 10 and MN 119.
2. Sectional parallels: Where a “section” of one text can be specified as parallel with a “section” of another. A “section” is anything definable by ID’s, up to and including the whole text.

When a partial parallel is specified by IDs and becomes a sectional parallel, it is then usually a type of full parallel. Of course, it’s possible to have texts that are “resembling sectional parallels”!

Ideally we can eliminate the old “partial” category completely.

In addition, we need to distinguish between:

1. Full parallels: Texts that have much in common, such that they appear to be different versions of the same “thing”.
2. Whole parallels: A parallel that relates to the “whole” of a text, rather than one section of it. To this we might add:
3. Ranging parallels: Where a parallel applies across two or more texts.

Thus “full/resembling” is one pair, based on the closeness of the relationship, and “section/whole/ranging” is another set, based on the extent of the related passage.

Okay, so now we can name the two different sections of the details pages; that is, the first part, with “whole” parallels, and the second, with “sectional” (i.e. bookmarked) parallels.

We could use a <th> to define: “Parallels of the whole text” and “Parallels of a section of the text”.

Note that the application of “ranging” parallels is the bug I noted earlier, where, when such parallels are the root text, our details page lacks a caption.

[Vimala]

Sure, but the problem remains that there are a lot of parallels now marked as resembling (with a “~” in the json data), while they should be more specifically marked with ids as sectional parallels.

[Vimala]

PS. Will try to get into the habit of using this terminology

[blake]

@sujato

Perhaps we could handle this in display logic: if something is listed as a parallel of the whole text, then filter out additional mentions of it as parallel of a section of the text.

Okay, it seems reasonable to handle this in the final relationships calculation (this is the same stage where inverse relationships and such are determined). I’ve added a filtering step which filters out any relationship which is a “subset” of an existing relationship. The algorithm I’m using is rather conservative, basically a non-sectional, non-partial relationship between a pair of uids suppresses sectional/resembling relationships of the same type from appearing (at the moment it would not often be logical to have relationships of different types between the same pair of uids, but if there are or will be cases where it happens they should be accommodated).

@sujato

Ideally we can eliminate the old “partial” category completely.

Do we want a change of terminology on the site? For example we could actually say something like “A resembles B”, although I don’t mind “partially parallels”.

[sujato]

@blake

I’ve added a filtering step

great, let’s keep a wary eye out for how this works.

@blake

Do we want a change of terminology on the site?

For now, not sure. The problem, as Ayya mentions above, is that many of the parallels currently specified as “partial” should be clarified as “sectional”, but we just don’t have the data. But in principle, yes, I’d rather use that language. Maybe try it out and we’ll see how it goes?

[sujato]

After taking a break for a day or two, I came back to this design, and something about it bothered me. i realized that, when scanning complex pages especially, the structure was not clear enough, especially in the first column. Here is a mockup that addresses this issue by removing the texts to the far right, similar to how they are today, but retaining the new functionality.

details_mockup_1line.html.zip (1.6 KB)

Here is the i18n version of the same concept.

details_mockup_i18n_1line.html.zip (1.8 KB)

It seems to me that in this form I can scan the IDs and titles much more nicely, without having to filter out the “text buttons”. In addition, they waste less vertical white space. @blake, @vimala, any thoughts?

[Vimala]

I like the language drop-down on the far right. I prefer this over the names of the translators. Also, how would you do that when there are multiple translations? Languages are universal, but people don’t always know who the translators are.

I would also prefer to loose the column that lists the Taisho and other numbers. This information can be found elsewhere. Also it is not always clear what they mean. In http://staging.suttacentral.net/ll/sn15.10, iti17 is mentioned behind iti24 for instance.

[sujato]

@Vimala

I like the language drop-down on the far right. I prefer this over the names of the translators.

These are proposals for separate views, one for the default (expert) view, one for the internationalized (i18n) view. In the i18n view, only one language will ever be used, this is why we can put the translator’s names and do not need to specify the language.

The choice here is between these versions, which place the text buttons on the right, as compared to the version currently on staging, which place them underneath the ID.

@Vimala

I would also prefer to loose the column that lists the Taisho and other numbers.

This isn’t going to change, it’s important in the expert view. Indeed, what we should be doing is working on a more systematic way of integrating the vol/page and ID systems, so you can always go to an ID from a vol/page …

@Vimala

iti17 is mentioned behind iti24 for instance

The title attribute makes it clear. In addition, separating them in a visual hierarchy is important. It is sadly true that it is confusing and unnecessary to have multiple conflicting reference systems, but we didn’t create this mess! The best we can do is to make the proper IDs prominent and encourage people to use them as much as possible.

[Vimala]

@sujato

it is confusing and unnecessary to have multiple conflicting reference systems

True, but then show it on both sides of the equation: also in the left column.
F.i. show T ii 766a04 also underneath EA 44.6 in SuttaCentral

[sujato]

Why? It’s in the caption already, along with the title. I want to keep the left column as clean as possible, and not repeat information. We could, I suppose, put all this information in the left column and not have a caption …

If we have multiple entries there, i.e. when there are bookmarked parallels, are we going to repeat the vol/page info every time? That might be useful, actually, but can we specify that information? In other words, if a sectional parallel points to a passage half way through a long sutta, can we correctly identify the vol/page reference for that passage?

[Vimala]

There are often several entries in the left column, not just one. A verse in the text might be parallel to other verses and also have a different Taisho number. These numbers don’t always seem to correspond to whole documents.

Also, when you scroll down you don’t see the caption any more in long texts.

[sujato]

@Vimala

These numbers don’t always seem to correspond to whole documents.

Right; my question is, do we actually have this information?

@Vimala

when you scroll down you don’t see the caption any more in long texts.

True, but that’s the normal case with headings (unless you use tricky js like Discourse!)

Here’s a quick and very dirty mockup of an “all in the left” view. I have omitted the caption as unnecessary duplication. the main text is on the left, and the bold of the ID and title is intended to sufficiently identify it as the root text.

Note that this approach will probably require a complete rethink of the CSS design. Stacking the info vertically in the left means that a “simple” left item, as in the mockup above, is substantially taller than a “simple” right item. (This will only be an issue in “one to one” parallels; with multiple right items we use rowspan in the left column.)

Currently these are both <td> elements in the same row, which (so far as I know) must have the same height. So it compensates by adding unwanted white space to the right hand column, as you can see in the mockup. We’d probably have to use a flexbox design to get around this.

Here’s an example of the same design with the vertical whitespace eliminated. Do not ask me how I did this, I am very ashamed of it!

[Vimala]

@sujato

Right; my question is, do we actually have this information?

Yes, but not in any meaningful form right now. It will be in the html documents only in the form of <a class="t" id="t0559a21"></a>. So maybe we can write an algorithm in Python to go through those texts and extract the closest t-number to the verse-num-sc that is listed in the parallels.json.

I don’t mind the extra whitespace on the right side as long as all the text is centred vertically.

@sujato

Do not ask me how I did this, I am very ashamed of it!

[sujato]

@Vimala

Yes, but not in any meaningful form right now.

Well, as long as it’s there. Could we extract it and json it?

@Vimala

I don’t mind the extra whitespace on the right side as long as all the text is centred vertically.

Sure, it’s a detail, but we should get them right. Anyway, I wouldn’t worry about it yet, I’m sure there’s a way of coding it.

[Vimala]

@sujato

Could we extract it and json it?

Probably … will look at it when I’m in the US. Not much more time right now.