On abstracting our model of views

Up till now, the choice of how to present the data on SC has been driven by pragmatism: how to present information in the most convenient way, so you can get where you’re going with the minimum of fuss. And I think we’ve done a good job of that.

However, with the new data structures and backend, I would like to suggest that we consider a more abstract model of views, one that will allow more flexibility and power in how things are presented.

To sum up:

  1. Every ID is both a thing and a meta-thing.
  2. Every thing and meta-thing has a view.
  3. Every view is situated within a hierarchy.
  4. The view is selected according to context.

To explain.

  1. Every ID is both a thing and a meta-thing. By “thing” I mean usually a text, typically a sutta or whatnot. But also, say, a vagga, or any other entity represented by an ID. Each of these, in principle, is accompanied by a “meta-thing” (or things), information about that thing. That would normally be the details page, a list of parallels, a description, and so on.
  2. Every thing and meta-thing has a view. Each of these should be accessible at least in principle, via the appropriate URL. Moreover, the views for things and meta-things should be easily accessible from one another at all times. Currently you can get to a text page from a details page easily, but not vice versa. Also, consider something like verse parallels. We should be able to see these in situ when reading a text, something like the current cross-references.
  3. Every view is situated within a hierarchy. Every view should situate the thing or meta-thing within the larger hierarchy of texts, something I have discussed in a previous post. You should be able to see where it fits in, and to go to different levels of the hierarchy. Moreover, you should be able to traverse up, down, or sideways in the hierarchy from wherever you are. So on a sutta, you can go up to the vagga. From a vagga, back to the previous vagga, or down to a sutta, or up to a pannasa, and so on. And this applies equally for things and meta-things.
  4. The view is selected according to context. Rather than writing the code for one set of views, the code allows for any potential view and navigation. Then we select the view that we want for that context. For example, we could go MN→mulapannasa→mulapariyayavagga→mulapariyayasutta. But that would be boring! So we go straight from MN→mulapariyayasutta by filtering out the stages in between. This might vary, for example, on mobile vs. desktop. Or by bandwidth (slow connections avoid big pages). Or it could be adjusted by user preferences. We already do this to some degree, with both division and subdivision view for SN and AN, for example. I am suggesting that this be generalized, and we develop a UI that works across all these different cases.
1 Like