Add a UI to explore public spaces

[SimonBrandner]

IMO, this should be a completely different dialog from the current explore rooms dialog. This is to create a clear separation between spaces and rooms and to avoid confusing users. I think Discord can be a good place from where to take inspiration.

Related: element-hq/element-web#17244

Edit by @kittykat:

For this to progress, product need to have a proposal on best approach or options from developers/backend to chose how to proceed
In terms of UI, this could be presented in the new search experience with a "Spaces" filter, similar to "Rooms" that we will have in the new search dialog.
When a space is clicked, it should open the "Explore space" page.
On mobile, spaces and rooms are differentiated by round or square avatars, this could continue to be the way to differentiate them in the search results until search filtering is added.

• Web: add a "spaces" filter to the new search experience (needs design)
• Android: make sure that spaces are differentiated from rooms in the results
• iOS: make sure that spaces are differentiated from rooms in the results

See here for proposal

[aaronraimist]

keywords: search find

[cognifloyd]

I think "Explore rooms" could be reused to provide this feature, but it needs a filter to say "Only show spaces".

[SimonBrandner]

I think "Explore rooms" could be reused to provide this feature, but it needs a filter to say "Only show spaces".

This would work at first but in the long term I think it should be its own thing that would be opened from the space panel so that it's more user friendly

[not-a-dev-stein]

It can be done in a really similar way to Discord. The "explore rooms" button can stay where it is and the "explore spaces" button can be added below or on top of the already existent "create a space" button, to have clear separation between the two.

[PxBCPG]

We can create public spaces, but we can't get to them within the explore session (actually, you need the full room name to join it)
What is the advantages of public versus private spaces then ?

[t3chguy]

What is the advantages of public versus private spaces then ?

Someone can join without a Matrix invite (e.g by a matrix.to link)

[PxBCPG]

Well, here not really because he will need to know the existence of this room, and he won't be able to "discover" it

[t3chguy]

It can be discovered out-of-band, e.g via Twitter, Blog post, youtube video, whatever. That isn't possible for a private space.

[tgr]

Even if there will be a separate space finder dialog, the Explore rooms feature should do something useful when a space name is entered. Users might be unsure about the difference between rooms and spaces, or simply mistake a space name for a room name (there is no way to tell them apart). Just giving zero results can be confusing; a good UI should DWIM.
(At which point a combined dialog might be simpler than having a rooms dialog that can do something intelligent when you enter a space name plus a spaces dialog that can do something intelligent when you enter a room name.)

[clokep]

A fairly easy solution to this could be to add spaces to the current room directory. The work required on the backend to do this would be:

• Allow spaces to be added to the room directory (I don't see anything immediately blocking this, but I might be missing something!).
• Have the room directory return an extra field (the room_type, as the /hierarchy API does).
• Allow filtering on room types.

This would require an MSC, but it should be fairly straightforward extensions of the current APIs with good justification from other APIs (e.g. the /hierarchy API).

Estimate wise for work, I think the first two bullets would be pretty easy (1 week?) and the filtering is a bit harder (1 - 2 weeks: this is because we don't put the data in the right spots currently -- we don't store the room type directly in the database, so it is difficult to filter on, but this could/should be changed regardless).

[kittykat]

I'm going to remove the needs product label as the above approach sounds great 👍

[clokep]

This would require an MSC, but it should be fairly straightforward extensions of the current APIs with good justification from other APIs (e.g. the /hierarchy API).

@SimonBrandner wrote one! 🎉 See MSC3827