90

A lot of this was discussed in discord here

Problem

  1. The terminology that Orion uses is confusing. "Window" refers to both the literal window and also tab groups, where there may be multiple within a single traditional window. This is confusing to beginners and long time users alike.

I use "window" to refer to the traditional window and "tab group" for orion's "window" heron out

  1. The way tab groups work when switched in-place is not well defined. Because of how tab group switching works, there is no indication to whether a tab group that was switched out for another one is suspended or still active. This can be a major barrier to entry for users, since it feels like a risk if they switch away from a tab group that its contents may be suspended.
  2. There is no spacial grasp of what a "workspace" is. Workspaces (or groups of tab groups) is an extremely abstract concept in the orion-verse. There is no way for users to conceptualise what their workspace is like, because as mentioned in 2, non-active tab groups just seem to disappear into the void. This is in contrast to browsers like Arc, where the tab groups are positioned spacially to the left or right of each other.
  3. These all act as a barrier to entry for more advanced features like workspace snapshots. If a user doesn't have a conceptualisation of their workspace, snapshotting it doesn't feel like an easy feature to use. Its also not very discoverable, hidden away in the menu bar.

Proposed solution


Above is an image edited in Preview illustrating what I see the "windows" (to be renamed to "Tab Groups") sidebar looking like.

For those familiar with Arc, the concept takes Arc's concept of "temporary tabs" and apply it to tab groups instead. On the top are all the "saved" windows along with their tabs, and below are all the temporary windows.

This view can be usable as a substitution for the vertical tabs view, except that clicking a folder allows you to "zoom in" on that tab group (essentially in-place tab group switching, which orion already has), bringing you back to the normal orion view.

When the user selects a tab group (the row items with the folder or the dotted square) or a tab within a different tab group:

  • If a window with that tab group active is open, it switches to that window and makes the relevant tab active. This prevents multiple windows opening the same tab group, which is just a weird thing to happen.
  • Else, if in vertical tab mode, it switches to that window. The sidebar then switches to the "Tabs" sidebar, with the tab row items animating from their position in the "Tab Groups" sidebar to the "Tabs" sidebar.
  • Else, in horizontal tab mode, it switches to that window. The sidebar then hides.


The rectangular window switcher (shown above) will be changed to "zoom out" to the "Tab Groups" sidebar. It will not affect the active tab or tab group.

A middle click or right click -> open in new window opens it in a new window, like orion's non-in-place switching.

The + button creates a new tab group or temporary tab group, depending on which one was pressed. The orion team might choose to only include the temporary tab group + button, since thats more in line with the current cmd-N behaviour.

Edge cases

  • Horizontal tabs with the tab groups sidebar: It will just show both, just like how Safari does it. Duplicate tab bars might look funny, but apple does it so eh

What this achieves

  1. It gets rid of the question of where tab groups go. When you focus a tab group, you're just "zooming in" into parts of the tab tree. It makes sense where the others are, they're just above/below out of view. Maybe over-scrolling vertically would switch tab groups, i dunno. Then, they can be suspended or closed the same way one would in a vertical tab tree; its just a upwards extension of the tab tree.
  2. It clarifies temporary tab groups vs named tab groups, since you'd just be able to drag and drop the tab groups (or the tabs within the tab groups!) from the named to temporary section, vice versa
  3. With such a unified view of tab groups and their tabs, the workspace snapshot feature becomes a lot clearer since you can see your whole orion workspace in one place.

Example use cases

Internet rabbit holes that the user may not want to close. For example, as a developer, I frequently go on rabbit holes about something I have to implement.
These tabs are too commonly used to be in another tab group, where it takes effort to switch to. However, they aren't used enough to be sprawled around my primary tab group. I would use this concept to put the tabs in a different tab group, but with the window switcher I can easily switch to them without worrying about the status of my tabs.

How other browsers implement this

Arc has "Spaces", which are tab groups that are spacially positioned in a horizontal manner, where swiping left/right on the sidebar switches between them. This results in amazing workspace conceptualisation, since the user has them spacially positioned in their minds.

This concept also reuses the "temporary tab" idea of Arc. Arc's sidebar is split into a section for permenant tabs and temporary tabs, this concept uses that except for tab groups instead of tabs, to represent named tab groups and temporary tab groups.

