Display strategies for new data tables

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.

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.

1 Like

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

1 Like

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).

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”.

1 Like

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

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?

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?

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.

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.

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 …

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.

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

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?

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.

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

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!

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.

:grinning:

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

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.

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

Thinking about it a bit more, there are a few issues that I think we need to discuss first:

  1. For the Chinese texts there are the Taisho numbers and the Pali has the PTS numbers which we can display, but for the Sanskrit and other texts, this becomes a little more problematic as there are no standardised numbering systems.

  2. The translations often have none of these numbers so in the example of your screenshot: mn1#25 is mentioned in kv9.3#13. Clicking on these two links will work in the pali texts, but not in the translations. Most likely, failing the correct reference, these will default to the top of the page. So you have to still figure out which English (or other language) parts of the text corresponds together (they are somewhere on the page, but where?)

  3. Instead of displaying the url#id (like MN 1#25), I would prefer to use the same notation as is used on the pages so instead of having very long id’s like t210.5#verse-num-sc95, it could display T 210.5 Verse 95. Especially with ranges in the Chinese this would become extremely long otherwise:
    t757#t-linehead0591c16-#t-linehead0597c25 might be better displayed as: T 757 0591c16-0597c25 or something like that.

Trying to respond while the system is still buggy!

  1. yes. i think we should start with the Chinese and Pali, or even just the Pali, and look at Skt and tibetan afterwards.

  2. It depends on the translation. Ultimately we will have our new translations with matching segments. We should build with that as the primary example, if we can apply it elsewhere that’s good. Maybe we should upload the AN with matching segments in EN/PI to a branch and develop there.

  3. Indeed.

@blake, there is a problem with staging, I believe this is new. See http://staging.suttacentral.net/ll/mn1 . Entries for T 56 and MA 106 are repeated.

While we’re at it, make sure you check out the latest version of the design I posted, I definitely prefer this.

Some thoughts on responsive design for the new tables. Assuming we use the latest design, it is somewhat expansive horizontally. It should have a sensible progression of shifts at any screen size. Here are my thoughts on the sequencing:

  1. As usual, use no-break spaces for IDs and vol/page, as these rapidly become incomprehensible if broken. On the other hand, use soft hyphens for long titles.
  2. The first shift should be title wrapping and/or stacking the text buttons vertically, and/or putting the title on the next line in the 'root" column. (Stacking the text buttons works currently, but requires that they be within the same <td>.)
  3. So that’s all pretty basic and more or less what happens already. Next, we should lose the vol/page column.
  4. Next, lose the description of the relation types, just have a plain connector with a title element.
  5. Finally, lose the table-cell display for the “related” column elements. Instead of having them vertically aligned, just have them collapse to their natural spacing, using display:inline-block, I guess.
  6. If that’s not sufficient for small mobile screens, make the final collapse to a “full-vertical” layout, where both the left and right columns stack all elements vertically. Not sure if this will be necessary, though.

I was just looking at SuttaCentral and noticed that everything is done double here. So such things need to be taken out.
It has to do with the fact that these are mentioned twice in the parallels.json file (I did this on purpose so it is not necessary any more to do any inferences).

“parallels”: [“mn1”, “ea44.6”, “~ma106”, “~t56”]
“parallels”: [“t56”, “~mn1”, “~ea44.6”]

It makes it easier to read the parallels.json file without having to go through all the possible inferences. So just an adjustment to the programming is needed.

I have created a list of all the pts and other numbers that correspond with sc numbers in the pali texts. I realised that for the most of the Taisho texts this does not need to be done because the url#id already show the t-linehead numbers. Only the Dhammapada texts are different because they have sc-verse numbers.
This list only shows sc numbers where other pts or ms numbers are mentioned in the same line also.

ptstaishonumbers.zip (562.1 KB)

1 Like