4

One of the great problems with Tab groups for a long time is that they hide Child Tabs from the UI — it can be very hard to find a Child tab if you have a number of windows and Tab Groups open at a given time.

Arguably the "simplest" solution would be to list Child Tabs in the Window menu, indented below their Tab Group parent, just as you see in the Tab Switcher app: https://apps.apple.com/au/app/tabs-switcher/id1406718335?mt=12

Having said that, it's true the Window menu length could get out of hand so an alternative might be to show children as a sub-menu under the parent Tab Group, but this would complicate the process of selecting the Tab Group without changing the active tab.

Thanks for any consideration — IMHO this is one of the key UX flaws that make Tab Group UX worse than it should be.

  • Vlad replied to this.

    transeunt I am assuming you are referring to Safari's implementation of Tab groups and that you haven't tried Orions implementation yet (avaialble in release candidate builds)?

    Provided that this problem happens only when a user has a lot of tab groups/tabs, wouldn't a faster way to locate a tab be to simply search for it in the address bar, something Orion already has built in?

      Vlad Well indeed, I'm not sure…? I'm using 0.99.109.1-beta and I'm not sure what you're referring to.

      Looking in the Window menu I see no obvious way to know what peer tabs exist within a given open window, I just see the active tab title.

      I know one can also cycle through tabs via Ctrl-Tab, per window.

      …and "yes" as you say I can 'search' for a tab by entering a remembered fragment in the address bar of… any window I guess… it's open then to some interpretation what one should I expect to happen if when finding a match (in terms of what is an understandable interaction transition if I'm in window X and enter a URL that matches with a tab in window B. A more sophisticated user can guess, but I'm not sure it's the clearest interaciton… nonetheless, there are conventions to follow.

      Finally, that feature assumes I recall enough about a given page, it's URL or title perhaps (extra points if it includes meta-data or even page content.) But what if I don't recall, that it's just 'that page I opened after that other one, that… I think is around here somewhere'.

      The good old, basic "show users what's open" rule seems to apply here. When I don't have enough data/recollection for a search, then browsing is what we fall back on. In that case being able to see:

      Window 1 - Tab A

      • Tab B
      • Tab C etc

      …means that open pages are not invisible, and more importantly, are not findable.

      Perhaps though, there's something I'm missing. 🤷🏻‍♂️ ☺️

      • Vlad replied to this.

        transeunt Your suggestion makes sense, I was just wanting to get on the same page.

        First of all, ping me on Discord so I can give you access to RC builds as you earned the contributor badge.

        It is not entirely clear to me what your suggestion is.

        Imagine a situation with 10 windows and 20 tabs each. How would you show this in UI?

        Note that submenu may not be optimal because the top level is the window itself and it should be clickable (and clickable items usually do not have a submenu)

          Vlad Yes, agree scalability may be a risk and there may need to be 'sensible' upper limits on how many children might be shown, in the spirit that "some is more helpful than none"… but I agree, it's not the most satisfying answer.

          As counter argument, I'm using Tab Switcher and while that's a floating palette, not a standard menu, it is still ultimately the exact type of text list I'm describing.

          As for using hierarchical menus — of course you're right that the active tab serving double duty as the window title makes it a little harder, but would there really be anything wrong for the first child to be that same active tab repeated, such that one could select it…?

          Just a thought.

            Not familiar with tab switcher app, but I assume it's only job is to show tabs.

            Window menu (where I believe you suggest this existing) is already large and bulky.

            So maybe we should get back to the drawing board and consider the use case here - what are we trying to achieve and is there a better way to do it.

              Vlad my main "ask" is centred around the ability to find the tabs I have open.

              In all browsers child tabs are hidden from the UI so there's no easy way for me to find a page without knowing enough about its page title or URL, which at least I can re-enter in the Address bar and hope the browser will switch to an active tab rather than load the page again.

              I find myself opening (or leaving open!) arguably too many windows/tabs, on the premise I'll get back to "processing" them, but later finding them can be challenging, undermining the original intent.

              This is part of what brings up: https://orionfeedback.org/d/1076-searching-in-help-menu-lags-considerably-vs-safari

              …and similar motivation to suggesting a Tab Snooze feature could be valuable, i.e. https://orionfeedback.org/d/1005-tab-snoozing

              • Vlad replied to this.

                transeunt Can you give an example of any browser that does what you ask - there are more than 100 browsers on macOS one should be doing it?

                  3 years later

                  @Vlad done, tabs in a window are now shown under File->Profiles->{profile name}->Windows->{window name}

                  No one is typing