Forgot:
âmajjhimanikayaâ (with or without capital, and without numbers) brings no results.
Ang. Sabbamitta, you may be the most thorough person I know!
And in your thorough inquiry of possibility, how would you prioritize each of your findings according to likelihood of user interest?
Physics asserts that the chair I am sitting on may vanish at any moment at the whim of its wave equation. However, my own death is a much more likely event to be experienced before the spontaneous vanishing of my chair. Therefore, priorities are important given our finite existences.
I would completely trust your priorities given your thoroughness.
Actually, I have no idea what goes on in peopleâs mind. To me, anything is possible. Maybe @Aminah is a better person to guess priorities?
Four knowledges: knowledge of the present phenomena, inferential knowledge, knowledge of othersâ minds, and conventional knowledge. --DN33
?
Trust yourself as I do you. I really do.
Thanks for your trust, thatâs very kind. But really, I see myself unable to prioritize these things. Weâve already seen that people approach the Suttas from all possible kinds of angles when we were putting together the example phrases. Everybody has their own approach how they proceed when searching something. You have just seen that Snowbird for example feels lost if he doesnât have a visual overview where he can select from. So people are very different, and I donât know which way of approach might perhaps be a little bit more frequentâŚ
By the way:
As long as thoroughness can be completed with 5 or 6 search entries that might well hold true. I only embarked in this adventure because of your remark
But actually, omitting 1-50 wouldnât help, and seeing this, I tried out more options.
Endeavouring, to save undue strain, if I might roll the original question back a bit and ask Karl to set out the implications (of course, including labour) of handling all the search terms Ang. Sabbamitta so diligently researched ().
I trust no-one is in any doubt that the 50 DN34 results, really ought to be corrected. Beyond that I think all the terms tried are terms we can reasonably expect people to try, and should deliver results. Before having a clearer idea of the insight gained, or need for, or other value from prioritization at the microlevel, my rough instinct would be to treat it as one issue that can be prioritized as a whole against the other things on the to-do list.
To my mind this is really the point to do some good musing over; itâs something Iâve thought about already before this, but it is good to have this concrete experience description. I believe itâs a really complex issue, not least because whatever we do, we want to make sure it is accessible to the blind and partially sighted as possible. I think this is one very good reason to try to design âsearch-ledâ SCV exploration, but of course, other options ought to be considered too to give the most welcoming experience to everyone.
Search is one of the most difficult things to code. It is VERY expensive. It took weeks to get the current search code. Indeed, Google has hundreds of engineers coding search daily. Search seems simple because âGoogle just knowsâ. But that simplicity for the end user requires those hundreds of engineers. I would much rather not make any changes to search because we are still finding bugs in the way it works today (e.g., search results for MN do not sort correctly). Search is so difficult because every bit of seach code affects other bits of search code. If we add more searches, we also have to guarantee that the new search code does not break the old searches.
This is why prioritization is critical. I would simply say âNoâ to âit would be niceâ requests for search changes. And I would even add a Nikaya navigation feature to avoid changing the search code.
Probably the best way to understand the complexity of search is to refer to the Search wiki page. Search bugs/features should be prioritized according to the definition of search documented in the wiki page. If search is not behaving as expected, then: 1) either the wiki needs to be changed (feature) or 2) the code does not do what the wiki documents (bug). In this prioritization, even fixing bugs takes time and extensive testing. Search features make me nervous because search code is delicate.
Lovely; thanks so much for this description.
I guess thereâs âwould be niceâ and âwould be nice.â In one respect all of this is just an adventure into âit would be niceâ, or to put it another way even if no single thing more was done to SCV it would still be an app of great value, so that all additions are just⌠âniceâ.
Honing in a little more though, within the context of the app itself, from my point of view it is very easy to say weâre talking about something more important than a doily. Particularly with respect to your explanation, it may not be the case that the point should be attended to by directly addressing the search functionality, but certainly removing as many obstacles from peopleâs way when theyâre trying to look for fairly basic things at the heart of appâs content, is to my mind worth considering seriously.
Speaking to the specific issue of prioritization, again, given your answer, it seems to me that perhaps a good start point in trying to make this assessment if any of these points should be taken forward is if you rank them in terms of doability, as youâre the only one of us who has any sense of whether some might be easier or more out of the question, or harmonizes more with existing code than others.
Iâm thoroughly sympathetic to why this is such a sensible answer, but I think it does, however, come from quite a different point of view from the âuser storyâ perspective. My suspicion is that only a tiny percentage of users have or will read that wiki page (in fact, itâs only in relation to this discussion that Iâsemi, so farâhave). I think the value of the initial exercise is that it explores SCV as itâs most likely going to be used and helps us to see if, where and how friction points can be ironed out.
Now, of course, there is the approach of just saying, âwell, in fact, all a person has to do to find a specific section of the Nikayaâs is search in the right way!â We can accomplish the Majjhima search Ang. Sabbamitta attempted, by simply entering MN([1-9]|[1-4][0-9]?|50)
. The results are a bit out of order, but then all that would be needed is a find in page (ctrl
+f
)⌠oh, interesting, a new discovery ⌠⌠for some reasons, the sutta IDs arenât findable although everything else on a results page is.
Iâm all up for preaching the gospel of regex, but I donât know that it will win the hearts of too many would be SCV users (moreâs the pity). As I say, I think we can probably yet do some musing over how to facilitate exploration and discovery; maybe the eventual solution wonât be fiddling with search, but it is still useful if we notice the limits of search underscore that there is a bit of an issue with navigating the collections.
Yes. I quite agree.
I normally give out cost estimates after prioritization so that decisions are made from the userâs point of view rather the developerâs point of view. We will need to make many future decisions about search ongoing. I thought it best to simply lay out the costs up front so that we can decide how to perform elective brain surgery. Search is the scariest part of SCV for me. Itâs the kind of code where one drinks a lot of coffee and then goes into a very quiet room for a long time hoping for the best.
I will do what it takes to serve user needs. Regarding search code, even investigation is costly because it requires going into that quiet room with coffee for a long time. It is therefore extremely valuable to have value prioritization since investigation itself is costly.
Yes. If search users needed to read that wiki page, we did search wrong.
The wiki page is really a reference for us as a team to make hard decisions. It is the formal specification for SCV search. The code is an implementation of that formal specification. The users do not need to understand the wiki, but we do.
We donât need to change search code to deliver on what Ang. Sabbmitta attempted on behalf of Snowbirdâs original request.
For example, if groups of 50 are acceptable then I would propose that having the following navigational aid would serve just as well and perhaps even better than typing in a search term. It is essentially the SC left-sidebar, adapted for SCV. Each of the links would bring up the search results for that section:
âŚ
> Majjhima Nikaya sections (Middle Discourses)
* MN1-50 some-descriptive-text
* MN51-100 some-descriptive-text
* MN101-150 some-descriptive-text
* MN151-152 some-descriptive-text
> etc.
There may be better solutions. This is just an example of what would be easier than changing search code. Itâs still a lot of work (1-2weeks) to add this type of nav aid, but it is not search code brain surgery.
Oh dear. That seems like a (simple) bug. I had embedded formatting for legibility and apparently have messed up CTRL-F. . CTRL-F is browser text search and has nothing to do with SCV scary search code.
Ah, I see. This makes good sense.
At my end, knowing what it involves is a critical part of prioritization (Iâve never worried that having all available information it will compromise my care for the user experience, because trying to âadvance the userâs perspectiveâ is essentially the only thing I have to bring to the table).
Sounds like my regular life except without the very quiet room, so Iâd think of that as a bit of a treat!
Neat (i.e. something not very expensive to attend to)!
Apparently Bhante Sujato has been quite busy with sutta content. I just started a content update on the suttas and so far it has found 13701484 files changed just in AN alone.
I will add this update to the Release Plan. All our suttas downloaded from Voice will be obsolete soon.
Sorry for the late reply. Yes there is.
Open the first section. In Other Resources are many links, including the one back to SC. There are also links to alternate translations such as Bhikkhu Bodhiâs. Note that SCV search does NOT search unsupported suttas, so it will only find ârelishing is the root of sufferingâ, but not âdelight is the root of suffering (Bodhi)â.
Click on the arrow at this line in order to expand it:
Then you see this:
Click on the arrow at this line in order to expand it:
And then youâll see this:
Now click on âMN 10 at SuttaCentral.net
â.
Thanks
I expected some think like you click the Sutta Central icon in top left corner.
It is not that important at this stage by the way.
But now you know.
If you really do not have time to listen to Sutta i suggest you first listen to MN42.
https://voice.suttacentral.net/scv/index.html?r=0.6968974683294133#/?search=mn42
Wow! I have never seen this before, it is the ultimate ellipsis:
The remainder of this discourse is identical with MN 41
â<em>thatâs</em>
MN49.25.1
<em>all</em> form
MN62.3.2