Adding new room aliases UI is extremely confusing

[grinapo]

Description

Adding published room aliases UI is confusing to put it nicely.
So what happens when I try to add a new public alias?

I enter the alias (Published Addresses » Other published addresses):

Then I get a terribly misleading error:

There was an error updating the room's alternative addresses. It may not be allowed by the server or a temporary failure occurred.

And then I see that my new alias is added!

Well, except it isn't.

The UI right now accepts a completely different workflow, namely:

• add a local alias to the room (Local Addresses » Room alias)
• ...after you clicked "Show more"...
• then type the whole, same alias again (no selection list)
• then it's added without problems, and added really.

Suggested behaviour

Other published addresses shall be a selection list, similar to Main address, which would pick one from the locally added addresses. A helpful message above the box would also inform me that I need to add a local address first.

Version information

• Platform: web (in-browser)
• Browser: Chrome, Firefox; any version
• URL: private, v. 1.5.15

[SamGuay]

I have nothing to add, but I just want to highlight that @grinapo's issue describes perfectly the confusion I faced yesterday on my server. Finally ended up working when @dannycolin told me to click on show more for local addresses 😅

A helpful message above the box would also inform me that I need to add a local address first.

I agree, a clear indication/warning (as simple as ⚠️) that direct people to dealing with local address first would help newbies like me :)

[henry-nicolas]

I faced exactly the same issue just yesterday. Even just swapping local and published aliases would already be helpful IMHO.

Users will just read top to bottom and stop when the form looks like it does what they want. In that sense, hidding by default (show more link) local aliases that are a pre-req for published ones, that does not help.

[thegcat]

Just to chime in that we were bit by this today too, "we" as in I had another knowledgeable user try it to confirm I wasn't derp-ing anything.

[foldleft]

I've had a vague poke at this to see what I can do before it's had a proper design review. Thoughts:

I think we should:

• Inline progress feedback when adding aliases
• Indicate what the attempted change was in the error message
• Validate published aliases so the user doesn't try to add an alias that isn't a room alias (I accidentally used @ instead of #, for example)
• Pre-empt likely failures by incorporating information about the user's permission levels and the permissions necessary to set aliases
• If (as I suspect) the change is to the entire alias list, handle failures by attempting to set it to its current value and providing feedback along the lines of "can't change / current list invalid" vs "new entry invalid"

[grinapo]

Right now the UI is in counter-intuitive order: first there is the "pick main alias" and later the "add local aliases", while the former requires the latter first.

Also "local aliases" is folded, while main alias isn't. The intent seems to be clear: to show main alias. It is not good for changing the alias, though.

While it would cause a bit duplicate maybe it'd be more logical to

1. show the current main alias (as a static text)
2. have a folded "change aliases"
3. which would contain, unfolded, an "add local aliases" (while also showing them) and a "select main alias from local aliases" choice.

[foldleft]

Thanks for the feedback! This feature will be getting some design review love eventually; for now I'm making some design-preserving changes that give the user better feedback that should help to get them unstuck.

[hex-m]

Having the same problem and I also couldn't find clear documentation about the semantics of different types of Room Addresses (local, published, main). The spec calls it "Room Alias" but doesn't have any details. The rooms document mentions neither aliases nor addresses. The FAQ calls it alias an mentions it once without explaining it.

Of course having a self-explanatory UI would be preferable.

[HansJK]

I have been using Matrix for a couple of years now, but this still confused me... I don't want to think about how confused non technical people get over this. They will give up pretty quickly.

[felinira]

I thought my server that I am administering for 2 years now was broken because of this. Half an hour later into some debugging session I found out I was using the wrong input box.

[babolivier]

I got confused by that multiple time to the point where I end up adding the alias manually with curl because it just looks like the feature's just not working. The fact that the text input for the "Local Addresses" section is hidden by default makes it even more confusing because my brain then doesn't parse it as a section that can help me with that.

[grinapo]

I have to correct myself a bit, since a plain pulldown would not work well: it could offe my aliases but the UI have to handle adding foreign aliases too, somehow, and since these aren't federated they have to be typed manually. I still believe the majority of the cases is when the alias creator and the alias adder (and even the main alias settr) is the same person, and the pulldown version would be valid and friendly.

If I understand correctly, we have various steps:

• someone adds a local, non-federated alias to a room
• room admin picks any alias to be federated
• room admin picks any federated alias to be main.
  There is a very high probability that in the majority of the cases the first two is in the same workflow, and all the three is very often.
  The UI probably should follow this order [since they have to happen in that order], and handle rare(r) cases (admin adds a foreign alias added by someone else) in an alternate workflow (eg. "show advanced options" hidden fields).