100
Merged 3 posts from Find bar tweak.
    14 days later

    Tbh i have a hard time finding a reason why adress bar would not work, or why it would interfere with something else. since you arent going to change the URL in the middle of a "find" anyway. so in that sense it a good utilisation of space. but it would deffinitly feel weird, and take some time to get used to. but the question is if that not the only problem? getting used to it. i remember when they included search engines in the adress bar.. that was also really weird to begin with

      Think about this workflow if the address bar field is replaced by "find in page":

      1. I go to a site and want to search in the page

      2. I click into the address field and type my search terms

      3. Once I'm done, I want to search google for something else, but when I click into the address bar, it's no longer searching Google; it searches the page I'm on

      4. How do I get the address bar back to searching google, or entering a URL?

      5. Why should such a fundamental feature of web browsers be different in Orion? How is the change to merging the URL/find in page improving my use of the app?

      My point throughout all of this: how does merging the primary feature of the address bar (to go to an address, which includes web searches) improve the experience? I haven't seen any clear example of how this change improves the experience – it's different for the sake of being different.

        twingeofregret

        4.

        you press on the little X that appears inside the adress bar or the done button that comes up when its in find mode which you have to press in normal find mode on browsers regardless to exit it.

        I can see your point tho if you know that you allready want to search on the next page you are going to.
        I can also follow your point that it doesnt add anything, i think the overall point when it comes to improving the experience would be its less intrusive and lets you see the page in a cleaner way, where you can ofc argue that the few pixels that current find takes up, isnt a whole lot

        Another thing i came to think of is, that even tho there is some logic to having everything in one bar. the 2 functions that address bar has right now of going to an URL or a Search result. are both things that will make you leave the page you are currently at. its kinda counter intuative to introduce something that doesnt do that, since you are so trained to that any modification in that space will take you away from current page. which is the opposite of interacting with the page as find does

          I love the idea of having find be built in to the address bar. It’s always visually jarring when another box shifts the layout of the page, or even chrome’s popup.

          It doesn’t matter how long the bar is because escape is easier than pressing wherever the x button is.

          I liked Vlad’s initial mockup, but there needs to be way more contrast so that it’s clear the address bar has changed modes. Perhaps the omnibox could be outlined in yellow, and the words “Find in page:” could be bold?

            Here is a mockup:

            • When find in page is active, the address bar is outlined in yellow.

            • The delete icon clears the current entry, find mode remains active

            • The arrows move to the previous/next instance

            • The done button exits find mode

            • Pressing esc also exits find mode

            • Pressing cmd + l exits find mode and highlights the entire URL

            • The filter icon can be clicked on, and brings up a tooltip with additional options.

              This design creates localization issues (especially in languages like German), and more importantly, it's not at all accessible. This is a key tenet of creating accessible experiences: don't overload UI elements with multiple modes/features, as it makes it more difficult to navigate using a screen reader or in magnification mode.

              Saving a few pixels isn't worth the combined effort of anyone who's never encountered this workflow before.

              Also, @ForumNinja404 – how do I get into "find in page" in the first place?

              I'm all for UI innovation, but changes to well-known interactions need to justify their existence. Saving screen real estate might have been important five years ago, but it's mostly a moot issue on modern laptops and screens.

                twingeofregret
                How do I get to find in page in the first place? The same as every other browser, cmd + f.

                The buttons can all be keyboard focusable with tab, shift + tab, space, etc..

                The additional options menu can be brought up when focused on the filter icon and selected just like any other form controls. Option pop-up can be wider for German languages so there’s no issue there.

                I fail to see how this implementation is any worse than Chrome (which doesn’t have additional options at all & doesn’t label the box “find in page”) and Firefox which displays the bar at the bottom of the page whereas all other interactions take place at the top of the browser.

                If you are an expert on accessibility, then please correct the issues you have with my design. I am not claiming to know everything.

                It has the exact same features as all the other browsers, only it takes up less space. The user is clearly notified they are using “find in page” and all interactions are keyboard accessible.

                I disagree that moving the same user experience 30px or shoving it in a floating search bar is somehow better UX. The user shouldn’t have to guess where the box is going to pop up.

                  @ForumNinja404 The most accessible design is generally one that leverages the user's existing knowledge of how something should work. The popover find field isn't great, but as you noted, it's a common practice amongst web browsers. What would be even better is a find field that's always available, but that could reduce usability for folks who don't use accessibility features.

                  @Vlad I tried that browser and it's a pretty terrible experience. Try this: turn on VoiceOver, launch that browser, and then turn the brightness on your screen down to zero. Try to load and navigate to pages uaing only the keyboard and the voice descriptions.

                  In Kaktus, if you hit command+f there's no indication that the search scope is now the page – VoiceOver just says that a text field has focus. That browser has other major issues (there's no way to put focus in the address bar using cmd+l, for example).

                    twingeofregret The Kaktus browser was built by an individual as an experimental project. It hasn’t been updated in three years.
                    I think Vlad meant to test the find functionally to get an idea for what it looks like, not to take it as a final product.

                    Obviously the design isn’t stellar in that example, but we could definitely build off it and add better accessibility w/ voice over and keyboard navigation. (hence my suggested mockup)

                    In regards to your point about not having an always available button, this could easily be added as an option within Orion’s editable toolbar.

                    this coupled with the macbook automatically dimming its screen in some conditions makes the number (next to the 'x' circle) almost "disappear", any suggestion on making the default colour just a tiny bit darker tone of grey?

                      18 days later
                      Merged 2 posts from Dim number for find-count field?.
                        25 days later

                        Brief Summary
                        It would be nice if when you search for something using Command + f, Orion would tell you what the index of the current highlight is.

                        Details:
                        In other browsers, for example Safari, when you search for something using command + f, you are told for example1/44 or 20/44 so you know where exactly you are. It could be displayed as {index}/{number of matches} like in chrome or '{index} of {number of matches} matches' like in safari.

                        Image/Video:
                        Safari

                        Orion

                          Second this, I was almost ready to suggest the exact same feature.

                            Merged 2 posts from Show the index of the highlighted find match.
                              3 months later

                              Having find be built into the address bar is a cool idea. Just throwing this out there, would it be possible to have it only take over part of the address bar rather than the whole thing? Kind of like a nested bar or maybe a temporary split until they exit find or go to a different site by clicking on the "smaller" split adress bar. Might be a way to work around some of the issues pointed out while still making good use of space and have a cleaner design.

                              • Vlad replied to this.

                                Vlad

                                This is a VERY rough idea of what I had in mind (my first time putting together a mockup so please forgive any design discrepancies):

                                I think the area that find takes up from the address bar can be dynamic based on what is typed in, that way it could extend or reduce in size. I think the filter option from @ForumNinja404 is a clean option so I included the icon in this one too.

                                Alternatively, instead of nesting the find bar into the address bar, the could share the same area like in the mockup but just be in their own separate bars, side by side if that helps with usability and clarity.

                                Hopefully this makes sense 🙂