-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When a Space contains Sub-spaces, the room listing shouldn't show a flat list including all subspace-rooms. #18905
Comments
Note that moving the sub-space list to the second column would have another advantage. Notice how "Contributor Discussions" is truncated to "Contributor Discus..."? |
Here's a screenshot of the Rust Discord setup: This is basically "option 3" of my suggested approaches above. It seems superior in a lot of ways:
This particular approach (as opposed to my "option 2") also has the advantage that you can still see everything at once and move easily between subspaces /sections. |
@SimonBrandner I notice you've thumbs-downed this suggestion. I'd love to hear the opposing viewpoint, and maybe we can come to something that fits better? |
For me the Discord model doesn't work well with very large Guilds, I often find myself having to scroll the list loads to be able to find unreads/notifications as there isn't a way to sort by recency. A similar issue would be the case if we split up the room list more than just People/Favs/Rooms because then each list would be recents-sorted but not the whole list. Another issue with this proposal is a room may exist in multiple subspaces and thus now then be shown multiple times in a single room list in multiple places, confusingly. |
I see the use case for this, but personally I would not like it because I prefer to have my spaces collapsed and just use the space for the current situation (work for example) selected. Then browse the room list including all sub spaces like I did before spaces using keyboard shortcuts. So an options in settings to choose would be best imo. EDIT: having to constantly switch spaces, in addition to switching rooms, would slow down my workflow. Unless there is a new keyboard shortcut to change spaces. I'm very happy |
I would like to +1 what @mattdm is saying/proposing. Current implementation of spaces doesn't help with organizing my rooms in a logical manner, since top level (or higher level) spaces also include all the lower level channels. This become more evident if you have rooms in a higher level space that don't belong in any sub-space and the only view with these rooms gets "polluted" by all the rooms in all the lower level spaces. As @Twi1ightSparkle said, I would be happy with a setting to choose between the two behaviours and I'm willing to try implementing this if:
|
@Twi1ightSparkle Ah, I see. I think the primary difference is coming at this from being a heavy matrix user before spaces existed, vs. me coming into this and wanting spaces to provide a curated experience for our users (who might not be familiar with matrix at all). I think, though, that these things could coexist? Public spaces could work like I'm suggesting, and then you could create your own private spaces with whatever arrangement you want. |
I want to note another weirdness that happens here: rooms are only considered a member of the top-level space if you've joined the subspace too. That leads to some serious cognitive weirdness. In my example at the top, is "Information" a member of the "Fedora" space? It depends. |
That is a separate issue: #17293 |
Well, it could be a separate issue; or, this could be a solution to that issue. |
No, it is a technical issue of not having access to the data via /sync - regardless of what the UI/UX looks like. |
But if you aren't trying to show rooms which are within subspaces as also members of the top-level space, it's irrelevant. That issue is only an issue because they're treated this way -- it's an example of the "weirdness" I mentioned. |
Oh! I have come across another situation related to this. We have one sub-space, Project Teams, which contains a fairly long list of sub-teams. In some cases, a team has more than one channel. I'd like to group those with a further sub-space -- say, for example, Infrastructure. As it is, that grouping is helpful to the members of that subspace, because it makes it possible to drill down to just those channels. But it's less useful for people who aren't, because now all of those rooms are in their list in the Project Teams space -- not filtered at all. |
I think that adding a way to "pin" a subspace to the spaces bar so that the parent space doesn't need to be extended to show the subspace would more or less solve this? Alternatively, there could be some room state event suggesting a different presentation, but the client should be compatible. |
It feels to me that this discussion is simply a repeat of the Home discussion (#18093) just one level down. The solution should include the results of the experiment there and allow the user to select "Show all rooms" for the parent space. Or maybe even just inherit that setting globally since it seems to be a conceptual thing, so if someone has indicated they don't consider Home to be an Other category, then the same should apply to parent spaces. @MayeulC that would be element-hq/element-meta#306 I think. |
I think this should ultimately be a per space setting. There are two modes at play here.
Like @Twi1ightSparkle, I also primarily use my spaces for switching between contexts. When I switch to a context, I expect the space to filter down my total collection of rooms to those particular to that context. But when in that context, I expect for everything that is a descendant of that context to be visible at once and sorted by recency.
I think I like this suggestion, provided I could get the context-like behaviour I want by creating a private space and adding the public space as a sub-space. Perhaps we should just differentiate between the two use cases on the UX level since these two use cases seem fundamentally different, even though both would be implemented using spaces. Something like "Contexts" and "Guilds" (to draw a parallel with Discord). There are other use cases I would like to see in the Context case, such as silencing notifications from non-member rooms when it is activated. |
Just to pitch in: However, for our customers, the current implementation where rooms from sub-spaces float up and show up in higher level spaces renders the solution practically useless. Our preferred solution to this would be:
|
High Agree, When I used to use discord and finding huge, active servers It was very fustrating just to find one specific channel under the 5+ or so categories. Just to chime in with my own idea, having some sort of "folders" within the sections that give the freedom to the user of only wanting to be in and see a specific set of rooms within said space. |
+1 though I am already addicted to this behavior in Cinny client, but when switching to Element, I get lost in scroll when there are hundreds of rooms in subspaces and then the only option is to left is remembering room name and searching it. |
Duplicate of #17378 |
Your use case
Our Space has a lot of rooms -- there are probably going to be hundreds. In order to make that not overwhelming, I want to organize these via sub-spaces. However, the UI considers all rooms in sub-spaces to be rooms in the top-level space too. Observe:
(Please ignore visual styling ... this is a new server in progress!)
We don't even have all of our rooms configured yet, and the list is already basically useless. It's even worse on mobile.
I would really like one of:
> Rooms
list.> Spaces
after> People
and> Rooms
which lists nested spaces.> Rooms
, but broken up into sections with Spaces serving as a section headersThe could also get sub-spaces out of the leftmost bar, allowing that to take up less space.
Have you considered any alternatives?
We could create multiple top-level spaces and not use nested spaces. This probably would be fine on our own server, but is less convenient for anyone coming in from a federated server since we'd have to send them a bunch of different space invites.
Additional context
This is really important to us; one of the chief reasons for moving to Matrix is for ease of use for new users, and this feels like an impediment to that.
The text was updated successfully, but these errors were encountered: