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.