Miav

    • Aug 3, 2023
    • Joined Jun 4, 2022
    • 1 discussion
    • 5 posts
    • 0 best answers
    • 9 points
    • In Compact tabs

      vladstudio

      compact tabs are not so compact after all

      Generally, the objective of compact tabs in this instance is reducing the usage of vertical space, not horizontal. With that being said, Safati's compact tabs do not actually waste any more horizontal space than chrome does, in spite of the gap between the tabs.

      Both in case of chrome and safari compact, the actual gap between the titles of adjacent tabs is around 40px on a 16" MBP.

      Please make sure to take a look at a bold idea I described here

      This is already a feature in both Safari and Orion, under View -> Always Show Toolbar in Full Screen

        • In Compact tabs

          Vlad
          Safari 15:
          +More tabs visible at once (with their titles)
          -Moving URL bar that shows only around 24 characters

          Orion proposed implementation:
          +Static URL bar that shows around 32 characters
          -Fewer tabs visible at once

          Being able to quickly switch to the tab I want is important for my workflow, so having around 6 tabs visible instead of 8 is a major con.
          Being able to see a URL past the TLD or being able to quickly click on the URL bar is not important to my workflow, so being able to see 33% more of the URL and having the URL bar be fixed in place is only a minor pro.

          I hope that's clear enough, but I'd be happy to provide more feedback if needed!

          • Vlad replied to this.
            • In Compact tabs

              Vlad I think that a compact mode in a browser is primarily about tradeoffs. You get more real space to show the actual page, but you need to give up some functionality of the top bar. When only 5 tabs are open, then your proposed solution is the perfect compromise, you get a static, visible URL bar and you can read titles of all your tabs too.
              But quite often I have more tabs open. Because many of them have the same base URL, I can't differentiate them just by the icon so I check the setting to always show tab titles. In Safari that gives me 8 visible tabs on my Macbook Air.
              I find this good enough. It lets me have a couple of github repos open, some docs and some stackoverflow pages.
              Your proposed solution takes up about over a quarter of that space. I shrunk my Safari window to "simulate" it.
              I get at most 6 visible tabs, which would be a serious hit to quckly switching to the tab I need. In return I can see more of the URL of the page of my currently active tab and I have URL bar that doesn't move around.
              As per my previous post, I very rarely need to examine the URL past the TLD, so I gain negligible value here. And if my workflow did involve frequent URL viewing or editing, I still wouldn't be able to see the full URL in the bar you proposed for many webpages.
              Safari, with its hybrid tab/url, let's me see 24 characters of the URL in this instance:

              In your example, the URL shown is 16 characters long and the bar could probably fit twice as many, so 32. A 33% improvement over Safari (also, in your demo, 8 characters, so around a quarter of the URL bar, is taken up by the https://. Seems redundant given I can see the lock icon. Safari does not show it.). The website I'm on right now, https://orionfeedback.org/d/92-compact-tabs/82 is 46 characters, so I couldn't see the number of the reply, which is at the end of the URL, in either case.
              The other benefit of your proposed solution is that the URL bar stays in one place as opposed to jiggling all over the tab bar. It's certainly nicer having it be static, but it's really not a big deal for me since I almost never click on it anyway, just CMD+W, CMD+T and enter the URL like that.

              So yeah, your proposed solution does look really slick and I'm sure a lot of people would love it, but for me and other people with similar workflows, it makes a much worse tradeoff compared to the Safari 15 implementation when it comes to productivity.

                • In Compact tabs

                  My opinion on this would be that out of existing implementations, Safari 15 compact tabs are the best. They look elegant, function similarly to iOS tabs and save space.
                  As far as I understand, the only issue the dev team has with the Safari implementation is that only a small portion of the URL is visible, as per Vlad's post https://orionfeedback.org/d/92-compact-tabs/45. Orion's early adopters are presumably fairly opinionated power users, so appealing to everyone could only be done through deep customization, but as far as the general case goes, I think the URL bar is generally fairly unimportant for the following reasons:

                  • Examining the URL is useful for ensuring you're not visiting a scam page, e.g. wlkipedia.net when you were looking for wikipedia.org. Even a tiny URL bar, like the one in Vlad's screenshot, is big enough to examine the base URL which is enough virtually all of the time.
                  • One might want to identify the subpage they're on by examining the URL, but it's generally better to just look at the page title. Consider an arbitrary AP article: https://apnews.com/article/science-australia-a9bdf5ada0b5fcf7b9b9b4689808295a. The URL provides very little info. All that I know is that it is related to science and Australia. The tab's title on the other hand is "World’s largest plant is a vast seagrass meadow in Australia | AP News" which, if I had multiple tabs open, would let me identify the one I'm looking for immediately and easily. Safari 15 compact tabs have a setting to make titles always visible, which I find to be the optimal solution for this scenario. Screenshot:
                  • A user might want to occasionally perform URL manipulation, but in the vast majority of the cases, it's a simple one, restricted to the beginning to the URL, such as changing reddit.com/[..] to old.reddit.com/[..], so again, a tiny URL bar would do.

                  In addition to all the above, I believe it would be possible to have the best of both worlds by:

                  1. Growing the URL bar to say, half the horizontal screen size, once the user clicks on it i.e. highlights the URL i.e. starts editing the URL.
                  2. Making it so that scrolling sideways with 2 fingers on a trackpad while hovering mouse over the URL moves the URL, allowing the user to read it easily even with a tiny URL bar. This one might interfere with scrolling a long tab bar, as the same gesture is used for scrolling a tab bar when there are too many tabs to fit them in the bar all at once.
                  3. Removing some of the icons, which - as Vlad pointed out - can take up a third of the URL bar space. In particular, reader icon is contextual only so doesn't usually appear anyway. Refresh can be tucked under the more options icon as most users use the hotkey anyway. Padlock is kinda useless and iirc Chrome has begun experimenting with removing it. I believe it would be far more useful to instead have a red, unlocked padlock on http sites and no icon for https sites.

                  And in the rare case that the user is performing a task that simply requires the full URL to be visible at all times, such as certain kinds of web development or pentesting, they could simply:

                  1. Opt out of the compact tab view

                  or

                  1. Switch to the vertical tab sidebar mode

                  In conclusion, I believe that both the mockup Vlad posted (https://orionfeedback.org/d/92-compact-tabs/51) and the IE9 interface (https://orionfeedback.org/d/92-compact-tabs/59) which he cited as a rough goal, would be a far worse option than the Safari 15 compact tabs for all but very specific workflows. While it would be great to see this available as an additional option, I personally would much prefer to have more tabs fit the tab bar at once than have more of any specific tab's URL visible.

                  • In "Find on page" menu not showing if tapped on while scrolling

                    Steps to reproduce:
                    Scroll to the bottom of a long page, scroll up quickly and let go. While the page keeps scrolling without your input due to the simulated momentum, tap the "Find in page" button.

                    Expected behavior:
                    The find in page menu appears, allowing one to enter a query and search the page, presumably without affecting the scrolling animation in the background.

                    Orion, OS version; hardware type:
                    Orion 1.0.3.123, iOS 15.5, iPhone 12 Pro

                    Video: