5.0b SR-2: Inconsistency/annoyance: please prioritize exact match for resource title if it exists in
This annoyance gets me frequently:
Type in the exact complete title of a resource into the command bar, and depending on what matching resources you have in your Library, sometimes the book you're trying to open doesn't even show up as one of the possible matches. The one this happens most frequently with is The Message, though I have noticed it other times too.
I have no idea what algorithm determines the order of matching resources in that list. But it's significantly different from the order in the "Search In" dropdown which is smart enough to put the exact match first:
The exact match should come first, then any other prioritized resources you have that match, then whatever order you determine for the remainder. For the "Search In" box, I see that you're putting already-open books up at the top of the list, which is fine, but below the line, in the "Top Resources" section, you should follow the same order as the command bar order, that is exact match first, then prioritized resources, then whatever else remains.
Comments
-
Thanks for bringing this to our attention. The Library already contains logic to ensure exact title matches are highest ranked for a query; I wasn't aware that this logic wasn't also in the Command Box and have filed a bug.
(BTW, are you really still running 5.0a SR-1? 5.0b SR-2 was released today.)
0 -
Thanks for bringing this to our attention. The Library already contains logic to ensure exact title matches are highest ranked for a query; I wasn't aware that this logic wasn't also in the Command Box and have filed a bug.
Thanks, Bradley!
(BTW, are you really still running 5.0a SR-1? 5.0b SR-2 was released today.)
Oops, 5.0b SR-2. The 5.0a was a typo, and I didn't notice the new version installing (or thought it was just new resources or something; my brain was on vacation). Will fix the subject line.0 -
I wasn't aware that this logic wasn't also in the Command Box and have filed a bug.
[:)] Thank you Bradley and Rosie:
I, too, often search in the Command Line for Petersen's Message and its' nonappearance has always frustrated me.
I just wasn't smart enough to bring it to the Forum as a "bug."
Regards, SteveF
0 -
I wasn't aware that this logic wasn't also in the Command Box and have filed a bug.
Thank you Bradley and Rosie:Just to clarify, I didn't say that, Bradley did. Be careful when you're responding to other people's emails not to quote the quote within a reply or it will get attributed to the person quoting it not the original author.
0 -
Be careful when you're responding to other people's emails
[:)]
Regards, SteveF
0 -
The Library already contains logic to ensure exact title matches are highest ranked for a query
Bradley,
I'm not sure if this logic works in the stable releases (I think I never tried, maybe someone can check this), but it seems to be broken in the latest beta.
Mick
Have joy in the Lord!
0 -
The Library already contains logic to ensure exact title matches are highest ranked for a query
I'm not sure if this logic works in the stable releases (I think I never tried, maybe someone can check this), but it seems to be broken in the latest beta.
By "exact title matches", I meant that a title that exactly matched the text you typed in would be promoted. Unfortunately, this simple check does not handle the case of an advanced query (title:"the message") specifying the exact title of the desired resource. This would obviously be a useful extension to add, but is not handled in the current software.
Right now, if you type in:
the message
into the Library, "The Message" should be result #1. This exactly matches the behaviour Rosie asked for in the original post, which is what I was replying to.
0 -
Right now, if you type in:
the message
into the Library, "The Message" should be result #1.I presume you mean "... if you've got your library sorted by Rank" which I never do, so I'd never noticed this behavior before. But I see it does work.
0 -
By "exact title matches", I meant that a title that exactly matched the text you typed in would be promoted.
Thanks, Bradley, for this clarification and I can confirm this works in the current beta.
Unfortunately, this simple check does not handle the case of an advanced query (title:"the message") specifying the exact title of the desired resource. This would obviously be a useful extension to add, but is not handled in the current software.
Unfortunately, what you name as an "advanced query" (would this mean using logical operators in library searches qualifies for a degree in rocket science? Please send the graduation papers to my mail adress [;)] ) seems to be the logic behind the command box parsing Open commands, which lets the shortcoming of the ranking algorithm spill over into another area of the software.
I personally happen to think that specifying the exact title entitles the user even more to rightfully expect an exact match being ranked as #1 - which clearly shows our respective roles in the endless game between users and developers: what you deem a "useful extension to add" (i.e. put it somewhere at the bottom of the Change Request list and let it gradually move up when complaints become stronger, and sometimes have it evaluated, planned for a sometime-to-be release version and if budget allows maybe realize it) looks pretty much like a bug in a core functionality to me.
To give you my perspective: I hardly ever sort the filtered library by rank, so bugs in the ranking algorithm are no big deal for me, when only the library filter is concerned.
However, this bug seriously affects the usability of the Open command, which means: instead of staying in the main layout and simply opening a resource where the title is known, one has to open the library, use the search/filter functionality, scroll through the results or narrow down or re-sort by rank in order to get to the resource, then click the title (maybe even close library if it was opened in a tab/flowating window). Much much more effort.
Maybe you'd like to think over your evaluation and perhaps comment here or in the beta thread again.
Thanks again for your forum interaction!
Mick
Have joy in the Lord!
0 -
Here's what I would consider another version of this bug:
Library:
Command box dropdown:
I have to type all the way to ST (En before the Summa shows up in the dropdown. And, even worse, if I remove the (Eng) from the abbreviated title -- which is what I want to do, since I never remember it's there -- then I can't get it to show up in the dropdown at all.
Abbreviated titles should, of course, be ranked higher than full titles when the dropdown chooses what to show. Otherwise, what use is the abbreviations?
What's more, the Library wasn't any smarter than the Command box. With a filter for ST, the Summa was ranked as number 426...
The Search dropdown got it immediately, though.
Mac Pro (late 2013) OS 12.6.2
0 -
This will be fixed in 5.1 Beta 5.
0 -
This will be fixed in 5.1 Beta 5.
Yay! [:)]
I like the recent improvement in turnaround for bug fixing from the time a bug is reported. Keep up the good work!
0 -
This will be fixed in 5.1 Beta 5.
Have you checked to what extent this fix fixes my issues as well (post above yours)?
I like the recent improvement in turnaround for bug fixing from the time a bug is reported.
?
I don't want to be negative, but I have to admit I haven't noticed any particular change lately. It still seems to take about a month on average before a bug is even recognized, and I still have plenty of bugs that were reported a year or more ago, and which have neither been recognized, nor fixed.
Mac Pro (late 2013) OS 12.6.2
0 -
I don't want to be negative, but I have to admit I haven't noticed any particular change lately. It still seems to take about a month on average before a bug is even recognized, and I still have plenty of bugs that were reported a year or more ago, and which have neither been recognized, nor fixed.
I haven't seen any improvement on old bugs, I've just had a bunch of newer bugs that I've reported in the past couple of months that I would have expected would end up neglected forever since they were kind of minor (such as this one), and have been surprised to see them fixed. I figured a bit of positive encouragement to keep that up might eventually help them overcome the backlog.
0 -
Have you checked to what extent this fix fixes my issues as well (post above yours)?
Your issue was not addressed by this bug fix (which was prioritising an exact title match).
I've made a note of your problem as a separate issue.
0 -
I have to type all the way to ST (En before the Summa shows up in the dropdown. And, even worse, if I remove the (Eng) from the abbreviated title -- which is what I want to do, since I never remember it's there -- then I can't get it to show up in the dropdown at all.
Abbreviated titles should, of course, be ranked higher than full titles when the dropdown chooses what to show. Otherwise, what use is the abbreviations?
And prioritized titles should be ranked higher than unprioritized:
Still no English Summa Theologica...
This isn't too helpful either:
Perhaps you can tell me which one I want...?[:P]
Though, to make it even more confusing, it doesn't seem to matter. Both links seem to go to the English edition. I would have expected one to go to the Greek...
And since we're at the topic of Logos not showing us the options it ought to show us, you should also take a look at http://community.logos.com/forums/p/70019/486593.aspx#486593, which shows similar issues with Reading Lists.
EDIT: No need to do that. Mark started a beta thread about it, which has already been recognized.
Mac Pro (late 2013) OS 12.6.2
0 -
This will be fixed in 5.1 Beta 5.
Thank you! Confirmed fixed (in 5.1 RC-3).
0
