Merge together?

[olastor]

Hi @benmneb,

first of all thank you for creating this new user interface! For https://pts.dhamma-dana.de/ I was already trying out a couple of months ago on migrating to it to your interface and better data (currently deployed here, with different frontend and data repos, but both are in a sort of "beta" state). I made some changes mostly regarding the data, e.g. updating the data format to a json api, updating the data itself, adding text excerpt preview and adding Dhp-A references to ancient-buddhist-texts.net .

Since we're now both already diverging in the frontend code and especially the data, how about we maintain the frontend repo together? It seems both your deployed version with Github pages and pts.dhamma-dana.de are being used by users, so I think it'd be good to merge in order to avoid confusion and inconsistencies between the two.

Please let me know what you think.

[benmneb]

👋 Could be a good idea! But have you thought about how to get offline usage with the API? This feature is useful for monastic settings where wifi and mobile data aren't reliable.

Also what's the benefit of the text excerpt preview in the results list? It seems like a redundant feature for a converter to have (it already says the language and translator and there's a link to go and read the sutta right there) 🤷‍♂️

I like the idea of removing the middle select box when it's not used, it's much cleaner. I like how you've named the book editions in the results and how the links to translations show the translators name. Adding the commentaries is a cool idea too.

🙏

[olastor]

Great!

Could be a good idea! But have you thought about how to get offline usage with the API? This feature is useful for monastic settings where wifi and mobile data aren't reliable.

Yeah, you're right that's not really possible with the API and it'd be better to have offline usage I agree. I switched to loading individual small JSON files in an API style, because the size of a single JSON map that is kept in the state does not scale very well when the size grows (i.e. new data is added). Then some issues arise, like:

• Before downloading a bigger file of e.g. >2MB it should probably ask since that internet traffic might generate data costs
• Everything needs to be kept in the redux state / memory, which might drag on performance
• If new data is added, everything needs to be downloaded again

Perhaps we could discuss the best solution here, it might be neither the API or a single JSON file (maybe something like IndexedDB?).

Also what's the benefit of the text excerpt preview in the results list? It seems like a redundant feature for a converter to have (it already says the language and translator and there's a link to go and read the sutta right there) man_shrugging

I thought it was useful because

• not in all cases the link opens the exact paragraph (e.g. for tipitika.org and on non-chrome browsers for ancient-buddhist-texts.net) and that way it gives a hint exactly where the page starts in the text
  • (if the ref points to a very long text, then only knowing what text it is might not be enough to narrow it down)
• if there are inconsistencies with the data you can see it by comparing the excerpts from different sources

Perhaps this feature is optional. For offline usage it's definitely too much data.

I like the idea of removing the middle select box when it's not used, it's much cleaner. I like how you've named the book editions in the results and how the links to translations show the translators name. Adding the commentaries is a cool idea too.

Thanks :)

[thesunshade]

I like the idea of removing the middle select box when it's not used,

I agree! I was even going to suggest this.

I wish I could offer a suggestion for how to handle the data overhead. For the converter I created (https://sutta.readingfaithfully.org/) I decided to use Gulp to turn it into a single file. Then those who care can just save the page as a single file. Not sure how well that works on mobile, though.

I wonder if the commentary lookup could be split off into a separate tool. That creates other issues, but there may be two distinct sets of users, one who only works with root texts, and one that works with everything. Except for the Dhp-a, I'm exclusively in the first group.

[olastor]

For the converter I created (https://sutta.readingfaithfully.org/) I decided to use Gulp to turn it into a single file. Then those who care can just save the page as a single file. Not sure how well that works on mobile, though.

In your use case that is I think the right way to do it and should work on mobile.

I wonder if the commentary lookup could be split off into a separate tool. That creates other issues, but there may be two distinct sets of users, one who only works with root texts, and one that works with everything.

Thank you for the suggestion! Creating separate web apps to save data would be somewhat hacky, but splitting the data up into smaller chunks that can be optionally loaded would be a nice feature, I think. I imagine it could open a popup the first time to visit and ask you to select which data (splitted by something like datasource or book-set) to download. Once downloaded everything will work offline and you can open that popup again in order to download/update/delete your offline data. I am thinking here of using something like PouchDB for offline storage.

This would add some more complexity to the app, but I can't think of any other good solution that deals with increasing data sizes and offline availability right now. I checked and for the suttacentral data the (uncrompressed) JSON file would be around 5MB and the data using tipitika.org is around 10MB.

Given only suttacentral should be supported, it'd maybe be possible to find ways to save data and compress the JSON map and just bundle it with the web app, but I think a cleaner approach would be to allow for more data to be added in the future (e.g. tipitika.org, links to other translation websites) or downloaded in a modular fashion.