I have 82 systematic theologies listed under "Type: Systematic Theology" in my library.
Why, when I create a collection of Systematic Theologies using "Type: Systematic Theology"... the resulting collection only has two items in it?!
Thanks!
Maybe because of the space character that works as a logical AND? Try the rule type:Systematic-Theology without any spaces.
The space after the colon is throwing it off.
Perhaps someone more knowledgeable can explain the reason to us.
Which space were you referring to? The one after the colon, or the one between Systematic and Theology?
Because if I do type:"systematic-theology", I also get 82 results, which makes it seem like there's some string interpolation occurring inside the quotes? Is a dash a placeholder for a space?
Nope... still only two. How BIZARRE! [:P]
Hmm.
Now I'm totally lost for two more reasons:
Also, what's the priority of AND, compared to type: Is it doing type:(x AND y) or (type:x) AND (y)?
Maybe because of the space character that works as a logical AND? Try the rule type:Systematic-Theology without any spaces. Which space were you referring to? The one after the colon, or the one between Systematic and Theology?
mainly the one after the colon. The other one shouldn't affect the results, see below.
Is a dash a placeholder for a space?
If one wrongly uses type:systematic theology then it will be the same as type:systematic AND theology and since the second part will not restrict the results further (as "theology" is part of every hit for the first part of the rule), in this case it won't distort the rule - but I don't want people to learn the wrong way of writing this (actually I wish someone smart at Faithlife had enough creativity to find only one-word types to avoid all those issues).
Using the dash inside of quotes is unnecessary.
Why does the absence of quotes change the number of results for type: systematic theology (vs. type: "systematic theology")?
when there is a space behind type: you don't use it to restrict to field content, but use the word type so that it needs to occur anywhere in the resource metadata.
type: systematic theology is equivalent to type AND systematic AND theology and will hit for resources that have all of those three words anywhere in the metadata. In my library it finds a monograph resource titled "The Glory of God: A Biblical Theology" where the resource description mentions it "...offers a systematic analysis" and it "examines eight types of glory" (?!).
This book won't e a hit for type: "systematic theology" because this is equivalent to type AND "systematic theology" i.e. requires that "systematic theology" as a unit / a string occurs (either in the type metadata or in any other place, such as subject or resource description) and also the word "type" occurs in the data. For me it hits three STs and a monograph PB called "Basic Doctrinal Studies"
Why does the lack of quotes still produce expected results? I'd think it would have been parsed as type:systematic AND theology. Is it a coincidence that type:"systematic theology" and type:systematic AND theology happen to both produce 82 results?
No it's not a coincidence, the second part of the AND rule is true for all hits for the first part as I explained above.
My guess is that this is because Collections only show resources that have been downloaded, while the library shows downloaded and cloud resources.
Right click on some of the resources in the library that aren't showing up in the collection, and see if you are given the option to download it.
Copy and paste this:
type:systematic theology
It will give you the results you want. I have 210 showing on my mobile device
As indicated earlier in the thread, this will include resources that are not systematic theologies, but have "theology" in the name, description, or author.
Try type:"systematic theology"
Or even type:systematic
type:systematic theology As indicated earlier in the thread, this will include resources that are not systematic theologies, but have "theology" in the name, description, or author. Try type:"systematic theology" Or even type:systematic
I still get 210 results in the search:
And zero results with your other suggestion:
zero results with your other suggestion
Take a close look: You are using two different quote symbols in your mobile search, which seems to throw the parser.
Yes - it's a strange case in that what the search is doing is finding all those resources with type systematic and also the word theology in the title or description. It is probably true - and seems to be true - that all systematic theology resources have the word theology in their description somewhere which is why you are seeing the same results in both cases.
To see the difference try
type:"bible commentary" and type:bible commentary
zero results with your other suggestion Take a close look: You are using two different quote symbols in your mobile search, which seems to throw the parser.
I actually think there is a problem with quotes in library filters on mobile devices which is adding to the problem here.
I corrected it and it still shows zero results. So Graham must be right — there is something wrong with the symbols on Mobile devices.
The easier way on mobile is to use the filter button to the right of the search field to specify the Systematic Theology resource type directly. Or just use type:systematic
I like the sidebar and facets, but I think the breadcrumbs are misleading.
They're written in a user-friendly style which differs from the syntax that the find box uses.
But if you try to use that string in the Find box, it doesn't do what you'd hope it would.
Now imagine if the Find box actually could understand that user-friendly syntax.
I think the user experience would be improved. I think the learning curve would be flattened. I think customers wouldn't need to be power users to use the library's features.
Please use human-readable syntax for library filtering | Faithlife Feedback
Because of Google conventions and the Clause search, I would simply convert the breadcrumbs to the actual syntax.
What Google conventions are you referring to, please?
How much overlap exists between filtering syntax and search syntax?
Do any types of Logos (non-faceted) searches use breadcrumbs?
I believe you mentioned several times how you’d want to see underlying search strings (from context menus?) as I think you had to figure out some particular syntax on your own?
While I’d favor user-friendly text for ease of use and understanding the UI, I’m curious about how a hybrid approach might work (such as revealing the actual syntax when hovering over a human-readable breadcrumb).
The one I use daily is site:community.logos.com; I sometimes use define:definite
Enough that I keep forgetting that there is a difference ... I keep trying to interchange elements that can't be interchanged
I've never really thought about that but I doubt it.
Yes, much of the time they are in the context menu ... I'm not sure how much is left to be done
The actual syntax is what has to be available to the copy function. The question is whether (a) that slows the user learning of the actual syntax and (b) whether the UI becomes unnecessarily complex. I wouldn't rule it out without further consideration.
BINGO! Andrew Batishko wins the chocolate bar! I keep forgetting that since moving up to a new Surface Pro 7, but with a smaller hard drive, and Logos 9, I decided not to download resources until I need them so yes, the majority of my listed STs don't show up in the collection till I've downloaded them.
Thanks Andrew! [}]
The actual syntax is what has to be available to the copy function.
Agreed. Why type the syntax it when it could be copied and pasted.
The question is whether (a) that slows the user learning of the actual syntax
FL has given customers the faceted filtering option -- a drastic improvement in ease of use -- which hides the actual syntax.
I'd suggest some users may not care to know the actual syntax, and we may not want to force it on them.
and (b) whether the UI becomes unnecessarily complex
Setting aside whether to show or how to copy a breadcrumb's actual syntax, we shouldn't overlook the unnecessary complexity of the actual syntax itself.
After all, what tripped things up here was the technical issue of a space after the colon. Users probably don't mean "type" when they enter "type: " so is it beneficial to evaluate it the unlikely way?
I think we probably all agree that the breadcrumb format is more naturally readable and understandable. I wonder how difficult it would be to construct a hybrid grammar that could understand breadcrumb format as well as actual syntax.
FL has given customers the faceted filtering option -- a drastic improvement in ease of use -- which hides the actual syntax. I'd suggest some users may not care to know the actual syntax, and we may not want to force it on them
I'd suggest some users may not care to know the actual syntax, and we may not want to force it on them
I'd go so far as to ask why the average user would assume the filter manual entry line followed the bread crumb model and why they would want to copy what they have in the breadcrumb into it.
BINGO! Andrew Batishko wins the chocolate bar! I keep forgetting that since moving up to a new Surface Pro 7, but with a smaller hard drive, and Logos 9, I decided not to download resources until I need them so yes, the majority of my listed STs don't show up in the collection till I've downloaded them. Thanks Andrew!
Thanks Andrew!
Hahaha that’s funny! Reminds me of a tech support question to solve a desktop computer problem: “Is your computer turned on? This is a common mistake! Is your monitor turned on? Another common mistake!
For you it would be: Did you forget to download all your books to your computer? That is a common mistake! 😂😁😜
Anyway, there are still issues with all the systematic theologies showing up depending on the “search code” you use. Good thing your problem got solved!
👍😁👌
It’s more natural, readable, or understandable? It wouldn’t require the user to learn a different syntax?
When we use an assistant like Siri, we can speak to it naturally. In the same sense, we should be able to naturally filter the library without having to learn and use a different syntax that isn’t intuitive to us.
Why and where is it natural to copy bread crumbs to an input box? Something I've not seen.
I’m sorry, I thought we were talking about using the more readable breadcrumb format in the find box, not the mechanism or behavior of how to copy the breadcrumb to the find box.
Does this go back to whether the breadcrumb should show the actual syntax, rather than the more user-friendly syntax?
I thought we were talking about using the more readable breadcrumb format in the find box,
Sorry I failed to be explicit - there is no obvious reason for the breadcrumb to match the find box except for being able to use the breadcrumb format in the find box (copy it - manual or app). The find box is intended to handle cases that are not easily handled by the facets. I have no objections to making the column name, facet name, and breadcrumb names identical or as near identical as possible -- and as long as shorter forms are not removed, letting them be used as the attribute names (no spaces) in the attribute name-colon-attribute value syntax. I do object to allowing a space after the colon as that is a bad habit to develop re: Google and clause search. I would expect that the average lay user gets by without ever using the Find Box.
I do object to allowing a space after the colon as that is a bad habit to develop
Perhaps suggest that the breadcrumb’s space after the colon gets removed, since it leads to problems with filtering. (I always saw it as an optional space that shouldn’t be required by the filtering grammar. It’s certainly not a hill I’m willing to die on.)
re: Google
Spaces after colons, sometimes they make things more readable, and sometimes they affect filtering results.
I like the sidebar and facets, but I think the breadcrumbs are misleading. They're written in a user-friendly style which differs from the syntax that the find box uses.
I think that whatever the breadcrumbs show should be functional syntax... which to my mind does not mean that the breadcrumbs need to stay the same as they are now. Type:Systematic-Theology is human-readable syntax.
Perhaps make a suggestion on the feedback site?
I’d like to see something good come out of this!
I think that the consistency that Fr. Devin supported and the breadcrumbs being in syntax format are worth putting on feedback. I strongly support the first half, consider the second half as not my choice for the use of resources so, yeah, I'd give it a vote.
Please feel free to write a suggestion or two. I have no problem at all supporting a better proposal (and deleting my suggestion).
I'm completely in favor of consistency between the column names, facet names, and field names.
I also believe that the breadcrumbs should be consistent with the syntax, whatever that syntax turns out to be.
I understand it's significantly easier to change the breadcrumb format, than to rewrite what the grammar would accept.
While I'm partial to the more readable breadcrumb as it exists today (since it doesn't require any additional effort to comprehend it), it's more important for there to be consistency between the different aspects of filtering that users are exposed to.
Users shouldn't have to use differing sets of formats that aren't interchangeable.
It is my experience that making it look as if things are identical when they serve different purposes creates more user problems than it solves.
On this we agree. But breadcrumbs are a record of actions not a syntax to learn. Breadcrumb syntax has a relatively small degree of variation across applications (Breadcrumb navigation - Wikipedia)
But we appear to be in general agreement:
At least from my perspective, it was worth while to sort out why we had different positions ... and therefore, gained a clearer view of the fundamental issues.
Good points, thanks! There certainly are a lot of issues for FL to consider.
I also believe that the breadcrumbs should be consistent with the syntax, whatever that syntax turns out to be. I understand it's significantly easier to change the breadcrumb format, than to rewrite what the grammar would accept.
The actual syntax used by the Facet is quite different to the breadcrumb in most cases because it uses the {extension} format e.g {MyTag "Creation"} ==> the field name has to be exact, the value has to be exact and must be enclosed by straight quotes. This matters with breadcrumb Subject: Jesus Christ because you won't get the same result with Subject:"Jesus Christ" as the facet uses {SubjectGroup "Jesus Christ"}; where the exact value has to be "Jesus Christ"; not "Church of Jesus Christ..." nor "Jesus christ". There is an even bigger difference between subject:handbooks and {SubjectGroup "Handbooks"} - but not due to Case.
Where the familiar colon syntax is used by the Facet, the breadcrumb is informative e.g. Your Ratings: Rated by you ==> myrating:>0 or Your Ratings: 5 stars ==> myrating:5. Breadcrumbs for Last Updated and Added don't even hint at the filter syntax.
The inconsistency between My Tags and Your Ratings could be fixed by FL, but I don't accept that breadcrumbs should be consistent with the syntax.
.png)
