View subspaces while the Spaces-bar is minimised.

[HansJK]

Is your suggestion related to a problem? Please describe.

When viewing subspaces in a space, the space-bar automatically expands, and takes up a huge amounts of valuable screen real-estate. This makes Element take up a lot more space than what's necessary, and it looks very clunky, aseptically on small screens.

Describe the solution you'd like.

You should be able to view sub-spaces while the space-bar is minimised.

Describe alternatives you've considered.

It could be solved like this:

My inspiration is from Discords server folders:

Additional context

This does mean that you won't be able so see the names of the subspaces unless you hover over them. But if it's a space you use a lot, it won't matter, since you know it well. And this won't be an issue if #17378 is added, since it will show the subspaces in the room list anyway.

[HarHarLinks]

I like the mockup, but how would you deal with multilevel subspaces?

[jerrykan]

At the moment I've been avoiding using sub-spaces because they are not readily accessible from the minimised side-bar. I'd be really keen to see something like this implemented.

@HarHarLinks My suggestion would be to cap it at 2nd or 3rd level (like a lot of threaded comments systems do). If you have heavily embedded your spaces then you probably aren't after quick access. Alternatively if you do want quick access to a subspace that is beyond the 2nd/3rd level, then implementing some sort of sub-space pinning might be an option (as mentioned in element-hq/element-meta#306)

[HarHarLinks]

personally, before/when toying around with subspaces first time, I was expecting something like this. further sublevels would be shown or hidden as a tree, like regular spaces (consistency...), depending on how wide you drag the space panel to be, like you can the room list. the "expand space panel" toggle becomes a "show space labels" toggle.

[jerrykan]

I don't mind the idea of the spaces panel width determining the depth of the tree to display, but for the "most minimal" panel width should show the top-level spaces and allow expanding to the 2nd-level spaces (slightly adjusting your mockup):

[smichel17]

The current implementation doesn't handle arbitrary depth subspaces, either. At some point you run out of horizontal space…
I'd be satisfied with indentation, like the current implementation, but just with the labels hidden, as @HarHarLinks described.

However, if you really wanted to handle arbitrary depth using something like @HansJK suggests, you could take inspiration from filesystem hierarchies and, when expanding a sub-space, collapse ancestors (and siblings?) into a "go up a level" button.

[ShadowJonathan]

An idea i came up with is to do some "navigation" in the sidebar, where you would navigate to subspaces whenever you wish, some mockups;

This'd then be the default view, where you would see spaces like before, but in addition, there'd be a "go right" button right next to a space. This would only show up if there are subspaces in this space, after clicking it, the view changes to something like this;

A "sub-view" of the space, which shows the space that's being represented (at the top) with direct subspaces to click on below, and another "go into subspace view" button on one of them.

This, in my opinion, is proper nesting while not disincentivising using subspaces. You can navigate to subspaces like this by clicking the right arrows until you have the view you want. Clicking on the spaces themselves would have the behavior like today; show the spaces' rooms in the room list.

I got this inspired by Android's navigation views, which a. always have a back button, and b. go "left" to go back (or up), and "right" to go deeper into the app. Here's that represented, notice how it could also be seen as a "nesting" of views into themselves, which is what i did here;

Large slightly off-topic image

[HarHarLinks]

While it solves a bunch of complicated cases with deep nesting etc, the downside of ShadowJonathan's mockup compared to the earlier ones is that now you need to go back and forth and not have everything in view at once (something I and probably others purposely did include).

[ShadowJonathan]

I also got a small taste of that too, but i think then the UI starts getting too verbose;

Large image

[DIzFer]

Until a "proper" solution for collapsed subspace viewing is decided on: Can the bar remember its last state? IMO having it permanently open beats having to click the expand button every load (and, actually, all of the proposed solutions)

[maisiliym]

This is blocking the emergence of independent networks which span cross-federation. Spaces are meant to achieve such a development. It's silly to stop a few inches from this milestone. The simplest implementation would create a truly-scalable exploration experience for matrix.

[ShadowJonathan]

@maisiliym while i agree with your statement, i think for the purposes of Element's work-prioritization and triage, it would need some evidence / backing up of information on which you base this, or at least a comprehensive explanation, else i think it wont be taken seriously (enough).