BUG (I hope...): Inline Search titles open in new tab

When you run an inline search, each result appears below a grey colored line of text, which indicates the location in the resource where the following paragraph or verse is found.

It used to be that when you clicked on that link, you would navigate in the same tab to that location, and inline search would close. This was fantastic, and was just what was missing for me to finally really enjoy using Inline Search.

Now, in the most recent beta, when you click on a link, a new tab opens up, in a new pane, showing you the location where you clicked. Not good....

Could we get the old behavior back? Please? I was finally loving using Inline Search! And now this!

Find more posts tagged with

Comments

Jack Caviness

[Y]

Agree with Fr Devin

Dave Hooton

It used to be that when you clicked on that link, you would navigate in the same tab to that location, and inline search would close.

That was my understanding from 6.0x and is also my preference, but 6.2 has the same behaviour as 6.1! Perhaps both can be accommodated via a key press.

Fr Devin Roza

https://community.logos.com/discussion/comment/705184#Comment_705184

Thanks for the support! [Y]

I just wanted to mention the reason that I prefer the previous behavior, where clicking on the grey link would navigate and close inline search, all within the resource.

Basically it's because if I'm doing an Inline Search, I chose Inline Search precisely because it allows me to search within a resource without leaving it. If I wanted to search within a resource and look at the results in a different pane, I would use the full Search Pane.

Dave Hooton

https://community.logos.com/discussion/comment/705202#Comment_705202

I chose Inline Search precisely because it allows me to search within a resource without leaving it.

Dylan Rondeau

This was fantastic, and was just what was missing for me to finally really enjoy using Inline Search.

Apparently not enjoyable enough to use Inline Search for three release cycles! [:)] This was actually an intentional change in 6.0a RC 1. It was even in the release notes: https://wiki.logos.com/Logos_6.0a_RC_1

I can make a case to see if this is something we want to do, but since this was a deliberate design change, I don't know if we will. It's been as-is long enough that I don't know if a significant number of users would want it changed.

Graham Criddle

https://community.logos.com/discussion/comment/705463#Comment_705463

I prefer the current way it works!

Dave Hooton

https://community.logos.com/discussion/comment/705468#Comment_705468

I prefer the current way it works!

[:)]

Fr Devin Roza

https://community.logos.com/discussion/comment/705463#Comment_705463

This was fantastic, and was just what was missing for me to finally really enjoy using Inline Search.

Apparently not enjoyable enough to use Inline Search for three release cycles! This was actually an intentional change in 6.0a RC 1. It was even in the release notes: https://wiki.logos.com/Logos_6.0a_RC_1

Call me crazy... but right before I upgraded to 6.2 beta 1, I was on the latest release, and Inline Search was, for the first time I remember, working the way I described, where clicking on the grey title closed Inline Search and navigated to the place where I clicked. I was super happy, and started using it constantly. I loved it. To be more precise, it didn't close the Inline Search entirely. It cleared the search bar, navigated the resource, and closed the search results. But the Inline Search bar stayed open. It was really, really nice.

It sounds like from what you say it was actually a fluke or a bug, but as far as I was concerned, Inline Search was finally working the way it should, allowing me to run full searches and navigate to the results without leaving the tab I was in... which is what I had always understood the idea of Inline Search to be.

I had avoided using Inline Search it before because of the navigation issues (how difficult can it be to actually just navigate to the search result you want to read when you're done searching and found what you wanted?). And it looks like now maybe I'll end up avoiding it again. It really is too bad, because it's feature that has so much potential, if it could just be what it says it is... Inline, as Dave so helpfully highlighted in an earlier post. Help Eli Evans!

MJ. Smith

https://community.logos.com/discussion/comment/705547#Comment_705547

I think Eli is busy proof-reading one last time Evans, Eli T. The Bible as Art. Bible Study Magazine. Bellingham, WA: Lexham Press, 2014.

Eli Evans (Logos)

https://community.logos.com/discussion/comment/705554#Comment_705554

I think Eli is busy proof-reading one last time Evans, Eli T. The Bible as Art. Bible Study Magazine. Bellingham, WA: Lexham Press, 2014.

Ha! No, I'm not working on that. I didn't even realize this was live yet. I remember that someone from the publications department passingly mentioned they were going to bundle my columns and if I had any objection — but that was months ago. Time to go grab my gratis copies ...

Eli Evans (Logos)

https://community.logos.com/discussion/comment/705547#Comment_705547

It was intentional, but you're making me reconsider.

Here was the reasoning:

There are two reasons to search: (A) To locate one or a few items; (B) to survey all the items. These two search behaviors are sometimes called A hunt/search/locate/target, and B gather/graze/survey/browse.

The 6.0a behavior (navigate in-panel and clear results) serves the A group at the expense of the B group, because it disturbs the layout less by re-using the panel, but in the process destroys the result list (a feature for A, but a harm for . If you want to see the context of just one hit then return to your B survey, you can't. On the other hand, the 6.1/2 behavior (show a new panel but keep the original results) serves the B group at the expense of the A group.

So it's an exercise in weighing harms: I saw the 6.1 behavior as fundamental to the B task and annoying to the A task, whereas the 6.0a behavior was merely convenient to the A task, but excluded the B task altogether. (By the way, this is usually the way design decision making has to go: It's not usually a matter of right versus wrong, but sorting out multiple competing virtues, or in this case, harms.)

I think using a meta key to get the other behavior is fine. I'll huddle up with the devs (there is already a bewildering array of meta keys for clicking links in resources, and the gray ones don't behave like the blue ones) and see if there's an elegant way forward that does minimal harm to both groups.

Brian Losabia

https://community.logos.com/discussion/comment/707792#Comment_707792

It would be neat to be able to toggle between the modes using the command box, to try both modes on to see which one works best for each individual Logos user. (I'm hoping it's a command box sort of toggle (like the verbum mode toggle), since I think the Logos system preferences are awesomely clean and streamlined, especially considering the powerful capabilities of the software.)

Fr Devin Roza

https://community.logos.com/discussion/comment/707818#Comment_707818

It would be neat to be able to toggle between the modes using the command box

What a good idea. It certainly would be nice to find some way or another to make it a permanent toggle (at least if the default is to open in a new tab [:)]).

And, thanks so much Eli for all your great work on Design! It's so refreshing to have a company that is so open to making a decision like this, and then reconsider it - as you say, designs like this have advantages and disadvantages, and some users may prefer one or another depending how they work.