Please use human-readable syntax for library filtering

Facet breadcrumbs are written in a user-friendly style (e.g., Type: Systematic Theology) which differ from the syntax that the Find box uses.

If you try to use that string in the find box, it doesn't do what you'd hope it would.

If the Find box could parse user-friendly syntax, I think it would help improve the user experience, and help flatten the learning curve.

4db5564c95d2b991e8251725dac9a831f7adad3c_Screenshot%20(430).png

Find more posts tagged with

Submitted

Desktop App

Status: None

Comments

Dave Hooton

Unfortunately, spaces have meaning in the syntax i.e. space = AND.
When you read
Type: Systematic Theology
you come to understand the significance of Type: versus Type or Type :
but the actual syntax for the Find box has to exclude spaces or indicate that an actual space character is intended i.e.
type:"systematic theology" ==> the quote marks delineate a phrase of two words
type:systematic-theology ==> the hyphen is an alternate way to separate the words in a phrase
Otherwise, type:systematic theology ==> type:systematic AND theology

PetahChristian

https://community.logos.com/discussion/comment/1335996#Comment_1335996

@mailmedav-48 That’s how the current parser treats spaces, but a rewrite could handle optional spaces instead of only treating them as AND.

Dave Hooton

https://community.logos.com/discussion/comment/1335996#Comment_1335996

@PetahChristian The convention follows Google usage, who also require quotes to escape spaces being treated as AND. Logos also treat the hyphen for this purpose, together with most punctuation (except comma, colon, ? and *).
So Bible.N.T.1 Peter (in the Library Find box) will give spurious results and Bible.N.T.1Peter won't work because a TEXT parser is used. Bible.N.T.1-Peter, Bible.N.T.1.Peter, or Bible-N.T.1-Peter will work (as well as use of lower case). And "Bible.N.T.1 Peter" will always work to escape spaces.
We adapt to using 1 Peter in Bible Search, and 1Peter in the Reference box of bibles/commentaries because of the DIFFERENT parsers (and 1Peter doesn't work in Search boxes).

So "optional spaces" WILL require a rewrite and likely make our collection rules much less efficient. Note that the more efficient {Extension} syntax requires a space after the field name, but the values have to be EXACT and enclosed by quotes. The current syntax is much more flexible.

Quick Links

Product Feedback

Recent Ideas

Missing Author Datatype / Wiki Article
I really want to have Dantes "Divina Comedia" in the Italian original in Logos/Verbum, but no one voted for it. So I tried to make a PB, but as other users affirm, there are no Milestones for "Dante" or the "Divina Comedia" present. Today, I wanted to check on the Author Datatype list coming from the Logos Wiki: Which…
Bible Study Builder notebook
can we please get the notebook function so that our notes for the questions could be stored in a notebook.
Notes: More Robust Indenting
When typing in Word, or even in the Notes Feature on the Logos Desktop App, when you start an indented number list, and you go to the next line then tab out, it goes from 1. to an a. indented from the position of the 1. (I hope this makes sense). I would love it if there was a way to add this to the Mobile/iPadOS version…
Addition to iOS app
In the iOS app there is a “back button” that will take you to the previous passage that you were at. It would be nice to also have a “forward” button so that you could go back to where you were before you hit the back button.
Missing/dead links interim improvement
On a frequent basis there is a forum thread on the issue of links resulting in a debate on links to different editions of the work. I suggest the following to minimize this reoccurring debate. Exclude milestone references and bibliographic references. If the user owns the edition referred to in the link, links as usual. If…