Option to disable Spaces bar

[BurnyBoi]

Your use case

When using a vertical monitor or using Element in a vertical window, the Spaces bar on the left can take up a lot of unnecessary space. There is a way to disable the communities bar, but not this new Spaces one.

There should be a way to hide the bar. Once disabled, Spaces would either need to be accessed some other way or have the bar re-enabled when there is a need to access them.

Have you considered any alternatives?

Currently Spaces can be kept off and aren't used so for now I'm leaving it off but eventually this will be enabled for all.

Additional context

No response

[t3chguy]

Shouldn't have put everything in a big giant commit then, ey? Something broke that worked before. That means a revert has to be performed straight away. End of story. This is just part of professional software development in general.

@thany that's not how it works. You can't remove all the supporting code for communities yet keep the communities bar. Synapse has stopped supporting communities also, so you'd be met with lots of errors trying to keep that code around.

[thany]

That is how it works, but in this particular case, a revert is no longer possible due to upstream API limitations, is what you're saying.

All the more reason to give this problem some elevated priority!

[t3chguy]

That is how it works, but in this particular case, a revert is no longer possible due to upstream API limitations, is what you're saying.

No. If you have feature X which depends on feature Y and you remove both X then feature Y, you can't just bring back feature X regardless of if they were removed in one commit or not. The supporting code will have gone and all you'll have is compilation errors.

[t3chguy]

so it just seems silly at this point to not wrap this up since the work was already mostly done https://github.com/matrix-org/matrix-react-sdk/pull/7128 and just needs to be merged into the latest SDK, then tweaked a bit more to account for a few more changes to the left bar since then.

No point wasting development cycles until product & design agree to what the UX will be like for users who disable it when they interact with spaces

[odiferousmint]

so it just seems silly at this point to not wrap this up since the work was already mostly done matrix-org/matrix-react-sdk#7128 and just needs to be merged into the latest SDK, then tweaked a bit more to account for a few more changes to the left bar since then.

No point wasting development cycles until product & design agree to what the UX will be like for users who disable it when they interact with spaces

Perhaps there can be options to:

1. Completely disable it
2. Arrow icon in the middle horizontally that would display the bar
3. Increased border size to know there is a bar collapsed
4. Display the bar when the mouse gets close to the edge where the bar is

I am pretty sure there are other ways to go about it as well. I actually forgot how Spaces worked, but perhaps anything similar may do the job.

[bdefore]

There's really not a window for the community to provide a solution in code here. The Spaces feature introduced a design problem and unfortunately shipped without sufficient consideration of use case of those who... don't care about Spaces. Let's complete the loop. Please raise the importance with that design team to consider the minimal use case. It's a messaging application first.

[t3chguy]

Completely disable it

Yup this is the way the PR goes, the issue is product won't land a feature like that as then you have no way to leave/manage spaces you are already in, there's a wider reaching effect here.

[weeman1337]

Questions to be answered:

• Users will loose room discovery in spaces
• Some room permissions depend on spaces

I think because of that users should still be able to join and explore spaces.

Currently some mock-ups exist here: https://www.figma.com/file/QTxqmDYaQiSU4I2KYHz35T/%5BSpaces%5D-Web---hide-spaces?node-id=3%3A3024

Some ideas that came into my mind:

Disabling spaces should enable „show everything in home space“

Instead of a magical switcher we could integrate spaces flat into the people/room list. Clicking on it could lead to the space home. So that users can leave spaces / discover the rooms from there.

[t3chguy]

Questions to be answered:

• Also what to do with the spaces the user is already in, there should be a way to leave them given they'll be wasting /sync bandwidth
• What to present the user if they navigate to a space via a matrix.to link

[thany]

@weeman1337

• Users will loose room discovery in spaces
• Some room permissions depend on spaces

Not if you merge the two bars, as requested months ago. With a viable CSS workaround.

@t3chguy

• Also what to do with the spaces the user is already in, there should be a way to leave them given they'll be wasting /sync bandwidth
• What to present the user if they navigate to a space via a matrix.to link

Same solution.

[giomfo]

From the recent mock-ups, I observed the suggestion to add a new preference "Hide spaces"

I would rename it "Hide spaces until I join a space" This option should be available only when the end user doesn't join any space I would remove this option (or mark it as unavailable) as soon as the end user joins a space The option would appear again if they leave all their spaces

Then people who don't want spaces at all, will be able to turn on this flag. This would hide the full Spaces UI (Spaces left bar, Space creation...) from Element, by keeping the Spaces handling in the code. As soon as they accept a space invite, the UI is updated to display the Spaces (Spaces bar...)

My request here is to be able to hide the spaces UI until the end user joins a space or decides to use them. We could not disable more strongly the Spaces because the product/design team plans to base new implementation on them

[BurnyBoi]

This option should be available only when the end user doesn't join any space

Having the bar hidden until the user joins their first space as an option for an Element instance seems beneficial, but ultimately, this thread is still about making the spaces bar always toggleable, regardless whether the user has already joined a space. As far as UI, there's been suggestions of a mini menu to still access spaces when the bar is hidden, as well as having a way to just quickly toggle the bar back on when needed.

[giomfo]

@gaelledel I think we may re-open https://github.com/vector-im/element-web/issues/22765 to handle separately these multiple requests about Spaces

[rufuskahler]

Removing 'Needs-Design' as will be resolved through EX work.

[t3chguy]

@rufuskahler removing X-Needs-Design means anyone can just start it with assets already provided in the issue, (e.g. community) - that does not appear to be the case, maybe you meant to remove X-Needs-Product - as without knowing how design expects the interaction to look this will be impossible to contribute.

