What is the logic behind this?

Are you trying to make it HARDER to search?

Logos6 introduced "inline search." Great! I actually like this feature. So, why doesn't Cmnd-F (on a Mac) or Ctrl-F (on Windows) default to this?

What is the advantage of "regular" Find now?
Why are you keeping both?
Why did you decide to use (a more awkward) Shift-Cmnd-F instead of Cmnd-F for new and improved inline search. Current implementation is harder, less intuitive and redundant.

I understand, that inline search only works in Bibles. Great.

Eliminate regular Find in Bibles
Enable inline search in all resources
default Cmnd-F to inline search

Find more posts tagged with

Comments

GaoLu

I disagree. Regular find and inline find serve different needs. I like both. Regular Find is universal and should use Ctr+F. Inline Search is specialized, not universal and has a KB shortcut that fits the occasion.

Let it be.

Bruce Dunning

Logos6 introduced "inline search." Great! I actually like this feature. So, why doesn't Cmnd-F (on a Mac) or Ctrl-F (on Windows) default to this?

When I type Ctrl-F it defaults to an in-line search (see below)

toughski

https://community.logos.com/discussion/comment/669187#Comment_669187

When I type Ctrl-F it defaults to an in-line search (see below)

no. the term "inline search" in L6 refers to this:

your screenshot references what I called "regular" search. I don't know the technical term for it. For the purposes of this post, let's refer to is as "old search"[;)]

Bruce Dunning

https://community.logos.com/discussion/comment/669190#Comment_669190

When I type Ctrl-F it defaults to an in-line search (see below)

no. the term "inline search" in L6 refers to this:

your screenshot references what I called "regular" search. I don't know the technical term for it. For the purposes of this post, let's refer to is as "old search"

You are right toughski. I looked at this too quickly and assumed it was the in-line serach. Sorry about that.

Sean

The Ctrl-F Find works the same as in a web browser or word processor; that's probably why that shortcut is assigned. It's also been there longer and would be confusing if changed.

I like and use both of them; the only problem is with the inline search opening a new copy of the resource whenever you click a result, but I don't know what the best solution to that would be.

toughski

https://community.logos.com/discussion/comment/669199#Comment_669199

I like and use both of them

I believe it is redundant

the only problem is with the inline search opening a new copy of the resource whenever you click a result

I don't understand what you mean. Neither searches produce clickable results - they just highlight searched terms in a resource. Are we talking about the same thing? Can you provide a screenshot?

Dave Hooton

What is the advantage of "regular" Find now?

Why are you keeping both?

"Regular" Find does not upset the display of resource text, so is quicker for ad hoc searches.

I understand, that inline search only works in Bibles. Great.

Not true. It works in monographs, etc.

Eliminate regular Find in Bibles

I wouldn't object if it was eliminated!

MJ. Smith

https://community.logos.com/discussion/comment/669204#Comment_669204

One both "find in this panel" and "inline search" work on all resources. They serve different functions. Find in this resource is a simple string search which is what CNTL-F (f for find) usually does. Inline search is a limited version of the search panel. Two different but related functions serving two different purposes.

I use the Find when I want to skim through a resource skipping portions unrelated to my topic. I use Inline Search when I am doing serious research and wish to see what this particular resource offers me ... rather than using the search panel and going back and forth between panels.

I would be unhappy if the meaning of the Find function (CNTRL-F) were to change or if the functions were combined.

toughski

https://community.logos.com/discussion/comment/669211#Comment_669211

"Regular" Find does not upset the display of resource text, so is quicker for ad hoc searches.

Dave, I am not being argumentative, but is there a "substantive" difference. Is it simply .037 ms quicker? I understand that in theory Inline Search has to redraw text in the panel (or maybe the entire screen), but practically, is there a significant difference to keep Regular Find?

