Skip to content
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

Adding new room aliases UI is extremely confusing #13077

Open
grinapo opened this issue Apr 8, 2020 · 12 comments
Open

Adding new room aliases UI is extremely confusing #13077

grinapo opened this issue Apr 8, 2020 · 12 comments
Assignees
Labels
A-Aliases A-Room-Settings O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Blocked X-Needs-Design Z-Chronic

Comments

@grinapo
Copy link

grinapo commented Apr 8, 2020

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):
2020-04-08_13-40-17_screenshot

Then I get a terribly misleading error:
2020-04-08_13-40-31_screenshot
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!
2020-04-08_13-41-10_screenshot

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
Copy link

SamGuay commented Apr 8, 2020

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
Copy link

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
Copy link

thegcat commented Apr 25, 2020

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
Copy link
Contributor

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
Copy link
Author

grinapo commented May 8, 2020

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
Copy link
Contributor

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.

@wioxjk

This comment has been minimized.

@hex-m
Copy link

hex-m commented Sep 25, 2020

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
Copy link

HansJK commented Feb 13, 2021

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.

@jryans jryans removed the Z-UI/UX label Mar 8, 2021
@SimonBrandner SimonBrandner added the Z-Papercuts Visible. Impactful. Predictable to action. label Apr 12, 2021
@nadonomy nadonomy added P2 and removed Z-Papercuts Visible. Impactful. Predictable to action. labels May 18, 2021
@felinira
Copy link

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
Copy link
Contributor

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
Copy link
Author

grinapo commented Feb 11, 2022

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).

@t3chguy t3chguy added O-Occasional Affects or can be seen by some users regularly or most users rarely and removed P2 labels May 17, 2022
@gaelledel gaelledel self-assigned this Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Aliases A-Room-Settings O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Blocked X-Needs-Design Z-Chronic
Projects
None yet
Development

No branches or pull requests