Display a summary of shared rooms in the invite dialog

[babolivier]

Because I don't know everyone's MXID by heart, each time I'm inviting someone to a room I worry that I'm going to invite some random people that happens to share a common display name with the user I want to invite, and sometimes have to switch back end forth between the dialog and another room just to look at the MXID of that user.

I think a nice way to improve this would be to display a summary of the rooms shared with each user that's suggested in the dialog. This could be done using MSC2666, which is already implemented in Synapse, and in the matrix-js-sdk.

[ShadowJonathan]

So basically an element-web continuation of matrix-org/matrix-react-sdk#4897 once it lands?

(@Half-Shot maybe worth adding to your meta issue?)

[Half-Shot]

Yeah, this is actually part of 4887 already.

I can't read, this is the inverse.

[babolivier]

Yeah, this is actually part of 4887 already.

I've talked about this IRL with @Half-Shot, looks like there was a misunderstanding; what's in element-hq/element-meta#1246 is for incoming invites, whereas I'm talking about outgoing ones.

[Half-Shot]

I think this could be solved in many ways and really prompts a design question here. You could use the shared room list API to fetch some rooms and display them under the member tiles in the invite dialogue, though it might not help you as it's quite a cramped space and so will only show you a few rooms (although you could expand it, although although that would mean increased number of clicks).

My counter proposal is that if your goal is "I know Dave from Backend Internal, I want to invite them to Backend Internal Retro Room" then you really want to filter for people in a space, or people in a room rather than just showing the firehose of daves with common rooms underneath. The technical advantage to this solution is you don't need to check for shared rooms for every user in that list using the API, because instead you just query the local cache of the members in a room.

So with my developer-level designer hat on, I feel like allowing users to filter the invite dialogue by a room/spaces membership feels more natural and actually what you are trying to do rather than a roundabout API call to fetch shared rooms.

[babolivier]

I agree, and I acknowledge it's a tricky issue from a design perspective.

My counter proposal is that if your goal is "I know Dave from Backend Internal, I want to invite them to Backend Internal Retro Room" then you really want to filter for people in a space, or people in a room rather than just showing the firehose of daves with common rooms underneath. The technical advantage to this solution is you don't need to check for shared rooms for every user in that list using the API, because instead you just query the local cache of the members in a room.

My concern with that is that it feels quite counter intuitive to me UX-wise: my first thought would be "I need to invite Dave", not knowing the UI will show me a bunch of Daves, so I'll just type "Dave", and I'll want to select the right Dave from there; I won't know in advance that I'll need to select the room/space to filter by and then search for the user.

Though maybe we could find a common ground between both solutions by displaying something like "Don't find the user you're looking for? Filter by room/space" on the search result page.

[Half-Shot]

I think my contention is that the shared room list is only so useful if you have a small number of rooms, it quickly becomes less useful if you have many of them and none of the "useful" ones show up. I think it probably makes sense for Product to weight in here on what they think the future of invites is.