BUG: Inconsistent presentation of Search results
See below for different presentation of results for one resource in Books Search:
Results 1-20 is inadequate. Scrolling down hides the results and if one scrolls back up we might see something like Results 1-140, which is nonsense when I get 912 results in 205 articles when searching multiple books.
I expect a complete set of results as per the second query, also with a single resource.
Note that Group by Book was the previous selected option in both cases.
.
Also, see
.
I expect a complete set of results as per the second query.
Dave
===
Windows 11 & Android 13
Comments
-
Hi Dave--Quick note from the "developer" point-of-view that this is actually working "as intended" (though of course you may still feel that we've made the wrong decision(s) here, and are welcome to give that feedback). There are some performance optimizations in our search engine (which predate L10) that allow us to return results for certain types of queries and views much more quickly, if only we don't need to compute a summary of all results.
For such queries/views (searching "jesus" in the "Library" view certainly falls into this category; can't remember offhand about the other one in your screenshot), we take advantage of that optimization, and therefore don't give a "result count summary" in the heading. But we decided to show users the result counts when we do know them (we may know them because the query or view doesn't take advantage of the optimization, or because we've already fetched all available results to display in the UI) hence the inconsistency you're seeing.
0 -
Hi Dave--Quick note from the "developer" point-of-view that this is actually working "as intended" (though of course you may still feel that we've made the wrong decision(s) here
The simple fact is that when Search parameters are identical (second screenshot) the presentation of results should be the same. In this case the queries were identical, but it is equally unacceptable to have a different presentation for different queries (first screenshot). If Group by Library should be inherently different to Group by Book, then its presentation of results should be consistent across queries. At least I can choose to ignore Group by Library, but Group by Book also has to be consistent, etc.
Consistency is a user expectation as inconsistency results in a user wasting time to understand/explain it e.g. I had been aware of it for a month or so but it was only when I ran the searches in the first screen shot that I could define it. Another user had a similar complaint and I was able to re-produce the issue for multiple resources.
Most users prefer a complete summary of results rather than 0-100, 0-120 etc (or no summary), and (having removed results timing) your "optimisation" doesn't seem to be significant.
Dave
===Windows 11 & Android 13
0 -
Quick note from the "developer" point-of-view that this is actually working "as intended" (though of course you may still feel that we've made the wrong decision(s) here, and are welcome to give that feedback). There are some performance optimizations in our search engine (which predate L10) that allow us to return results for certain types of queries and views much more quickly, if only we don't need to compute a summary of all results.
Your developers need to rethink their mind set. Remind them of how the programmers for MRI machines work - with zero tolerance for error. Obviously, that is not the level of accuracy expected of Logos. But users take their religion seriously, even as a life-and-death matter, so they expect reliable, consistent results i.e. something they can rely on. To accept sloppy data implies acceptance of sloppy reasoning implies acceptance of sloppy theology. That's not exactly the image Logos should project.
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
That's not exactly the image Logos should project.
In a Bible and Morph search, we display exact counts because we know that matters.
In a Books search, we can often start displaying the first results more quickly than we can compute the count for results across the whole library. Does knowing that I have 320,585 results across 165,942 articles in 21,527 resources tell me anything useful?
0 -
Consistency is a user expectation
We have three options:
- Always display the count (at the cost of performance)
- Never display the count (at the cost of losing useful information)
- Display the count when we have it (at the cost of consistency)
There are always trade-offs, and I'm sure an argument could be made for choosing any of these three. But ultimately, we chose #3.
0 -
Does knowing that I have 320,585 results across 165,942 articles in 21,527 resources tell me anything useful?
Nice try at reductio ad absurdum however, I am rarely silly enough to think that results across my whole library is worth running. The results across a selected set of liturgical books or official documents of a given group or reformation confessions of faith or sermons by a particular preacher or sermons by preachers of a particular order tell me whether or not there is a difference worth researching further ... a basic function of data mining. As we don't have a data mining visual representation, I must rely on search counts to serve that function.
I suspect choice 3 was made because of an insufficient set of use cases for search counts.
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
I suspect choice 3 was made because of an insufficient set of use cases for search counts.
I don't know about that. It's the same behavior as L9, so it was made long before my time here.
0 -
We have three options:
- Always display the count (at the cost of performance)
- Never display the count (at the cost of losing useful information)
- Display the count when we have it (at the cost of consistency)
There are always trade-offs, and I'm sure an argument could be made for choosing any of these three. But ultimately, we chose #3.
I suspect choice 3 was made because of an insufficient set of use cases for search counts.
I don't know about that. It's the same behavior as L9, so it was made long before my time here.
If it is the same as L9 (which I have side-by-side with V22.0) do you think I would be complaining? And I tried to explain the crucial difference above.
1. This is about Books Search which is being compared with L9 Basic Search
2. I am equating Group by Library with Ranked and Group by Book (Title/Count) with By Resource/By Count
3. I use have a fully downloaded Library (2670 count) and will use "Holy Spirit" as the query.
4. Group by Book (Title/Count) behaves the same as L9 and I don't notice any performance hit with 124,721 results in 2212 resources (0.11s in L9)
5. Group by Library then provides the same summary of results as by Book, which is not presented in L9
I run the same search in my other Search tab and there is NO summary of results with All Books (vs. Downloaded Books above). I switch to Downloaded Books and still NO summary. If I change to Group by Book then switch back to Library, the summary of results is carried over. I go back to the first Search tab (above screenshot) switch to All Open Books and the results summary disappears!!
This sort of inconsistency is unacceptable.
In a Books search, we can often start displaying the first results more quickly than we can compute the count for results across the whole library. Does knowing that I have 320,585 results across 165,942 articles in 21,527 resources tell me anything useful?
Of course it matters. I often run Searches side-by-side so I can compare two sets of results after modifying the query. The summary of results will tell me how big a task I may have set myself! But I will qualify this by stating that I do this with group by Book (with both Title and Count) which appears to have the consistency that is lacking with group by Library. And I haven't mentioned that switching from None (with 1-20) to Library means the latter ends up with NO summary. But both can end up with a complete summary if switched from Author or Type.
And you have to show how results from a single resource are derived (first screenshot) i.e. show the Group by line.
BTW Search History also loses the plot as it can reproduce with no summary consistently and then end up with a summary.
Dave
===Windows 11 & Android 13
0 -
There are some performance optimizations in our search engine (which predate L10) that allow us to return results for certain types of queries and views much more quickly, if only we don't need to compute a summary of all results.
What about returning the results for those certain types of queries and views and only then computing the summary of all results?
“The trouble is that everyone talks about reforming others and no one thinks about reforming himself.” St. Peter of Alcántara
0
