Searching has become too complex!
I posted a suggestion for providing better help for searching using datatypes and extensions in the suggestions section of the forum. However, I am posting here to complain a bit about how difficult it has become using the search box for searching datasets and extensions. There are some videos that show how to combine these searches which make things look easy, but memorizing the search formulas for the various datasets is impossible. Do I put an = sign; <> or {} or {<>} or {<=>}; what are the various literary types available regarding Laws or Grammatical constructs... Also there are the searches you get from the right context menu that have different formulas from what the help files use. The documentation and comparison of searches using the Grammatical Construct is a perfect example. There needs to be some consistency in the formulas regarding capitalization, spacing etc.
We need better drop down suggestions specific to these searches. Once a { or a < is typed in the search find box a drop down should offer whether we want Section, Speaker, Literary type, Grammatical Construct etc. Once that is selected then options should be available. How can we truly search literary types without going to help and finding all the types offered with the exact syntax required?
It is time for making these very powerful search tools more accessible to the average user or even once power users that can no longer keep up...
Comments
-
I agree.
0 -
I agree with John. I have no trouble at all in my day job writing pretty complex SQL statements (for those lucky enough not to have to do this for a living, this is the data query language many programmers use). And one of the other complexities when using Logos compared to SQL is that I often don't know what Logos syntax to use with what dataset or resource. It would be nice if that was a wee bit clearer. In SQL, I know what my tables are and what columns are available to me.
0 -
A while back (maybe last year or year before) there was a discussion about a search function that mirrored the morph search methods. As an example If I wanted to find passages I have marked up with Highlighter Pens I would enter {Highlight Highlighter Pens/*}
The idea would be click a button where all the search capabilities would be listed (e.g. section, highlights, clause, etc.) I click highlight and a list of the high lighter palettes I have would appear. I click Highlighter Pens and a list of the colors appear, and I can select one or more of the colors. The search string would be automatically built based on my selections.
This would eliminate the need for a user to memorize all of the search possibilities, as well as the syntax for each.
0 -
Fred, that is exactly what I suggested in that section of the forum. It would be very useful and helpful.
0 -
John Fidel said:
Fred, that is exactly what I suggested in that section of the forum. It would be very useful and helpful.
Maybe someone in Faithlife will see it and get something like that built. I am not sure how difficult it would be, but if it can be done for Morph searching I would think it can be done for other types of searches.
#simplesearchtool [:)]
0 -
0
-
I agree. I keep a syntax "cheat sheet" on my desk to reference because it is impossible to remember the specifics for each type of search.
0 -
Fredc said:
The idea would be click a button where all the search capabilities would be listed (e.g. section, highlights, clause, etc.) I click highlight and a list of the high lighter palettes I have would appear. I click Highlighter Pens and a list of the colors appear, and I can select one or more of the colors. The search string would be automatically built based on my selections.
Superb suggestion.
Lew Worthington said:I have no trouble at all in my day job writing pretty complex SQL statements (for those lucky enough not to have to do this for a living, this is the data query language many programmers use). And one of the other complexities when using Logos compared to SQL is that I often don't know what Logos syntax to use with what dataset or resource. It would be nice if that was a wee bit clearer. In SQL, I know what my tables are and what columns are available to me
When even programmers complain about the complexity of the search syntax, it is time for FL to make some alterations.
0 -
I agree. One of the things people missed in the change from Libronix to Logos 4 was the search dialog box. As search syntax has become increasingly complex, it would be good to revisit bringing back a dialog box interface to it, so that people don't have to memorize the arcane syntax or keep a cheat sheet. Keep the syntax there for uber power users who really want to type that stuff in, or who only use a couple of the search features and have them memorized. But create a GUI for it.
0 -
Rosie Perera said:
But create a GUI for it.
+1 [Y] for Search GUI builder plus more Search Documentation. Awesome would be a GUI Builder with selectable items that links to documentation.
Thankful for Greek Grammatical Constructions Documentation.
Keep Smiling [:)]
0 -
Lew Worthington said:
I agree with John. I have no trouble at all in my day job writing pretty complex SQL statements...
That made me smile. I also compared Logos searches with SQL some time ago.
0 -
[Y]
0 -
YES!!!!! A single GUI interface from which ALL searches can be constructed: syntax, morphology, Bible and basic. Logos really suffers in comparison to its competing products in this area. The layers upon layers which has become the Logos search engine is really becoming quite unwieldy.
0 -
Yes! Please!
0 -
John Fidel said:
It is time for making these very powerful search tools more accessible to the average user or even once power users that can no longer keep up...
I agree!
0 -
Clint Cozier said:
YES!!!!! A single GUI interface from which ALL searches can be constructed: syntax, morphology, Bible and basic. Logos really suffers in comparison to its competing products in this area. The layers upon layers which has become the Logos search engine is really becoming quite unwieldy.
It's a great idea in theory. However, given the variety of searches possible and the requests for searches that appear in the forums, I'm not convinced it is practical. I suspect a number of additional restrictions on searches would be required. The interface could be greatly improved, however, with a much more robust hint/autocompleter
Reasons I think that a significant portion of the problem exists in user training rather than interface:
- the number of requests to help build searches that are impossible - where no conceivable coding (including Logos') would make them findable because it is a subjective category
- the number of complaints of mismatched results where there is no reason to assume the results should (or could) match
A better interface will not solve user misunderstandings or unrealistic expectations. It would likely only increase the frustration level because the user could blame the error on the interface having built the wrong query.
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 -
Doing something -- whether it's more/better suggestions, or a visual search query builder, or streamlining the search syntax -- is on our list for an incremental release. MJ's caveats are all very real.
0 -
Thanks for the reply and follow up. I look forward to seeing what you come up with.
0 -
Fredc said:
a search function that mirrored the morph search methods.
[Y]
I think the vast majority of users really appreciate the GUI of the morph search. I'm highly supportive of extending this to other (existing and future(cross fingers)) searches. I'm suggesting this interface for a much needed Nikkud search ability. My suggestion is specific to Hebrew, but I'm confident that it could be extended to Greek as well. I'd really appreciate support in this request! [;)][:P][:D]
0
