Last modified: 2014-02-20 02:07:27 UTC
Currently the entire thing is a javascript file. For an experiment that's perfectly fine, but this has since been deployed in full on the English Wikipedia and thus that is no longer a viable implementation. From a user standpoint, anyone without js will miss out on it entirely when much of the visual stuff would still benefit the new folks even without the added responsiveness. From a developer standpoint, having the thing implemented in js makes it harder to work with in general as it does not follow interface standards. From an i18n standpoint, there is no i18n nor any system messages in general. From a wiki admin standpoint, without system messages, the only way to customise things is javascript, but it can be very difficult if not impossible to write on-wiki js that will work with/override system js, which this is.
Agreed about the general point you're making. However, we will be permanently implementing these interface changes in core, not in an extension. It's hard to get more suitable for MediaWiki core than account creation. If you want to learn more about these architectural plans before filing bugs, ask in our IRC channel which you're in all the time, check out our Trello board,[1] or Quarterly Planning document.[2] 1. https://trello.com/b/FdtPTV2y 2. https://www.mediawiki.org/wiki/Editor_engagement_experiments/Quarterly_Planning
If the thing is going in core, then it should not be present in this form as a 'permanent feature' at all. Clarity on these matters where people will actually be looking might help, but in the meantime this is problematic regardless of what documentation there may be.
To clarify, these things should be implemented BEFORE being deployed in full, not after. This sort of approach just makes things more difficult for everyone.
(In reply to comment #3) > To clarify, these things should be implemented BEFORE being deployed in full, > not after. This sort of approach just makes things more difficult for > everyone. That's not really your call to make. S and I agreed that turning on the new UI, which was proven through testing to be superior, temporarily while we build a more permanent version, was better for users than reverting to the ugly, inhumane previous state of English Wikipedia account creation. This was not a full deployment, but rather simply not removing a better experience while we make something more lasting. I stand by that decision.
Does the English Wikipedia agree with this view?
(In reply to comment #5) > Does the English Wikipedia agree with this view? English Wikipedia is currently having a nice, cold blueberry smoothie. She sends you all her regards. We're all in agreement. This needs to be re-implemented to merit a permanent roll-out. Give it a rest, already.
[double mid-air collision] Isarra, I think what Steven means is that your request is valid, but as a request for account creation internal interface/API in core to be more flexible (or exist at all), making it easier to plug extensions on it. This is a well known deficiency of MediaWiki, as far as I can understand, see for instance [[mw:Translation_UX/Development_plan#Milestone_SG4:_signup_dialog]]. You may want to create a new bug (or even MW RfC) for this, if one doesn't exist; this would be a duplicate of it. Bug 17312 sort of asks this, I think; I couldn't find another. This bug can be marked WORKSFORME, INVALID or WONTFIX, but it seems quite sure that this job won't be done as part of this project, so in this component it's probably pointless. You may want to mark it as duplicate of bug 17312 or equivalent, or to move it to core.
Thank you, Nemo. That actually helps explain a lot. That said, why is this not part of the project? If the experiments are bringing up valid issues and useful fixes, is there no pipeline to implement them? I'm not sure what to close this as because LATER is no longer an option and nothing else seems appropriate given the situation - it is a 'bug' that has yet to be resolved; this just isn't the place for it.
(In reply to comment #7) > Isarra, I think what Steven means is that your request is valid [...] This request looks valid to me as well. Is there a bug about the general need to re-implement (from JavaScript to PHP) the improved account creation form? If there is no such bug (bug 17312 doesn't appear to be it), isn't this bug valid and unresolved? I'm confused.
Okay, yeah, this probably is a valid bug, just not under the right component or whatever, if e3 really is just experiments... but I really don't know where it would be appropriate to put this, so could someone who does please fix it?
The "E3 Experiments" component is fine for now. Re-opening.
(In reply to comment #9) > (In reply to comment #7) > > Isarra, I think what Steven means is that your request is valid [...] > > This request looks valid to me as well. Is there a bug about the general need > to re-implement (from JavaScript to PHP) the improved account creation form? > If > there is no such bug (bug 17312 doesn't appear to be it), isn't this bug > valid > and unresolved? I'm confused. Part of the reason there is no such bug is because I don't really use Bugzilla to track what the team is actually working on. There are all kinds of outdated and irrelevant bugs floating around components we maintain at any given point in time. I also just find it a little silly to file "bugs" about major product changes like rewriting the core account creation interface. We generally keep our projects tracked on the Trello board I linked above.
"Isarra, I think what Steven means is that your request is valid, but as a request for account creation internal interface/API in core to be more flexible (or exist at all), making it easier to plug extensions on it." No, based on talking to Steven before (and what he said as the first comment), I think he is in agreement that we would to move essentially all of ACUX to core. There are certainly improvements that can be a made to the core account creation hook points. But that's not going to be the focus when moving ACUX to core (a significant enough task on its own). I'm going to change the title to specify core. As Steven says, we use Trello for some things. However, it's fine to leave this open as a tracking bug.
(In reply to comment #12) > There are all kinds of outdated and irrelevant bugs floating around > components we maintain at any given point in time. If you'd like to have some cleanup for your components your welcome to propose it for "Old bugs" as part of https://www.mediawiki.org/wiki/QA/Weekly_goals
Is this bug a duplicate of bug 43690?
Yeah, but this one (though later) is better developed, so I'll mark the other one.
*** Bug 43690 has been marked as a duplicate of this bug. ***
I've removed bug 15700 as a blocker because we're not making separate special pages a hard requirement for our first release. I removed 26751 as a dependency as well, because it was really broad, and we don't plan on moving any functionality except the frontend modifications currently being done in E3Experiments (of course). If anyone feels like there are missing requirements, please comment on https://www.mediawiki.org/wiki/Account_creation_user_experience to ask that they be added.
(In reply to comment #18) > I've removed bug 15700 as a blocker because we're not making separate special > pages a hard requirement for our first release. Indeed that's not a requirement: the intended blocker was bug 17312, which basically requests code cleanup making enhancements like this possible. (The amount of such cleanup actually needed to fix this bug will be seen later when someone starts working on it, of course.)
This is actually in progress at https://gerrit.wikimedia.org/r/#/c/30637/. S Page and Munaf Assaf are the primary devs, so I'm assigning S.
This is merged, but not yet in any branches. It missed the cut for 1.21wmf12, so it will be in 1.21wmf13, cut on April 1. We should coordinate removing the productized code from ACUX, perhaps leaving just EventLogging for the new form.
(In reply to comment #21) > This is merged, but not yet in any branches. It missed the cut for > 1.21wmf12, > so it will be in 1.21wmf13, cut on April 1. > > We should coordinate removing the productized code from ACUX, perhaps leaving > just EventLogging for the new form. I think probably the easiest thing to do is have us use our normal deploy window before April 1 (so Thursday the 28th) to remove the productized code from ACUX. The testing of the new version will work much better without it, so doing so prior to 1.21wmf13 is a good idea.
Reverted by https://gerrit.wikimedia.org/r/#/c/54713/
I'm lost. Why was this being implemented with a URL query string and such? I thought the whole idea here was to fix up/improve MediaWiki's core account creation logic, not duplicate it. I haven't been following most of this closely, but I skimmed <https://gerrit.wikimedia.org/r/30637> and it seems like the entire approach here was wrong. If it's experimental, leave it in an extension. If it's going into core, put it into core. The query string/configurability really doesn't make any sense to me. If you're going to go in that route, why wouldn't Agora be a skin? And... I thought includes/templates/ was completely deprecated. I thought the only part of the UI that used it was Special:UserLogin and Special:UserLogin?type=signup and they only did so for historical reasons. I could swear there was a bug about killing off these remaining templates (and just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand, but adding templates like this seems like the wrong approach overall. Make Agora a MediaWiki skin and/or improve the core account creation interface. If you want to put something behind configuration, just leave it in a MediaWiki extension. Sorry this wasn't flagged earlier.
(In reply to comment #24) > And... I thought includes/templates/ was completely deprecated. I thought the > only part of the UI that used it was Special:UserLogin and > Special:UserLogin?type=signup and they only did so for historical reasons. I > could swear there was a bug about killing off these remaining templates (and > just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand, > but adding templates like this seems like the wrong approach overall. This would be bug 10317.
(In reply to comment #24) > I'm lost. > > Why was this being implemented with a URL query string and such? We definitely intend to make it a normal part of core (no query string, it's just there). However, the query string is meant as a temporary measure. Besides allowing people to test (this is necessary since the extension version has only ever run on enwiki in production), it lets people do any necessary cleanup to MW messages. I agree this approach is unusual for MW core. However, it's more common elsewhere (it's a form of gating). Again, it is not intended to last unduly long. The core commit (now reverted, but after addressing concerns will be committed again) suggesting removing the old version completely from core by 1.22. I don't think that milestone is set in stone. > And... I thought includes/templates/ was completely deprecated. I thought the > only part of the UI that used it was Special:UserLogin and > Special:UserLogin?type=signup and they only did so for historical reasons. I > could swear there was a bug about killing off these remaining templates (and > just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand, > but adding templates like this seems like the wrong approach overall. There was some discussion of using a different approach (possibly HTMLForm), but IIRC, it was decided to be out of scope for the initial commit. That doesn't mean it can't be done later. > Make Agora a MediaWiki skin and/or improve the core account creation > interface. The idea is that Agora will be mediawiki.ui, a separate module. However, this module does have skin-specific behavior. So (again in the core commit that was reverted), there is one CSS file for non-Vector (default) and another for Vector. More could easily be added for other skins.
(In reply to comment #26) > There was some discussion of using a different approach (possibly HTMLForm), > but IIRC, it was decided to be out of scope for the initial commit. That > doesn't mean it can't be done later. Right. But rather than staying away from the mess or cleaning it up, you seem to be _adding_ to it with additional templates. Broadly, as I understand it, the idea here was that we were going to clean up the account creation UI and internals in MediaWiki core. Looking at <https://gerrit.wikimedia.org/r/30637>, I think I'd much rather see time and energy focused on <https://gerrit.wikimedia.org/r/27022>.
(In reply to comment #27) > (In reply to comment #26) > > There was some discussion of using a different approach (possibly HTMLForm), > > but IIRC, it was decided to be out of scope for the initial commit. That > > doesn't mean it can't be done later. > > Right. But rather than staying away from the mess or cleaning it up, you seem > to be _adding_ to it with additional templates. Broadly, as I understand it, > the idea here was that we were going to clean up the account creation UI and > internals in MediaWiki core. > > Looking at <https://gerrit.wikimedia.org/r/30637>, I think I'd much rather > see > time and energy focused on <https://gerrit.wikimedia.org/r/27022>. The idea here is not to focus on cleaning MediaWiki internals. I don't think we should permanently add a big mess, but the idea here is to implement interface improvements for the end user, based on our previous testing. I can fully understand how the temporary URL parameter implementation feels very awkward, but considering this gives us the ability to gather feedback about design, functionality, internalization, etc. from end users on the wikis while not breaking their current interface, the benefits outweigh having to do a bit of clean up when we want to turn https://gerrit.wikimedia.org/r/30637 on by default.
Just a quick update: there is a new patch in Gerrit (https://gerrit.wikimedia.org/r/55847) which separates out the login changes for review from the account creation changes, which had more issues anyway. However, there's no rush to review that, since we're exploring building on top of Tyler's patch to convert to HTMLForm (https://gerrit.wikimedia.org/r/27022). Notes are at https://www.mediawiki.org/wiki/Agora/Engineering#Changing_HTMLForm
(In reply to comment #29) > Just a quick update: there is a new patch in Gerrit > (https://gerrit.wikimedia.org/r/55847) which separates out the login changes > for review from the account creation changes, which had more issues anyway. https://gerrit.wikimedia.org/r/55847 is merged; https://gerrit.wikimedia.org/r/45878 is next.
(In reply to comment #30) > https://gerrit.wikimedia.org/r/45878 is next. That should have been https://gerrit.wikimedia.org/r/#/c/57823/ instead. (Thanks, Krenair, for pointing it out to me.)
https://gerrit.wikimedia.org/r/#/c/57823/ is merged and will soon be ready for testing in production, as soon as we backport it to the current MediaWiki release.
Related URL: https://gerrit.wikimedia.org/r/60765 (Gerrit Change I9b03d519af43de147bff0ac509a1154f67cd3a0a)
