Vlad This is obviously not a strict rule, but in general when you're considering a UX pattern for an app or service (especially one as common as a web browser) it's better to follow an existing pattern rather than create a new one. You want to leverage a user's existing knowledge of how things work, and new patterns that deviate from that can create uncertainty and a loss of confidence.
I have not seen a single example of a browser that combines the find in page with the address bar.
I have not seen a single example of a browser that combines the find in page with the address bar.
I just gave you one 
(could be we typed at the same time see my message here https://orionfeedback.org/d/644-better-find-on-page/20 )
You want to leverage a user's existing knowledge of how things work, and new patterns that deviate from that can create uncertainty and a loss of confidence.
In general yes, although if Steve Jobs followed this convention we would still be typing on physical keys and never have iPhone. With Orion we are not afraid to break established patterns and experiment with the goal of producing superior UX. Sometimes it works, sometimes it does not, but 'existing patterns' should not be holding us back to experiment.
Vlad If Kaktus were a browser with a large audience, the deviation from convention might make sense.
Let's think about it this way: Orion has a lot of new functionality that is rare or doesn't existing in the most popular browsers. There's a lot of stuff to learn, and you want new users to use these new features as that's your value proposition over established apps. So it's in your best interests to reduce the amount of re-learning a user has to do.
As the famous UX saying goes, "don't make me think!!" Don't make users think about stuff that's already well established.
Vlad I would avoid the Steve Jobs comparison. The iPhone was a completely new paradigm throughout so it required brand new patterns as none existed. You're creating an iteration of existing interactions. I'm not saying you shouldn't innovate – that's the whole idea of Orion and I think it's awesome – but you have a limited amount of user attention and energy, and I recommend you spend that on the right features.
twingeofregret I believe that it is not deviation that matters, but whether something is superior UX or not.
I feel that your argument would be stronger if we for example decided to change the hotkey from cmd f to cmd h. Then there is stuff to learn and you are breaking the pattern. However cmd f in this UX will work in the exactly same way, find will be invoked, user will search, enter will skip to next result etc...
The only thing we changed is saved 30px on the screen for the user because the browser already has a multi purpose input field - omnibar and we do not another one.
Vlad Ultimately, it's your decision and of course I respect that. I'm just telling you what I know, and I've been doing this for decades (and more specifically in the browser space). I normally don't self-aggrandize, but this is an area I know a lot about. If you haven't already, do some reading about cognitive load.
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.
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. 
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.
Want to highlight this as an obvious flaw of the design. Whether it is really important from a use case standpoint is tbd.
twingeofregret At one point the search bar and URL bars were separate and now they are merged. Is it time the find bar and URL/search bars are now merged also?
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:
might not get fixed; planned to completely rework the find in page functionality. check https://orionfeedback.org/d/644-better-find-on-page