[thany]

The spaces bar can be removed as-is. What additional assets could you possibly need to remove something?

[t3chguy]

@thany the product team doesn't want it removed, they want the functionality to be available elsewhere, so the UX to switch behaviours and the alternative behaviour need designs. Similar to Element X (EX)

[thany]

A checkbox should suffice.

[t3chguy]

@thany that doesn't explain how a user can manage spaces they are in without the space panel

[thany]

Then they check the checkbox. If you're not using spaces, uncheck to remove it. If you are, then check to reveal it. It's as simple as that.

[t3chguy]

Simply hiding spaces & invites is very unlikely to fly, they'll need exposed via alternate means, like a dropdown more akin to EX

[thany]

Spaces don't need to be exposed at all. If a user hides Spaces, it's for a reason. I can only really speak for myself, so when I hide spaces, it's because I don't use them and I don't want them taking up any space (especially not when they expand themselves at the whim of increasing window size, which I have to do every time Element starts because it's not able to remember its own size properly).

Users who do need spaces, can keep them visible. I really, honestly, genuinely don't see the problem here. Just hide the bloody thing, or don't. How hard can it be?

Either way, in my case, what would be my advantage of still having access to spaces?

[t3chguy]

Spaces don't need to be exposed at all

That's up to the Element Product team

[thany]

No, it should be up to the users. Otherwise can you please loop in the "Product Team" so they can explain themselves here?

[t3chguy]

Indirectly it is, but not up to the vocal users, but up to the wider userbase. The vocal minority often do not match the average.

[thany]

Either way, in my case, what would be my advantage of still having access to spaces?

Maybe they can also answer this, because I can't think of anything.

[jellykells]

Can someone please point me to the overwhelming user feedback that says "please don't let anyone hide the Spaces bar I want every user to have to see it"

[t3chguy]

I suggest waiting to see what the Product & Design teams have planned in this space rather than demanding a given solution. Users present issues & feedback, they don't get to drive the choices and implementation. The product is free. You're always welcome to fork it and make it work exactly as you hope and dream.

[jellykells]

So users don't really drive the choices made by the Element team. Well, thanks for being honest at least.

[t3chguy]

You can say "the contrast is bad", but not pick our colour palette. Just like here you can say you want a way to get rid of the stacked space panel bar taking up your valuable space, doesn't mean you can decide that there'll also be no way to manage spaces alongside that. If you want your own software designed just like you want it, try freelancer or fiverr.

[MonkeyBars3k]

I have tried making Spaces and been reading about them and still can't wrap my head around them at all. Is there a tutorial somewhere out there? I find the explanations on the blog extremely confusing. At its core, what even IS a "Space"?? Is it like a custom collection of users and rooms specific to one's user account, or what? I made a new room in my test Space, and it doesn't show up in Home. So is it self-contained or not, or in between? So confused. I can't imagine many users understand what they are, given the lack of introduction and how different they appear to be from other common chat app features.

[jellykells]

You can say "the contrast is bad", but not pick our colour palette

Not a great example, since the Element team has actually gone in the right direction regarding theming and given users the ability to pick whatever color palette they want.

Similarly, I think it is reasonable to give users who aren't interested in seeing or managing spaces a way to hide the interface intended to facilitate that.

[t3chguy]

At the end of the day a space is a room, if you're in a space and something happening in that space makes your push rules trigger, you'll need to see it otherwise you'll be getting pings/notifications without an ability to see them. You can't disable push rules for spaces in the spec today. Equally a space could create a lot of /sync bloat due to being filled with state events, so you would want to retain a way to leave it without needing to reconfigure your client. Again can't filter out spaces in /sync with the filters provided by the spec.

[MonkeyBars3k]

can't filter out spaces in /sync with the filters provided by the spec.

The Spaces rollout seems quite poorly planned from a UX point of view, from the feature explanation to making irreversible codebase and unalterable UI changes that waste large portions of real estate.

[jellykells]

I think /sync returning unnecessary data if the UI were disabled is a separate issue that shouldn't necessarily block this feature request, and I wonder how many users would even be aware that it was occurring.

As far as push rules go, I think the only notifications triggered by default for spaces is invites? I can see why you wouldn't want users getting an invite notification to a space and then not being able to view it, that seems like a legitimate concern. On the other hand, for users not interested enough in using spaces to have the UI visible, it seems minor enough that the Space bar toggle could be added as a Labs feature until someone might be willing to put in a spec PR to improve the /sync filters.

On that train of thought, would a PR implementing such a Labs feature even be considered for merge, or is this really "fork it" territory?

[t3chguy]

On that train of thought, would a PR implementing such a Labs feature even be considered for merge, or is this really "fork it" territory?

It is unlikely to be accepted given the product team has it in their sights, unless the author was willing to shape the PR into whatever the product & design teams had in mind

[jellykells]

Personally, I find Spaces somewhat useful (even if we don't have user flair back yet!), but the large and ever-present UI obnoxious. So for me this feature request is more like "let me hide it while you guys brainstorm something better" rather than a final solution, hence considering a Labs flag.

But I suppose if there's resistance to even adding a stop-gap solution, that's a dead end.

[t3chguy]

We're just averse to adding yet more unmaintained labs flags which are poorly covered by tests and increase tech debt. If someone wanted to revive https://github.com/matrix-org/matrix-react-sdk/pull/7128 and leverage our Netlify builds to keep it hosted that could be an easy interim solution