Also, Inline search is definitely more complex. Since search parameters persist from the last search, it is possible that it would take longer to reset the search (for example, if previously I was searching Emphasis Markup in OT, and now I want to search All Bible Text in All Passages, I would have to make a few clicks to reset).

Overall, though, this is not enough to keep Regular Find.

MJ. Smith

https://community.logos.com/discussion/comment/669219#Comment_669219

Dave, I am not being argumentative, but is there a "substantive" difference. Is it simply .037 ms quicker? I understand that in theory Inline Search has to redraw text in the panel (or maybe the entire screen), but practically, is there a significant difference to keep Regular Find?

I answered that - "Find" is a simple string search. period. Inline search is a modified panel search which is NOT a simple string search. Play a bit with case, punctuation and word forms and you will see the difference.

toughski

https://community.logos.com/discussion/comment/669213#Comment_669213

One both "find in this resource" and "inline search" work on all resources.

in my previous post I mistook my notes for a Logos Commentary. Inline Search does NOT work in user notes. (In all honesty, "find in this resource" in user notes is so crippled that it is practically useless).

I would be unhappy if the meaning of the Find function (CNTRL-F) were to change or if the functions were combined.

We all resist and are mostly unhappy with change. I am approaching this issue from a design perspective. SIMPLE. Clean. elegant. UI.

Right now we have multiple search entry points. In the same resource! Multiple keyboard shortcuts. That you have to memorize. However, there is no shortcut for a Search panel - I believe you have to click on the magnifying glass (or enter "search" in the command bar).

This is so unintuitive to new users. I would like Logos designers to consider power of simplicity, rather than complexity, when adding/redesigning new features.

toughski

https://community.logos.com/discussion/comment/669220#Comment_669220

Dave, I am not being argumentative, but is there a "substantive" difference. Is it simply .037 ms quicker? ...

I answered that

in my reply to Dave I was talking about the SPEED difference. That was the context of his reply.

Play a bit with case, punctuation and word forms and you will see the difference.

Can you provide some examples of what you mean? I see the difference that Regular Find locates targets one at a time, while Inline Search numerous targets.

Ron

https://community.logos.com/discussion/comment/669228#Comment_669228

This is so unintuitive to new users. I would like Logos designers to consider power of simplicity, rather than complexity, when adding/redesigning new features.

I'm trying to figure out the point you are trying to make with the DSLR camera? If you are using that as an example of complexity and therefore poor design, I couldn't disagree more. The "complexity" of that camera interface lets me do far more with my DSLR than I can with a point-and-shoot or with my cell phone camera. It has far more versatility and can take photos I could never manage prior to owning it.

