Iāve been thinking for a long time about the advantages of creating a browser plugin for SuttaCentral that would implement some of the suggestions made for the site but for whatever reason will not be implemented. Here is the list of things I have come up with that might be possible:
Checked items are working
Iām not 100% confident that all of these could be implemented, but it gives you an idea of what might be possible.
And by ābrowser pluginā I mean a plugin you would install in Chrome/Firefox.
The major question, though, is if there are folks with coding skills who would like to help out with this.
Thoughts?
Perhaps we could @ any users we know who have the coding skills needed who might be interested.
ā¦ so too the sentient beings who have the noble eye of wisdom are few, while those who are ignorant and confused are many. AN1.337
In all seriousness, how it behaves with AN suttas would be interesting. Even removing AN completely from the pool would make sense for this, I think. Unless you think getting random one liners like this is interesting (it well might be!)
Yes, so bringing things back to the idea of a pluginā¦ If a random sutta button is built into a plugin we can mess with it all we want without having to consider the impact to the main site. In a plugin we can cater to the power user without worrying about the impact to the broad base of the main site. (BTW, Iām actually not really into the random sutta thing, but lots of folks are. Thatās the great thing about putting it into a plugin.)
Hi, thanks for the suggestions, let me just comment on a few.
yes, I think itās unlikely weāll launch more than dark/light themes, although we might improve these. Basically color themes are easy to get 95% right, but really fussy for the edge cases, so it could well be useful for individualization. Since colors are governed by a limited set of variables, itās trivial to make a theme. In fact you could easily make a theme builder and let people define their own colors.
If there was a simple CSS implementation of this, which could be activated via hotkey or via the settings panel, Iād listen.
Thatās a great idea, although I would be open to further native improvements. Maybe if you explore this let us know if there are any that you think might be useful globally.
Yes, we wonāt implement this.
I am open to changing the view settings, although horizontal scroll will always be necessary depending on screen width. If someone can design a better way, happy to consider it. But we donāt have developer resources at the moment.
Yes, we would not do this.
Hmm, maybe we would do this. I dunno, it feels like more complexity to do something thatās easy enough. But maybe for mobiles it would be better, so yeah, if there was a simple and lightweight option Iād consider this.
Nope.
Hmm. Our overall development priority is to deprecate legacy translations and promote segmented translations. So Iād be more open if this was a simple alert: youāre on a legacy translation, and yes, a segmented translation is available.
(For those new to this, just to repeat: the only reason we have multiple translations is that in the past there was no single set of good translations, so we just got what we could. Most of the legacy translations in English are not all that greatāalthough of course there are exceptions. Weāve supported translations from more translators than any other site, but I must confess there comes a time when I am less than enthused about spending years improving translations only to send people back to less accurate versions, sorry. People get into the bad habit of comparing translations to find the one they like. But the reality is that when a new translation is made, the translator is well aware of the old interpretation and changes it deliberately. And unless you know Pali well, you really donāt have a basis for judging the work. I donāt know how many times people have said to me, āI really like the way X translated Yā, but Iām, āYou might like it, but thatās not what the Pali says.ā And if you do know Pali, then you should be looking at the Pali. Rather than comparing translations, I highly recommend sticking with the segmented translations, checking the Pali with the lookup tool, and when you have questions, ask them here.)
This is a bit complicated, let me comment on that issue.
Yeah, probably not something weād implement. Better for a browser extension.
Umm, yeah, Iāve given some thought to this over the years, or else ārecommendedā and the like, but nothing has really tickled my fancy. Iād be open to something if there was a strong and clear proposal. But yeah, unlikely weād do a ārandom suttaā button.
Yeah, again unlikely weād do this.
Iām happy with our current navigation.
Iām using Papaly for this, TBH it could be improved from a technical point of view, but it does the job.
Thank you Bhante for looking at these. I want to be clear to you and anyone else reading, I support a conservative approach to including features into the main site. Most of the things I listed I donāt thing should ever be considered for the main site.
There are several āhacksā Iām using currently either through Stylus, TamperMonkey, or bookmarlets. My thinking is that a dedicated plugin could make similar things available to more people who might not have the skill/interest to use these tools.
Indeed. That was on my mind.
Iām super happy with the hotkeys we have developed so far, and Iām honestly at the end of my ideas for things I believe will be really useful. My thinking with this would be for non-English users to be able to change the hotkey to something easier to remember, or more importantly, using keys in the non-English keyboard so they donāt have to switch back and forth to use the hotkeys. In an app (like VSCode, etc) I love the ability to have custom hotkeys. But I donāt think itās something useful enough to try to code into the site, for various reasons.
I mean, thatās just not true, is it. There is no reason the settings canāt flex vertically like most things on the web. Any way, thatās really a discussion for a different thread.
Yes, Iām fully on board with that.
Iām also supportive of that view, despite the fact that it would seem my Citation Helper App promotes the opposite. I include links to alternate translations in my Daily Sutta Emails not so people can do comparative study but because I know there are folks who are fans of say, Bhante Bodhi or Ajahn Thanissaro, who would prefer to read their translation if one existed.
Iām also super in favour of removing the 100 y/o translations from the site.
But in a browser plugin you could really go all out with the options. I can imagine someone whoās preferred language might be Korean, but because of the general lack of Korean translations they spend there time on SC set to English. Having a notification where there is actually a Korean translation might be welcomed.
And then there are potentially lots of other edge cases. For example when I am selecting my sutta of the day, I always want to know if there is a translation by Bhante Bodhi just so I can give some variety when possible (not that I always go with his, but I like to know when they exist)
Part of my reasoning for a plugin is that it might be a breeding ground for new features to get hammered out (pardon my mixed metaphor).
I am too!!!
But there are often people complaining about it for one reason or another. A browser plugin could offer multiple different navigation schemes.
Indeed. My idea situation would be that people might come forward to help with coding things in a plugin and then move on to helping with the site. That way people could get familiar with the environment hopefully without derailing the main development.
And if it wasnāt clear, Iām hoping people who are interested in working on a browser plugin could step forward.
Sure there is, itās so that you can see the settings panel at the same time as the text for which youāre changing the settings so you can see it in real time.
A lot of people have very restricted vertical space on their devices. TBH Iām often startled at how people use their computers with multiple bars at the top and bottom. On a 13" laptop screen, you can lose a lot of actual on-page space very quickly. Detecting this is hard, and adapting it for different form-factors is a time-consuming job. Horizontal scrolling is a common UI feature in modern web design, and it solves these problems neatly. I agree, the current implementation could be improved, but not by taking up vertical space.
Indeed. If it turns out thereās a neat solution we could definitely look at importing it.
I come to SuttaCentrral to read Bhante Sujatoās translations, essays, and notes. I donāt compare other translations because I donāt know enough Pali to assess anything other than whether a translations fits pre-existing beliefs I might have. Not a good reason to pick a translation.
I love all the notes Bhante has added. That has greatly increased my understanding of the suttas.
And I love that I can bring up the text in Pali when reading Bhanteās translation.
There is nothing beyond those things I would use. And I fear more options might actually make the site harder to navigate.
I love that there are people like you, @Snowbird, thinking about how to improve the site. I value your input and the contributions Iāve seen you make so much. With SuttaCentralās interface, I feel less is more.
To be honest most of what you outlined above doesnāt appeal to me in the slightest- except fixing the navigation. Iāve tried to be ok with it. Honestly I have. 5 clicks to get to a sutta in DN (and I have to know which vagga itās in )
I guess what I meant was that there is no technical reason they canāt, not that there might be an advantage to the horizontal scroll. I didnāt realize/remember you were hoping to let people see the changes to the view as options were changed. IDK. There are lots of situations where clicking on those options donāt change anything at all, especially if you are looking at legacy texts. Anyhoo, thatās probably a discussion for a different place.
Oh, I guess a couple things come to mind. One is that developing an alternate system could be a good real-world coding project for a student. It is, as you know, a tricky problem to solve. Iād even say that multiple alternatives could be created.
Another thought (and I donāt know if itās valid) is that by having the possibility of a plugin, people who donāt like the current system can take up their own cause and create something that works for them and have it be available to others as well.
Absolutely! And just to make it clear to folks, creating a plugin is specifically so more options donāt need to be added to the site. Or more accurately, so people who want more options can have them without messing up the current site.
Indeed! The whole point is that these are not appealing to the massesā¦
or that someone might only need one of these things. I certainly donāt need all of the things I suggested.
So, are you keen to take up Bhanteās offer of a world of pain? Can we test my theory that talented people like yourself might want to help code an alternative?
ugggh I walked right into that one!
Someone once told me that you would never start anything if you knew how hard it would be. Hereās me thinking; how hard could it be?
Iām happy to talk about it further.
So if I understand the realm of browser plugin development, they are at their core just html/css/js. My thought on alternative navigation schemes was to simply have a plugin-based page that would offer the navigation (maybe using the SC API, although I donāt know if that is necessary) rather than try and co-opt the existing pages. Although maybe that alternate page could have a link/icon to it injected into the site next to the existing home icon.
If that path was taken, development on such a thing could take the form of a standalone āappā and then be added in to the plugin.
But perhaps you could share your thoughts in more detail first?
One thing that @mikenz66 has suggested is a navigation similar to folders and files, although Iām not sure exactly what he has in mind.
@Thanuttamo has expressed that the legacy interface was more to his liking.
I can also imagine a drop-down type system where more drop downs would be added as you selected things.
And some people might like a very simple list of all suttas in a book. Like the āshortcut to all suttasā links but just a simple text list of titles.
What you outline sounds good. I am most comfortable just bashing out html/css/js
Iāve not worked with material design before. I normally use Bootstrap
Iām thinking that I would like to try adding a hamburger menu (to replace the home button) and navigation drawer.
Inside the drawer Iām not sure whether it would be best to have
The idea being that the draw would maintain at itās state at one level up. So if Iād clicked into āsuttaā (in the first example) it would open to show DN, MN, SN, AN etc.
Iām not sure if this makes sense. I am trying to mock it up now. The links I used is where it would take you for each.
I would like to add another āmissingā feature that others may have proposed already: linking from suttas to substantial discussions (as inferred, for example, from a high count) about them on D&D.
Alternatively: linking from Pali terms to substantial discussions about them on D&D.
Sometimes I read a sutta and I wonder about the implications or the interpretation. D&D is the most obvious place where those discussions may have happened (given its SC affiliation and the direct link to D&D from the SC menu system). But currently this sutta/Pali level link between the sites is not made automatically.
This is where things get a bit scrolly, but I think thatās the price to pay to be able to not have to remember whether something is in the book of causation or the mahavaga.
So what I really would like feedback on is which of the two architectures do people prefer?
Sutta then pali
OR
Pali then sutta (as per the mockup)
And by āsomethingā you mean a samyutta, right?
I am completely biased in the direction of language first. And as I stated earlier, Iām also biased towards decisions not optionsā¦ howeverā¦ I feel like with this plugin it makes sense to provide options since we are targeting so called power users.
If it were me, Iād prefer to lead with the samyutta number and drop the SN. Otherwise if you actually know the samyutta number your eye doesnāt have to zig zag back and forth as you look down.
And yeah, itās going to be scrolly. Thatās life.
Will you have chapter numbers for AN?
And will you list books for KN?
Iāve never (?) used frameworks like Bootstrap or Material Design, but I think for something this simple it would be better to just do vanilla JS, no? That way there is a lower barrier to entry on people contributing?
Iām trying to find other navigation examples. There is the one used by Digital PÄli Reader. Itās a very hierarchical one, meaning you need to know where a sutta is all the way down.
It also has a quick link feature that lets you type in the citation and it takes you right there. I think this would be good too and I would probably even use it myself. I can imagine it being easier than modifying the url. It wouldnāt have to be any smarter than that either, meaning if you typed in dn50 you would get a 404 page just like if you modified the url.
In all seriousness, how it behaves with AN suttas would be interesting. Even removing AN completely from the pool would make sense for this, I think. Unless you think getting random one liners like this is interesting (it well might be!)
(and I have to know which vagga itās in 
)
Can we test my theory that talented people like yourself might want to help code an alternative?
count) about them on D&D.
