Here I will develop a MD spec for SC, examining each aspect of SC and describing how best it may be expressed in the MD idiom.
When building the app, we should use the simplest default MD approach wherever possible. We should take care to study and understand the MD approach, and implement it carefully. All aspects, such as spacing, metrics, shadows, animation, and so on, play their part. Reading the spec is an object lesson in a careful, well-considered approach to design.
The essential reference is:
Views
So far we have proceeded under the understanding that we would have distinct views for the i18n and the expert views. But I now think this is unnecessary, especially since we are no longer changing the URLs. Rather, we can choose a set of standard defaults, and allow the user to toggle other preferences.
This would include:
- Show/hide:
- nav drawer (on by default on wide screens, off on text pages)
- Text info (off by default)
- Select a language. This would set the UI for that language, and show the titles, descriptions, and translations in that language. If unclicked:
- UI and descriptions in English
- Titles in root language
- Translations selected via dropdown (as currently).
Navigation
Hierarchy
The navigation in SC is essentially hierarchical. The hierarchy is to a certain extent determined, since it represents the traditional way of organizing texts, especially in Pali. However this is complicated by the fact that we include multiple text sources, which are not part of a systematic hierarchy. Moreover, many of these text sources themselves do not have a coherent inner hierarchy. This is because, like say SA 1, the hierarchy is muddled in the Chinese edition, or because, like most of the Sanskrit texts, we merely have isolated texts, not whole collections. Thus we must extend the traditional hierarchy.
One problem we have to solve is to ensure the visibility of the non-Pali texts. In the two-dimensional old menu, you can see the Chinese and other texts. Even if you never click on them, you know they are there, and can recognize that they have similar names to the Pali. How might we avoid losing this in a one-dimensional nav drawer?
So here’s a thought. What say we dispense with language as a category for navigation? After all, it’s mostly relevant for experts who read the texts in the original languages. Focusing on the i18n aspect for now, it is of secondary interest to a user what the source language of a translation happened to be. After all, we might have exactly the same text translated from different sources. It’s also intimidating: if you don’t know Chinese, why would you click a link that says “Chinese”? So let’s organize the texts semantically, with language info de-emphasized.
In terms of the overall navigation hierarchy, there are many elements, such as nikaya, pannasa, nipata, samyutta, vagga, and so on. Each of these is simple, and constitutes a potential node in the navigation.
The suttaplex
At the bottom of this tree is a “sutta”. (Note that for the purposes of this document, I use “sutta” to refer to any text, including suttas, Vinaya, division-length texts, etc.). A sutta as represented on SC is irreducibly complex; in other words, it is a cluster of associated data. Typically, the data associated with a sutta consists of:
- original text
- multiple translations
- parallels data
- ID
- description
- reference info, i.e. vol/page, etc.
Just because I love jargon, I’m going to refer to this as a “suttaplex”. Nifty, right? Note that the “suttaplex” is all the info for one sutta, a “suttaplex list” is a list of suttaplexes.
The critical thing to remember is this:
- Everything in the hierarchy above the suttaplex is simple, whereas a suttaplex is complex.
This understanding shapes the overall direction of the navigation and structure of the app.
We end up with three kinds of thing. These correspond to MD components thus:
- Hierarchy = Nav drawer
- List of suttaplexes = List
- Text pages
We can conceptualize this as three columns:
| Nav Drawer | Suttaplex list | Text |
| ---- | ---- | ---- |
| ---- | ---- | ---- |
| ---- | ---- | ---- |
The nav drawer includes the hierarchy down as far as the vagga. The suttaplex list includes the list of suttaplexes. This replaces the “(sub)division” and “details” views in the old site. The text includes the text and/or translation.
Let’s look at each of these elements individually, then consider how they work together. Click on the links for detailed info:
Navigation flow
So now we have looked at the three essential elements of the site content, let’s consider how they fit together.
Functionally, this would work thus. First you navigate to the appropriate level of the hierarchy in the nav drawer. You click on a division, pannasa, nipata, samyutta, or vagga, etc., and the relevant suttaplex list is called up. You can then scroll to the relevant sutta, view the parallels if you like, or select the text.
How should this be implemented?
Mobile
The Suttaplex list should be on its own page. This is essential in order to make full use of the screen width. This has the disadvantage that you cannot navigate directly from sutta to sutta, but have to go to an intermediate sutta list page. Having said which, this difference is probably more theoretical than practical.
Wider screens
For wider screens, MD allows, for desktop only, a “cascading nav drawer”. Clicking on an item in the nav drawer opens a second panel, expanding the nav drawer horizontally. On a wide screen, this could be displayed at the same z-index as the nav drawer and the text, i.e. they all literally sit side by side as three columns. I don’t think a cascading nav drawer as such is quite right, since what is expanded is a complex list, not a set list of items. Still, it is not too dissimilar.
Here’s a mockup of that.
In somewhat narrower screens, such as tablets, the nav drawer and sutta list might be an overlay on the text.
However, this view would not work at all on mobile. So to keep development simple we should probably begin by developing for mobile, using a separate page for the sutta list view. At least we can be sure that this will work anywhere. We might consider implementing it as a cascading view later, if it seems useful.