There is some complexity to it and it has a learning curve, but complexity doesn't always equate to "poor design"...and conversely, simplicity doesn't necessarily always mean "better". Sometimes power and versatility necessitate a certain amount of complexity. From that standpoint, I think that the camera analogy works well. Logos is the DSLR of the Bible Study world! (And that's a good thing [:)] )

toughski

https://community.logos.com/discussion/comment/669235#Comment_669235

I'm trying to figure out the point you are trying to make with the DSLR camera? If you are using that as an example of complexity and therefore poor design

au contraire! This is an example of a complex device with beautiful design (because it's a Canon![:P]) All buttons are within finger reach. There is only enough buttons, no more, no less. Even if one has a battery grip (not pictured) the shutter button would be in the exact same spot in Portrait mode as in Landscape, etc. Aside from shutter button doing focusing and metering (most people reprogram it anyway), all other buttons perform only one function - Simplicity, that allows users to change settings even without looking at buttons or even a screen.

EDIT: Ron, you seem to understand photography and DSLRs: can you imagine a camera, that has one button/wheel to enter aperture in Aperture Priority mode, a different button for entering aperture in Manual mode, etc? this would be a nightmare!

Granted, a dSLR is not an "apples-to-apples" comparison to Logos, but from the design standpoint, there is too much redundancy, or unexpected behavior (compare Find in a regular Logos resource vs. Notes, for example) in Logos6.

Andrew Batishko

I can think of one thing the Find tool can do that Search and Inline Search can't. The Find tool will let you look for punctuation.

toughski

https://community.logos.com/discussion/comment/669253#Comment_669253

I can think of one thing the Find tool can do that Search and Inline Search can't. The Find tool will let you look for punctuation.

Indeed! Was THAT designed intentionally? Apart from a desire to find all the Smileys in God's Word, what is the practical purpose for this? I am not trying to be argumentative, but as a missionary, preparing multiple messages every week, how is this practical? Even if it is, I am sure this functionality can be combined into Inline Search.

MJ. Smith

https://community.logos.com/discussion/comment/669237#Comment_669237

With match all forms applying to inline search but not find ....

GaoLu

https://community.logos.com/discussion/comment/669256#Comment_669256

Bible:

Inline Find provides less context than Regular Find.

Monographs:

Inline does not allow instance by instance view. Regular Find has the nifty carets that allow finding instance by instance with full scroll-able context.

If they can be combined great. Please don't take my old fashioned Find away.

Re: punctuation - I can imagine wanting to search for punctuation such as instances of ":" for example "Lord;" or "Lord:"

MJ. Smith

https://community.logos.com/discussion/comment/669256#Comment_669256

Indeed! Was THAT designed intentionally?

I hope so ... it is a string search ... and yes, there are times when I want to search for a word followed by punctuation - to find lists vs. compounds for example. Yes I can do it with a panel search and the match argument but ...

Example: Judges-Ruth as a single book vs. Judges, Ruth as a list of two books

toughski

https://community.logos.com/discussion/comment/669257#Comment_669257

With match all forms applying to inline search but not find ....

I am sorry. I don't understand. The display of the results is different, but the Inline Search seems to find everything that Find does (with some false-positives, this is to be expected). With Find you have to click about 167 times to get to the last target (let's imaging that you were searching specifically for it), while with Inline Search you can quickly scan the results and click only once.

Having said this, Find is the only option available for Notes, unfortunately. Even so, it's implementation seems to be crippled from Find in other resources.

toughski

https://community.logos.com/discussion/comment/669259#Comment_669259

Indeed! Was THAT designed intentionally?

I hope so ...

I should have put a <sarcasm> marker. I think this differential is a lack of design in Inline Search, rather than intentional "feature" of the Find

MJ. Smith

https://community.logos.com/discussion/comment/669228#Comment_669228

We all resist and are mostly unhappy with change. I am approaching this issue from a design perspective. SIMPLE. Clean. elegant. UI.

My children would certainly disagree with your assumption here and I would match my reputation/experience in analysis and design with the best of them. Standardization is a valuable attribute which Logos/Verbum is preserving in CNTL-F.

toughski

https://community.logos.com/discussion/comment/669258#Comment_669258

Bible:

Inline Find provides less context than Regular Find.

true. How much of the context is adequate? I believe 1 paragraph is significant context, and Inline Search provides that.

Monographs:

Inline does not allow instance by instance view. Regular Find has the nifty carets that allow finding instance by instance with full scroll-able context.

Thank you. This is helpful! This implementation of Inline Search in Monographs is terrible! Why the difference from the others? I believe this can be better!

toughski

https://community.logos.com/discussion/comment/669263#Comment_669263

Standardization is a valuable attribute which Logos/Verbum is preserving in CNTL-F.

I am all FOR CNTL-F!

I am against 2 searches under 1 roof:

I am against Inline Search displaying one way in Bibles and a totally different way in Monographs
I am against Find working one way in Logos resources and a totally different way in Notes
I am against having to memorize CTRL-F, Shift-Ctrl-F, Alt-Shift-Ctrl-F, Fn-Alt-Shift-Ctrl-F, etc.

There is a reason we have a unified Search Window with Basic, Bible, Media, Clause, Morph, Syntax buttons. We do not have separate search fields for them - just 1.

MJ. Smith

https://community.logos.com/discussion/comment/669262#Comment_669262

I think this differential is a lack of design in Inline Search, rather than intentional "feature" of the Find

I don't think so - in a Search one has universal settings and the Match attribute to allow one to select very precisely the behavior you want ... at the cost of having a steep learning curve on the Search; the find is a simple and standard string match with a minimal learning curve but requiring multiple searches to replicate the Search.

Related but different functions for different purposes.

MJ. Smith

https://community.logos.com/discussion/comment/669269#Comment_669269

Standardization is a valuable attribute which Logos/Verbum is preserving in CNTL-F.

I am all FOR CNTL-F!

I am against 2 searches under 1 roof:

I am against Inline Search displaying one way in Bibles and a totally different way in Monographs

I am against Find working one way in Logos resources and a totally different way in Notes

I am against having to memorize CTRL-F, Shift-Ctrl-F, Alt-Shift-Ctrl-F, Fn-Alt-Shift-Ctrl-F, etc.

I'm getting the feeling that you are trying to convince me that you are right rather than asking for information regarding the logic of the current implementation.

Logos has made a distinction between Search and Find. You do not but the logic of Logos has been explained ... and is reasonable given the universal search attributes do not apply to a find.

Logos makes an assumption that on a Bible you will select a Bible search and on a monograph you will select a Basic search. The format that shows reflects the results of that choice just as it would in a search panel. If you wish to add a step to every search rather than Logos/Verbum making a highly accurate prediction you have a point. But Logos logic is reasonable.

Logos implementation of Find & Search in Notes are less than satisfactory. Whether or not Logos will be able to change this depends upon what structural changes they may have made in the recent reworking of notes. We have to wait and see but it is not germaine to the primary question.

You are not obligated to learn all (or any) keyboard shortcuts ... one learns the ones you need for the various applications you use and the functions that you use. If Logos was intended to be solely a keyboard application this would have considerable more weight than when it is mouse and (slowly becoming) touch screen enabled.

That covers all the logic needed to explain the implementation. Whether or not you accept the validity of the logic is outside the question I'm answering.

NB.Mick

https://community.logos.com/discussion/comment/669256#Comment_669256

I can think of one thing the Find tool can do that Search and Inline Search can't. The Find tool will let you look for punctuation.

Indeed! (...) what is the practical purpose for this

I use it to find certain footnote markers, namely "daggered notes" in the CSSB [Concordia Self-Study-Bible, a Lutheranized NIV SB].

Many forum users seem to look for question marks in their English bibles (which of course relies on the translators to discern questions in the original text and phrase them as such in English)

toughski

https://community.logos.com/discussion/comment/669360#Comment_669360

Thank you, NB.Mick

Mark Barnes

https://community.logos.com/discussion/comment/669256#Comment_669256

Indeed! Was THAT designed intentionally? Apart from a desire to find all the Smileys in God's Word, what is the practical purpose for this? I am not trying to be argumentative, but as a missionary, preparing multiple messages every week, how is this practical? Even if it is, I am sure this functionality can be combined into Inline Search.

It's not as simple as that. Inline search uses the search index, whereas CTRL+F doesn't. Unless you change the entire way Logos indexes and searches, inline search won't be able to find punctuation.

As to why that might be useful, there are edge cases when it's useful. But that's not really the point. Both inline search and CTRL+F are useful in different ways. There's not sufficiently different that people would be clamouring for CTRL+F if inline search existed on its own, but they are sufficiently different to make it worth keeping both now we have both.

Personally, I use inline search when I want to search for something in a single resource and be able to scan through multiple results. I use CTRL+F most often when I know what I'm looking for, and just want to jump to that place in the resource. [Home]+[CTRL+F]+SearchTerms+[Esc] is quicker and more efficient than inline search for that purpose.

Mark Barnes

https://community.logos.com/discussion/comment/669269#Comment_669269

I am against Inline Search displaying one way in Bibles and a totally different way in Monographs

It doesn't. Perhaps you have the display ranges set differently?

toughski

https://community.logos.com/discussion/comment/669374#Comment_669374

It doesn't. Perhaps you have the display ranges set differently?

Mark, we are talking about Monographs (you gave an example of an Encyclopedia), so I went to the first found monograph and this is what I got:

unlike the Bible, it did not even display what I was looking for! It was only now, HOURS LATER that I thought to click on the little upload button on the right and selected Send to Search panel.

It then displayed in a way that I expected. But it was not "inline search" in the actual resource. This is the design inconsistencies, that really throw users off.

Mark Barnes

https://community.logos.com/discussion/comment/669397#Comment_669397

Mark, we are talking about Monographs (you gave an example of an Encyclopedia),

Almost all monographs work exactly as I described.

It looks like there's a bug by which the sentence/paragraph/article menu doesn't display in resources without milestones (e.g. most Vyrso books such as the one you posted). I'll report that.

I'm wrong. It looks like the problem occurs in some other resources too. I can't work out what's triggering the problem.

Bob Pritchett

I think this has been argued pretty thoroughly, but just to give an 'official' answer:

A fundamental design principle we try to follow is that the same action should lead to the same behavior. The mechanics of 'Find' -- its operation forward from your current position (not from the start of the document), its non-destructive display of the content (it doesn't reformat/hide text), etc. are not only well-established in our app, but in almost all desktop applications. To have Find behave differently in Logos resources (from both other apps and from non-resource windows in our app) would introduce a 'I don't know what will happen when I type this' situation.

Searching for punctuation was a regular request; people often ask how to find the next question mark in a resource, for example.

Andrew Batishko

https://community.logos.com/discussion/comment/669397#Comment_669397

Mark, we are talking about Monographs (you gave an example of an Encyclopedia), so I went to the first found monograph and this is what I got:

unlike the Bible, it did not even display what I was looking for! It was only now, HOURS LATER that I thought to click on the little upload button on the right and selected Send to Search panel.

It then displayed in a way that I expected. But it was not "inline search" in the actual resource. This is the design inconsistencies, that really throw users off.

Not all resources (such as Speaking the Truth in Love) have been rebuilt to take advantage of the smart-selection tagging, which is what drives the context options in inline search. Without that tagging, the displayed context is the entire article. You can navigate between search hits using locator bar:

toughski

https://community.logos.com/discussion/comment/669417#Comment_669417

Thank you, Bob.

It is much clearer now why and how I should use both tools.

A fundamental design principle we try to follow is that the same action should lead to the same behavior.

Can I request improvement to both Find (specifically as it relates to its behavior in Notes) and Inline Search (as it relates to its behavior in Monographs, including Personal Books)

toughski

https://community.logos.com/discussion/comment/669434#Comment_669434

Not all resources (such as Speaking the Truth in Love) have been rebuilt to take advantage of the smart-selection tagging, which is what drives the context options in inline search. Without that tagging, the displayed context is the entire article. You can navigate between search hits using locator bar:

This is VERY helpful, thanks!

Also makes sense why a forced update of so many resources right before the rollout of L6 [;)]

Dave Hooton

https://community.logos.com/discussion/comment/669440#Comment_669440

...Without that tagging, the displayed context is the entire article. You can navigate between search hits using locator bar:

This is VERY helpful, thanks!

I previously requested that Faithlife have a "Search Result" locator as part of the Inline search panel and received a favourable response.

toughski

https://community.logos.com/discussion/comment/669604#Comment_669604

I previously requested that Faithlife have a "Search Result" locator as part of the Inline search panel and received a favourable response.

[Y]

GaoLu

https://community.logos.com/discussion/comment/669656#Comment_669656

Now that is a good thing!