Better find on page

twingeofregret I appreciate that. I also spent decades building products so this area is near and dear to my heart. Also one of the main reasons Orion exists, is that other browsers have been stuck doing more of the same thing for a decade.

Please try the interaction in Kaktus browser and let me know if you still think it is sub-par to current implementations in browsers. Ultimately, this is the only thing that matters and worth discussing about.

Vlad I took a look at it. It manages the two modes as I expected - you need to physically "close" the find in page to get back to the main address bar. It's not the best experience because it removes what makes the address bar easy to use, which is optimization for a single task (change what address I'm looking at). Here the user has to think about what mode that field is in. In general, the less optimized a UI element is for a single task, the more complex (and thus the more work) the user needs to do to use it.

Imagine a search bar in a web page also changing the website you're on. It's an extreme example, but it's apt: the in-page search field always searches the site you're in. It's optimized for searching that site. The browser address bar is optimized for going to an address. (This is part of the reason why other browsers put the "find in page" UI a little into the viewport – it helps tie the relationship between that field and what it searches.)

I don't know if you care about this, but this type of mode switching is also not that accessible.

twingeofregret Thanks for checking it out!

The browser address bar is optimized for going to an address.

I can agree that up to about 10 years ago this was the case. Then a change happened with omnibar concept introduced by Firefox. Now all of the sudden the main purpose of that long input bar in the browser was to search!

Indeed most people use this nowadays to search. They mainly search with the search engine, but also the omnibar allows the user to search currently open tabs, history and bookmarks. Indeed, searching constitues most of the usage of the omnibar today.

Searching for content on the page is just another extension of the search capability that is both context and tab aware. This is the reason that when I first saw this feature implemented in this way in Kaktus, it clicked with me. Separating the search on page from omnibar would feel like separating search engine box from omnibar - unnecessary.

you need to physically "close" the find in page to get back to the main address bar.

But, interaction itself is as quick or quicker then with separate UI for find on page.

The only thing I need to be able to edit my URL is press ESC. Considering I just typed cmd f, means my hands are on the keyboard already.

With separate find UI, I have to either press cmd - l (harder than just ESC) or move my mouse to click the address bar.

Integrated find on page is easier in this sense too, specially because "ESC" to cancel is already a known pattern for any type of search in omnibar. If I start searching for something, I press escape to go back to my URL.

Vlad Ah yes, but the change Firefox implemented is still true to the optimal use of the address bar: it ultimately changes where and what you see in the viewport, which is the purpose for all of the primary browser controls (back, forward, reload, bookmarks, tabs, etc.) It's never been connected to manipulating or searching what you see in the viewport at that moment.

You're looking at that bar as being optimized for search, which isn't how the vast majority of users see it. We tried adding in-page search as an experiment to the address bar and people got confused as it changed the mode the user was in. The two separate user goals are "I want to view a specific webpage," and "I want to find something on this website," and once we started using the same UI control for both, people got lost.

twingeofregret

Yes, my premise is that users are already in the search context when using omnibar. Something 'never been used as...' or 'always been used as.' was a never a good argument in my book.

Can you share more about experiments you did? I want to make sure that the execution was similar to what I had in mind.

In general, we are not scared of being wrong but we are scared of not trying to do everything for the user.

I've skimmed this thread, so appologies if I've missed something — just wanted to add that an expandable search button/input is a very common UI convention in macOS apps and is arguably a good use of the existing toolbar. The key difference here being whether in-page search should exist as a separate button/field from the URL/address field or be combined with it.

Of course the problem with a separate in-page search toolbar button is potential confusion with web search, and of course we've already gone down that path before — let's not forget that's exactly how previous versions of Safari, Firefox and others operated.

Having said that, another negative of course arises as users add more extensions, which arguably might be more common amongst Orion users, given your compatibility with Firefox and Chrome extensions.

Still — I don't see a strong argument that there's no convention for adding a search button/field to the toolbar. Likewise combing in-page search into the URL/address field could be interesting, but one drawback is a scenario where I might want to stay in "find mode" (e.g. to iterate through multiple found instances) but also want to share the URL — access to these is obvioulsy mutually exclusive under such a design.

Whether it's the best approach will of course depend on Orion's particular implementation, but I'd certainly like to see your proposed approach.

Vlad I think there should be two shortcuts to get back to URL bar. One is {esc} and the other should be the standard keyboard shortcut to select text in the URL bar ——> {cmd + l}, which should not only return to URL bar but select all text so it is ready for a brand new search query.

Actually is super hard to use Find text in page in current version..

And my idea for how Find should be working on daily use:
 (cmd) +F will bring up a find textbox in the lower right (or left) corner of the window. I would say firefox highlight tickbox is a must if you are looking for code or something like it on a webpage.
Also results should be a counter like others said and I good maybe an icon to appear on the center of the window each time you are starting over.

Here's a video with Orion, Safari and Firefox.
That "bug" on Orion is there even if I deleted the Orion folder from Application Support.. strange?

Steps to reproduce:
The text search bar sometimes obscures the content beneath it. In the example below, I simply closed the bar without scrolling. There was text beneath it, when there should have been none.

Expected behavior:
The content should shift up to fill the place of the search bar.

Orion, OS version; hardware type:
Version 0.99.120.1-beta (WebKit 614.1.20)

Image/Video:

Orion's "Find on Page" behavior is similar to Safari and works almost as expected on Safari, but there are some things about Safari's "Find on Page" implementation that I find extremely frustrating.

1. Interacting with a page hides find results. This is extremely annoying because sometimes I want to open multiple links containing the same search term and the results are hidden as soon as I highlight or click anything on the page. The example below compares the behavior of Edge to Orion.

2. If a search query is modified while a result is highlighted and the highlighted result still matches the search query while it's being modified, the highlight should not jump to the top result on the page but instead remain on the initially highlighted result. This really sucks when I am searching for things in the middle of a long pdf and I get booted back to page 1 because something in page 1 matched. The example below again compares the behavior of Edge to Orion.

P.S.: In the second video, when I move to the "Find on Page" bar on Orion, I pressed "Command + F" and the previously empty text field automatically filled in with my last searched query, "Star Wars," even though I never copied/pasted the term. I have no idea why this happens, and if I search for another term afterwards, look at the results for this new query, and press "Command + F" again, it replaces the new term with "Star Wars" again. I have no idea how to reproduce this bug but it just randomly happens and deletes my most recently searched keywords.

I find the highlight+pop to be an adequate callout of the search term. Dimming the entire rest of the page is "changing" the rest of the website which doesn't make sense to me. i.e. imagine a scenario when you want to take a screenshot with all occurences of some term highlighted (something I need to do for my work, sometimes), but you still care about the context of the rest of the page.

Additionally, it would be nice if the Search box didn't move the entire page down. That is a bit jarring