Design/Archive/Wikimedia Foundation Design/Login/Engineering

Notes towards implementing the new design.

https://gerrit.wikimedia.org/r/#/c/30637/ replaces form HTML with static. But we need to preserve the current complex PHP logic if we're going to integrate.

CSS styling

#userlogin, #userloginForm

these both float: left and draw a border similar to what's on other special forms. The float: left makes the fancy green "Create account" button appear to the side unless it's moved into the form. I think you may have to !important disable these.

I had to move the cta "create account" div inside the userloginForm div to avoid problems.

td.mwlabel

styles the table cell. Unneeded and unused in new design,

td.mw-submit

styles the cell for the Login button, making it white-space: nowrap; and text-align: left; I don't think we need these in the new design.

HTML stuff

old "Don't have an account" was at the top in

<?php $this->html('link') ?>

but this is not styled.

new design has a special <div id="createaccount-cta"> that is heavily styled containing new messages and a button:

  <h3><?php $this->msg( 'donthaveaccount' ) ?><button class="mw-btn green"><?php $this->msg( 'joinwikipedia' ) ?></button></h3>

TODO: do we need both?

relevant messages

loginstart

empty message in the messages table and on enwiki

loginlanguagelinks

templates/Userlogin.php can optionally (if haveData( 'languages' ) ) show a languagelinks div, containing loginlanguagelinks text and a bunch of languages. testwiki has this, I don't see it on enwiki.

Will Universal Language Selector affect this?

loginprompt

'You must have cookies enabled to log in to {{SITENAME}}.'

Enwiki replaces it with a comment in order to blank out the message; Wiktionary has a complex prompt inviting user to Special:MergeAccount from other wikis

nologin

'Don't have an account? $1.'

If the user can create an account, this is shown. The existing form replaces $1 with the HTML for a hyperlink.

nologinlink

"Create an account"

The code in SpecialUserlogin.php uses this as the text in its hyperlink. TODO: in the new design, this has to be transformed into a button.

joinwikipedia

"Join Wikipedia"

this is the current contents of the button. But the current includes/specials/SpecialUserlogin.php code doesn't work this way, see nologinlink

loginend

has lots of text on enwiki, see en:MediaWiki:Loginend.

StevenW says axe this, its text will be gone forever "All those per-wiki messages will be lost in time, like tears in rain. Time to die."

Code and logic issues

'Create account' button trouble

specials/SpecialUserlogin.php conditionally puts the nologinlink 'Create an account' text into a hyperlink to that form, and then inserts this HTML into the nologin string 'Don't have an account? $1.'

I changed to outputting Munaf's new strings 'donthaveanccount' and 'joinwikipedia' in separate text and button.

Another problem You're not allowed to have a freestanding button that's a link. e.g. button inside hyperlink. I tried putting the button inside a form that links to create account, that didn't work either.

domain select, extra fields

Before "remember my password", the old form might output a usedomain select list, extrafields and cansecurelogin. WMF Labs' console login shows the usedomain as "Your domain" select, and has an extra "Token" field. TODO check to see how these are styled

cansecurelogin is another optional checkbox. If $wgSecureLogin (which doesn't seem to be set anywhere) is true, it displays a 'Stay connected to HTTPS after login' checkbox.

I kept the ordering and try to output these correctly, but if a wiki triggered these fields, I don't know if the "remember my password"'s special class="pull-up" would get messed up.

What about skins?

Hmmm.

Can't combine two things in label

The new design combines "Remember my password" and a right-aligned "Forgot username or password?" in one label.

This doesn't work because "Remember my password" and "Forgot username" may be separately or together disabled on the wiki. Also

• "Forgot username or password" can't be in a label that's "for" a checkbox that isn't shown.
• I think Siebrand said that in some languages the two text strings would not fit.
• in the jsFiddle the two pieces of text don't properly align horizontally

The two items have to be a separate label and another div or whatever that can stand alone. stackoverflow suggestions

Internationalization

Colon issues

The Userlogin and Usercreate forms have label messages 'yourname', 'yourpassword' etc with values 'Username:', 'Password:', i.e. they include the colon on the end. In the new agora design these labels are on top of the fields rather than to the left, so the colon is unnecessary. The Account Creation UX experiment ran JavaScript that replaced these labels with colon-free text. Looking at the MessagesXx.php files most languages include the colon, many omit it, and I can't tell if some languages use a different glyph.

It would make more sense to omit the colon and have a function wfMessage( 'username' )->colonify(), but there isn't such a field in mw:Localisation. Rather than add duplicates of all these messages — username-nopunct, yourpassword-nopunct, etc. — S proposed to leave the fields with colons, but then once a language has fully converted all uses to the new Agora form, go and clean up the messages.

TODO get i18n review of this.

Auth issues

SpecialUserlogin.php calls

       // Give authentication and captcha plugins a chance to modify the form
       $wgAuth->modifyUITemplate( $template, $this->mType );

so authorization could do anything.

TODO: Use HTML form class

(from Agora/Engineering meeting)

Problem is Userlogin and Usercreate don't use HTMLForm, they're just QuickTemplate.

Usercreate issues

We are likewise integrating the ACUX layout enhancements. These have similar but different issues.

CAPTCHA woes

The CAPTCHA just adds information to the 'header' field of the template object. There's no easy way for the form to tell what extensions have added which info here. ConfirmEdit has a comment

@fixme if multiple thingies insert a header, could break.

so it seems the ability of extensions to modify the template in UserCreateForm and UserLoginForm hooks is not robust.

Also, there is no easy way to override the absurdly long fancycaptcha-xxx message that enwiki has borrowed to add gobs of text to the form.

Differences in CSS

The mediawiki.special.userlogin.css has to incorporate a replacement for the acux.css that the experiment loads. Compared with Userlogin, ACUX's form is bigger and uses bold labels, and uses width=300px where Userlogin uses width=100%.

• Userlogin uses label class='pos-above', ACUX uses label class='acux-label'
• Userlogin styles everything off being in a mw-form-list, ACUX uses styles acux and acux-inputs

Naming

• Should the new Userlogin/Usercreate form layouts use mw-form-stacked, etc. naming similar to Trevor's Agora mw-ui-button class?
• Or should the Userlogin/Usercreate form layouts just apply .agora style to existing form?

Munaf leans towards the latter.