Question #1: Just with this context, what would you expect clicking on each of these icons to do (languages and filter)? Please consider before you read other responses and give your thoughts below.
Question #1
Before clicking on languages I was expecting to have a list of languages I could select from.
Before clicking on filter I was expecting to have a set of filters I could select from.
Question #2
Languages : It performed as I predicted
Filters : I was given a list of expressions I could manually add to filter my query, instead of buttons to tick.
This is cool. Clicking on the languages icon behaved somewhat as Iâd expected. It presents me with a pre-populated subset of languages relevant to the texts. I expected to see PÄli, Sanskrit, and Chinese as root languages, and English as the translation language. Itâs interesting that you also show GÄndhÄrÄ«, Uighur and other languages that were unexpected as basic search results that would (I expect) output results for the most commonly used languages.
The filter icon is more interesting. There are scope limiters (ex: volpage, author, in) and boolean operators (AND, OR, NOT) which are very powerful. I like this.
However, the filter icon itself is simply a help menu, and the expected response to clicking the filter icon is different than the language icon. The language icon provides direct control via checkboxes, while the filter icon shows instructions that the user needs to think through, create a regex and type it in - an inconsistency in the user experience. Perhaps it may be cognitively easier on the user if the icon and text were different, something like âSearch Helpâ.
Also, perhaps you donât yet fully support grouping of search terms using braces. I tried this and the server threw a âData load errorâ.
The second form of the query may be a little confusing because the precedence and associativity of the operators is not specified. A section in the Help page or menu item with this detail can help us write good search queries with operators.
The obvious cases that should return zero results work as expected.
I just added. This is, in fact, the greater issue.
Great feedback! Iâm afraid you are not alone.
Thanks so much for your detailed response!!!
Search accommodates all documents on the website, so we have to have those there. Those you mention are rare on the site.
Search only looks in documents that are of the languages you tick. So if you tick nothing in the root languages, it wonât return any of them.
I have long thought that exact thing. (This is one of the reasons for the post) I think for the sake of simplifying the interface, lots of things get lumped together. For example, the parallels icon is mostly other things besides parallels.
Indeed. I agree.
BTW, the search doesnât support regex. Iâm guessing you just meant a search string.
As far as I know, we donât support that at all. I realize you probably just tried that as an example for testing, but my feeling so far is that in practice complex searches like this will be rare. But if you can come up with a plausible use, please let me know.
@HongDa is the one who deserves the credit mostly, with Bhante Sujatoâs guidance of course.
Your feedback is always welcome, especially bugs which can be reported in this thread If you are very interested you could check out the latest posts tagged with search and then click the bell icon and choose âwatchingâ
So here it the tricky bit. Moats is an English word so it will only be found in English documents. If you donât have English selected, then you wonât get any results at all.
Thanks for your feedback!
So you mean related words like âpalaceâ or âguardâ?
We donât have anything like that yet, unfortunately.
@Snowbird regarding your points on regexes and braces - I thought of starting with the basics and then trying with regexes if the basic searches worked. Please ignore my comment about regexes.
Youâre probably right that most people would write simpler search queries. I donât have a plausible use case for regexes and more complex queries with grouping - these may be more useful for academic purposes.
A small note on operator or search term precedence and associativity would be useful though. For example, when I look at the search string:
in:mn author:sujato Buddha OR Monastery
I need to guess the associativity - whether the search string would be interpreted as
(in:mn author:sujato Buddha) OR Monastery
or
(in:mn author:sujato Buddha) OR (in:mn author:sujato Monastery)
The latter is more restrictive.
The intent of scope limiters (ex: in, authorâŠ) is clear. Perhaps later when thereâs time, some examples on how to write advanced search queries can help elucidate operator associativity or precedence.
Yes, once everything is hammered out we can make more detailed tutorials.
At the moment, I believe the filters apply to the whole search string. And operators can only be used on keywords. So itâs (in:mn author:sujato Buddha) OR (in:mn author:sujato Monastery), however that string wonât work in the search because you canât use brackets and you canât use operators on filters.
For example, the search author:suddhaso OR author:sujato feeling breaks things in a very strange way. Simply searching for author:suddhaso with no keywords will return a simple list of all of his translations. But somehow it seems to interpret author:suddhaso OR author:sujato feeling as ignoring everything including and after the OR but it tries to present them all like they were regular search results. Odd. @Khemarato.bhikkhu, have you come across that yet?
A small note on operator or search term precedence and associativity would be useful though. For example, when I look at the search string: