Page MenuHomePhabricator

[New UserLogin] "(help me choose)" should appear only after a failed registration attempt
Closed, ResolvedPublic

Description

The new ACUX shows this link "(help me choose)" prominently on top of the first textfield. This is a wikipedism that has several problems:

  • Even if you do have a policy (like English Wikipedia has) this is probably not a page you want all new user to look, scared that they might be doing something wrong. http://en.wikipedia.org/wiki/Wikipedia:Username_policy is so dense and boring that it might drive potential new users away.

I'm not sure how to force a wrong username and I don't want to create fake accounts trying to test this, but I bet when you try to create a "blacklisted" user name you get an error message. Place the "(help me choose)" link in the error message instead, since that is the place where legitimate users will need it.

In the meantime most people just trying to register with their NameSurnameXYZ and other innocent variants will just go through, unaware (for good!) of the dense boring policy they just followed unconsciously.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47801

Details

Reference
bz47704

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:41 AM
bzimport set Reference to bz47704.
bzimport added a subscriber: Unknown Object (MLST).

swalling wrote:

All Wikimedia projects should have a help document or policy describing what is and is not an acceptable username. Either that, or redirect to a central one. Only providing the help link after the user fails is poor practice.

All Wikimedia projects should have a help document or policy describing what
is and is not an acceptable username.

Maybe, although this is not the reality today. But in any case: this a feature in MediaWiki core, not an extension used only by Wikimedia projects. I don't think we can enforce Wikimedia policies through the UI of a plain MediaWiki feature.

Also why poor practice? What is the % of users that hit a wrong username vs the ones just going through? Have you seen any popular web service referring to a username policy the moment you create an account? I have registered to plenty of online services and never saw such notice.

In the current registration page that link is one of many and I'm sure most users don't even see it. But in the new UX (which I love) it suddenly becomes the most visible link. And let me repeat, the long destination page only helps to those having the patience to read 40% of it through. I wouldn't be surprised if in practice people try whatever username had in mind already without reading any policy in advance.

Please consider reopening, even if it doesn't fit in your priorities today.

(In reply to comment #1)

All Wikimedia projects should have a help document or policy describing what
is and is not an acceptable username.

This bug is in the "MediaWiki" product, not the "Wikimedia" product. Re-opening.

swalling wrote:

(In reply to comment #2)

Also why poor practice? What is the % of users that hit a wrong username vs
the
ones just going through? Have you seen any popular web service referring to a
username policy the moment you create an account? I have registered to plenty
of online services and never saw such notice.

Wikimedia sites are different in this regard. We have local policies about group accounts, accounts that seem to represent a company, accounts with offensive names, etc. that will get users blocked if they violate them. A link is the least intrusive way to provide this information up front to users, and many of the local rules won't generate an error message at all.

In the current registration page that link is one of many and I'm sure most
users don't even see it. But in the new UX (which I love) it suddenly becomes
the most visible link.

The link is far less prominent than what some wikis are doing in their old versions of the forms: walls of text explaining the rules.

Users do click through and read this link, even when it was embedded in a mountain of text, and still successfully create accounts. (On English Wikipedia, for example, it's the number three referrer to sign up page.) Adding the link up front is not doing harm, and in fact may be doing some good.

Anyway, MZ can play tug of war with the bug status, but I'm not going to recommend to E3 that we implement this.

(In reply to comment #4)

Wikimedia sites are different in this regard. We have local policies about
group accounts, accounts that seem to represent a company, accounts with
offensive names, etc. that will get users blocked if they violate them. A
link
is the least intrusive way to provide this information up front to users, and
many of the local rules won't generate an error message at all.

Precisely - it's the Wikimedia sites that are different, and this shouldn't be enforced globally. There's nothing preventing you from inserting an empty message there and letting wiki's admins customize it.

I noticed this when trying out the new UI at pl.wikipedia, and I agree with Quim and MZMcBride – this link should not be there by default.

(In reply to comment #1)

Either that, or redirect to a central one.

Ridiculous, we don't even have crosswiki redirects; stop climbing mirrors, Steven.

If you believe a central help page is needed,

  1. create it on mediawiki.org and make it translatable,
  2. link it from the interface.

If you believe a policy is needed, please get consensus for this claim. I've opened a new section for you at https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5442481#Username_policies

swalling wrote:

(In reply to comment #6)

(In reply to comment #1)

Either that, or redirect to a central one.

Ridiculous, we don't even have crosswiki redirects; stop climbing mirrors,
Steven.

If you believe a central help page is needed,

  1. create it on mediawiki.org and make it translatable,
  2. link it from the interface.

If you believe a policy is needed, please get consensus for this claim. I've
opened a new section for you at
https://meta.wikimedia.org/w/index.
php?title=Wikimedia_Forum&oldid=5442481#Username_policies

Nemo, I'm sorry but that thread is too much. What point are you trying to make, other than that you can selectively quote me on Meta, but not by name, and get some people to snark about it? You trying to drum up anger by putting words in my mouth about forcing policy on communities, when that is _not_ what I said or meant, is ridiculous.

I don't think having to customize a link and/or its text is such a bad thing, we do it all the time on Wikimedia projects. Other than that, this thread has devolved pretty rapidly in to trolling. I have about 20-something other bugs or enhancements to deal with, so I'm moving on.

(In reply to comment #7)

I don't think having to customize a link and/or its text is such a bad thing,
we do it all the time on Wikimedia projects.

Precisely. Which is why *we* should keep doing that, instead of forcing it on all MediaWiki projects everywhere.

Other than that, this thread has
devolved pretty rapidly in to trolling. I have about 20-something other bugs
or
enhancements to deal with, so I'm moving on.

Please don't throw tantrums when you're disagreeing with someone. This is just irresponsible.

Related URL: https://gerrit.wikimedia.org/r/61395 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df)

I submitted Ie0888cd0 to blank this message by default.

Bartosz, thanks for your patch. It and the discussion of what urls should appear in the new forms by default belongs in bug 47801.

This bug remains an interesting idea that we probably won't implement. Wikis could implement it by blanking the message in the createaccount form and adding a '_help with usernames_' link to messages like 'noname'; it's a useful approach for some wikis and we should suggest this somewhere, maybe https://www.mediawiki.org/wiki/Manual:Page_customizations ?

Note bug 47530 "Open username policy in tooltip" should help with the problem identified by this bug by making the advice more lightweight.

Let's discuss the username policy link here, since it's more specific, and this bug was filed first.

There are a lot of wikis both inside and outside the WMF that have a username policy. There are two questions:

  • What should the MW defaults should be?
  • What should the WMF defaults be?

Based on this, there are various options

  1. If we think most MW wikis want a username policy linked from this page, then the original approach seems correct, and wikis that don't want it can override it locally.

There are certainly a good number of third-party MW wikis that have this (search [wiki username policy]), and more might set it up if it were suggested as a redlink.

  1. If most MW wikis don't have or want it, but WMF wikis do, then one option is to put it in WikimediaMessages (https://www.mediawiki.org/wiki/Extension:WikimediaMessages), which is exactly what it sounds like, WMF-wide message defaults.

It certainly seems like a lot of WMF wikis have such policies, judging by both https://www.wikidata.org/wiki/Q4664077 and the Google search mentioned above. It's not just Wikipedias. See http://en.wikiquote.org/wiki/Wikiquote:Username_policy, http://commons.wikimedia.org/wiki/Commons:Username_policy, http://en.wikinews.org/wiki/Wikinews:Username , etc.

  1. We could have a boolean that determines whether to show the message, with an appropriate MW and WMF default, and configuration on various wikis.
  1. We could do it manually only on the wikis that want it, but I'm not convinced that's the most efficient, given how many do have it.

I think 1 or 2 are the best options, but 3 is a possibility.

Regarding the original point (only showing it after an error), it is true that "when you try to create a "blacklisted" user name you get an error message"

But there are a lot of usernames that are not appropriate, but not blacklisted. And some wikis don't have automated blacklists enabled.

The Commons is proposed, but the other two non-Wikpedia ones mentioned are official.

swalling wrote:

See my comment on bug 47801 about our solution for this.

*** This bug has been marked as a duplicate of bug 47801 ***