How this extends feature usefulness

  1. It allows the user to see all their tabs within a profile AT ONCE. The convenience of this feature cannot be understated. Any workspace features (like snapshots) benefit greatly from this.

    TheOtherKai Thanks for this New Year's gift.

    Before engaging in discussion I want to make sure you are also aware of these two popular feature requests and any change in sidebar should solve the problems presented here:

    https://orionfeedback.org/d/3658-move-url-bar-to-side-with-vertical-tabs/
    https://orionfeedback.org/d/4408-window-switcher-sidebar-should-have-the-option-of-showing-tabs-also-bookmarks-reading-list/

      TheOtherKai

      Correct me if I’m wrong, your proposal is that rather than groups be in a dropdown, they are shown directly in the tree? I’m not opposed to that, it would make things a bit easier to understand and allow for dragging tabs between groups.

      However, The distinction of temporary tabs seems unnecessary and very misleading. Tabs will always exist within the context of a group whether or not the group is named, they don’t magically disappear. The sidebar should not have a section for unnamed groups, it should all be a unified tree.

      Overall, I like the idea but there are so many UX elements to consider.

      1. How does one zoom in / out of the directory tree? Zooming in defeats the purpose of showing all the groups at once. It’s also not viable with horizontal tabs. The current implementation (while less transparent) works for both tab views and is confined to a single button.

      Why not have the full tree always visible? When the user switches to a tab in another group, the other groups collapse and the current group is marked as active.

      1. How are multiple windows handled? While I’d generally agree that a group should only be open in one window at a time, this makes the new tree less powerful.

      What happens if a user has 2 windows open, one with group A and another with group B?

      If a user is currently in group A, what happens if they click a tab in group B? Do they jump directly to that other open window? That seems like a bad user experience.

      Groups are folders that are not bound to a specific window, they simply provide structure.

      1. The new UX would allow users to switch between groups quickly and move tabs between them. With horizontal tabs, there’s not an easy way to make this work. Collapsible accordions are notoriously bad and dragging tabs between them would get difficult with a single tab strip.

      The horizontal UI would have to be an entirely different setup. The easiest way I can think of is to rename the “Windows Sidebar” to “Group Sidebar and show the full tree there.

        ForumNinja404

        Correct me if I’m wrong, your proposal is that rather than groups be in a dropdown, they are shown directly in the tree?

        my proposal is that tabs are shown in the “windows” sidebar, not that windows are shown in the tabs sidebar. Small but important distinction.

        However, The distinction of temporary tabs seems unnecessary and very misleading.

        Perhaps my wording was off, I didn’t mean to suggest any such “temporary tab” concept. I’m just suggesting that how orion handles temporary tab groups should be similar to how arc handles temporary tabs.

        The sidebar should not have a section for unnamed groups, it should all be a unified tree.

        I argue this is even more misleading.

        Since this is the ”windows” sidebar, its not shown by default in a new unnamed window. What the user sees will be no different from what they would see right now. The separation is there because when the window containing the tab group is closed, that tab group is closed too. This is unlike regular saved groups, that retain. They have different behaviours and putting them together in that way seems nonsensical.

        How does one zoom in / out of the directory tree? Zooming in defeats the purpose of showing all the groups at once.

        The purpose of tab groups here is to have different things that you don’t need to see all the time. It helps not to hink of the regular tab tree as a "zoomed in" version of the tab groups tree, but that the tab groups tree is a "zoomed out" version of the regular tab tree. Within a tab group (the regular tab tree), you see what you would normally see right now in Orion. "zooming out" (probably by clicking the window switcher) just shows you your other tab groups, that you may not need all the time.

        For example, I usually use tree tabs in a way similar to what I'm proposing, within a single window. I collapse + suspend them whenever I don't need them, and do the opposite whenever they are needed. This is so that when they're not needed, I don't see them, but I can easily (within one click) see what tabs there are and switch to them if needed. My proposal is just a more integrated version of that.

        It’s also not viable with horizontal tabs. The current implementation (while less transparent) works for both tab views and is confined to a single button.
        and
        The new UX would allow users to switch between groups quickly and move tabs between them. With horizontal tabs, there’s not an easy way to make this work. Collapsible accordions are notoriously bad and dragging tabs between them would get difficult with a single tab strip.

        Apple shows both, but Vlad mentioned in the discord that it is an inelegant solution. My idea for this is that the current tab group within the Tab Groups sidebar doesn't show its tabs, and they are instead shown in the horizontal tab mode.

        Why not have the full tree always visible? When the user switches to a tab in another group, the other groups collapse and the current group is marked as active.

        Because you might not want to see the other tabs within other tab views. The Tab Groups sidebar is not intended to be a full replacement for the vertical tabs sidebar.

        How are multiple windows handled? While I’d generally agree that a group should only be open in one window at a time, but this makes the new tree less powerful.

        I decided to only allow one open window for each group at a time because that is how Orion currently works. My proposal would not make orion's tab groups any weaker than they are now.

        If a user is currently in group A, what happens if they click a tab in group B? Do they jump directly to that other open window? That seems like a bad user experience.

        I'm thinking that this is similar to current in-place window switching when the target window is already open. Orion just switches to the already open window, and I think that this is the best user experience in this case. Other possible behaviours:

        • The existing window closes, current window switches in-place
        • The active tab groups in the windows swap
          But I think just switching to the open window is the most predictable.

        Groups are folders that are not bound to a specific window, they simply provide structure.
        Exactly, thats why I want to fix the terminology used.

        The easiest way I can think of is to rename the “Windows Sidebar” to “Group Sidebar and show the full tree there.
        Well yeah, thats kinda the proposal in a nutshell. The only additional thing is the separation of the temp and named tab groups.

        Vlad
        With regards to these ideas, my idea would work fine with the sidebar url bar, since its just an upwards extension of the vertical tabs concept. It is a revamp of the "Windows" sidebar and doesn't have a large impact on the regular Tabs sidebar.

        As for joint sidebars, I don’t think that my idea would work very well with it. Since it could show EVERY SINGLE TAB that the user has (if all tab group disclosures are expanded), its going to be so vertically tall that adding other sidebars to the bottom would be such a hassle to use that it wouldn’t be worth using. The only way I see it working is if its implemented similar to VSCode (image below), where each section can be resized and each scrolls individually.

          TheOtherKai changed the title to Improvement to Orion's "Windows" Sidebar .

            The important things that I think orion needs to solve before it can grow out of this issue are:

            1. The terminology needs to change ("window" -> "tab group")
            2. The "workspace" must be visualisable
            3. It needs to be obvious what the state of tabs within non-active tab groups aer

            The way this proposal solves point 2 is by animating the transition, so the workspace is just an extension of the tab groups. 3 is solved because tab groups behave similarly to the vertical tabs sidebar, so you can see that the tabs are/are not suspended, and you can take actions on them by right click suspend tree as you would a tab tree.

            8 months later

            Upvoting this one, and saw it as I was writing out my own feedback suggestion.
            Something like this, from another browser called Arc:

            I think it's beautiful, and it brings the content forward. I like the idea of having everything on the sidebar, and making the top minimal to nonexistant like this.

            2 months later

            This is how vertical tabs work currently, A lot of extra space in the sidebar.

            Moving the url bar to the sidebar would provide more vertical real estate, without sacrificing space in the sidebar.
            eg taken from arc browser

            • Vlad replied to this.

              I agree. After using Arc for a few days I much prefer their layout of vertical tabs.

                5 days later

                alakhpc Thanks!

                Putting aside the usability of a very short address bar, It is not just the address bar. Currently I have 10 toolbar buttons and few extensions in my toolbar. Where would these go?

                  8 days later

                  Can you clarify what you expect to be there?
                  Currently arc only shows extensions up there, which imo are not frequently interacted with

                  going through all the popular extensions in Orion, none of them require any interaction (if you consider keyboard shortcuts for password managers)

                  The only times I've found myself reaching for the bar is disabling uBlock for compatibility reasons, which is infrequent enough that a 0.2s animation is perfectly acceptable

                  • Vlad replied to this.

                    alakhpc By default Orion has

                    Privacy, Website settings, Bookmark, New Tab, Tab View, Downloads and Share - all frequently interacted toolbar icons. I have a few extra extensions on top of that.

                      new tab can be next to the open tabs

                      The share/bookmark icons are here in arc, but these seem to be quite inaccessible unless you know what you're looking for so probably not a good idea

                      The downloads is quite neat though

                      Maybe a seperate "frequent extensions" row somewhere here on the sidebar could be handy? just random thoughts

                      • Vlad replied to this.

                        alakhpc Thanks for thoughtful feedback.

                        That would require considerable UI work and I am not sure the solutions proposed are all that intuitive or user-friendly. They may look nice, but looking and using are two different things. HIG exists for a reason for the last 15 years.

                        We are open to a more user friendly solution and we are already working on a changes to our vertical sidebar to make it more powerful, while remaining native and HIG compliant.

                        2 months later

                        It'd be nice to have an option to move the address bar and other top bar icons into the sidebar, like Arc does it:

                        Saves a bit of space and looks nicer, in my humble opinion.