Merged 8 posts from Make the find menu a bit fatter/shorter.
100
Better find on page
Vlad changed the title to Better find on page .
9 days later
Totally agree that this should not be part of the browser address bar. That's specifically for one thing only: changing the view of the current browser window (either by searching or putting in a URL). It will start to get messy from at UX perspective if you try to mash the find in page mode with the address bar. For one, it means the user has to figure out what mode they're in after they've searched within the page - am I in find in page mode, or can I type a URL and have it work?
There are very good reasons for keeping the two of these as separated UI elements and user confusion is a big one. Happy to go into more detail if needed.
twingeofregret Isn't address bar used for search in Safari on iOS (dont have phone now to check?)
Vlad Mobile operating systems while can be used as an example for certain small applications on desktop menus, does not make sense to reduce in size further for the sake of parity with mobile user interfaces when it leads to a reduction in total information received by the current user which is not either filler or redundant information brought about by means of usage of ancient UI standards or over-radicalized interfaces such as Apple's blunder with the touchbar and butterfly keyboard.
I was disussing a UX pattern, whether address bar can be used for something else than URL or not. Since precendent has been made hopefully we can discuss further @twingeofregret
- Edited
Vlad Yes, but as I mentioned it's a search that changes the site you're looking at in the browser. It's an issue of scoping – the address bar changes the address you're looking at, the find-in-page search is just for the address you're currently on. It's a mental modal thing: users have been conditioned to understand what the address bar does, and mixing it with another modal will be really confusing.
twingeofregret Perhaps if you try this interaction in a browser, it will not feel as odd.
This is the browser I originally saw it in:
https://github.com/azer/kaktus#download
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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.
- Edited
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. 