Display strategies for new data tables

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

That’s great. :triumph: Now can you just make it work on the whole site? :wink:

That’s @Blake’s job. I don’t want to mess with what he is doing there while he is working on it.

Joking! Yesterday I was reading a thread on the crazy demands that bosses make and thought I’d try it out!

image

1 Like

image

4 Likes

To be honest, it is probably just as easy for @Blake to just draw the right number out of the html text when it is needed so no separate lists like these are necessary. It is just a very straightforward bit of python code to do that.

What about cases where we are not in a text? I’m thinking of the Dictionaries, for example. It would be great to linkify all the v/p references there. Would it not be simplest to use a json file for this?

It’s usually not a good idea to have the same data in two different places.

Right now only the PTS numbers of the start of the sutta are mentioned in sutta.csv and this is what shows up in the Vol/Page references in the sutta list of that Nikaya. Inside the text we have all the numbers for instance in MN1 we have <a class="pts" id="pts1.1"> to <a class="pts" id="pts1.6">.
These numbers I retrieved in a csv list (can easily be converted to JSON) and matched them up with the corresponding SC paragraph numbers. However, there are far more SC paragraph numbers in between and that makes those a more precise reference for use with parallels.
Blake is currently working to change the whole system to JSON so also sutta.csv will have to be converted into the new system.

When you have a page that lists parallels, you are not in the text either.

My take was primarily the parallels pages, but yes, Dictionaries would also be good to have linkified. So Blake can either use my list or use a small python script to search for the respective number in the text. The first option is probably a bit quicker loading, but the second safer if our own numbering system changes, even slightly.

When I started working on the parallels, I found that a lot of the cross references did not work any more because our own numbering systems have evolved over time. At least with the pts numbers you know they won’t change: they keep being linked to the same text.
On the other hand, the parallels.json file now uses the sc paragraph numbers for link-ids because these are more precise. So if things change, so should the parallel’s notation.

So just some thoughts on this. Blake can see what he feels is the most appropriate method.

Okay, sure, well let’s wait and see what Blake comes up with.

Ultimately I’d like to move to a complete separation of data and text, using standoff properties; but we’re not there yet.