Last modified: 2014-11-17 10:35:49 UTC
As far as I can determine, the sectionEditLinks experiment was successful. If that's the case, we should tidy it up and deploy it. Current blockers: * It may need some updating to be fully compatible with HEAD. * It defers some work to the client that ought to be done on the server.
https://meta.wikimedia.org/wiki/Research:Section_edit_modification sounds equivocal; lots more clicks, but many didn't turn into edits. Anyway, as it's so hard to trigger the new look on testwiki (cookies and bucketing)and even then the edit link remains left-aligned, I have a patch that turns it on always, Gerrit change #32015. It still does the transformation in jQuery instead of changing core edit links and Vector CSS. See it on piramido.
Note that this was announced on Design-l. More community announcements upcoming. http://lists.wikimedia.org/pipermail/design/2012-November/000204.html
(In reply to comment #1) > Anyway, as it's so hard to trigger the new look on testwiki (cookies and > bucketing)and even then the edit link remains left-aligned, I have a patch > that > turns it on always, Gerrit change #32015. We don't need to re-enable that experiment. We've seen it many times of the last few years. Feel free to do the bucketing/cookie thing on a local wiki, labs or on test wiki. But not by default. This bug was filed against mediawiki core, with the design in mind to have 0 javascript involved. Experimental phase is over.
@Krinkle, yeah I think it's obvious that was the majority consensus on Design-l. No one's pushing through the JS-dependent version in a hurry at the moment. Should probably just abandon the related patchset in lieu of the aforementioned implementation in core?
(In reply to comment #4) > @Krinkle, yeah I think it's obvious that was the majority consensus on > Design-l. No one's pushing through the JS-dependent version in a hurry at the > moment. Should probably just abandon the related patchset in lieu of the > aforementioned implementation in core? Do you think changing the section links should apply to only the Vector skin or to all skins?
(In reply to comment #4) > @Krinkle, yeah I think it's obvious that was the majority consensus on > Design-l. No one's pushing through the JS-dependent version in a hurry at the > moment. Should probably just abandon the related patchset in lieu of the > aforementioned implementation in core? Yep, which is going to be an tough one to get right. It'll change a few dusty parts in mediawiki core. Lots of attention and care need to go in this one to make absolutely sure we cover the cases of stale caches and the different levels thereof in mediawiki and wmf-config specifically.
(In reply to comment #5) > Do you think changing the section links should apply to only the Vector skin > or > to all skins? The design is visually Vector-specific, so we don't have the data to apply it to other skins right away. The parser cache uses placeholders for TOC and editsectiolinks, which means their html structure doesn't fragment the cache. So we can (and have to) do this in the Skin-specific handling, not Parser or some other catch-all place. But sure, other skins can (and do) style edit sections whatever way they want to. Other skins can roll their own implementation of this if they want to (which isn't all that complicated, it should only be a few lines of code). This bug however is for Vector.
Do we actually want to use that look? It looks very out of place for me even on Vector, and more so on other skins. May I propose an alternative design? Such has feature been implemented and enabled by default on pl.wikipedia for years. I've never heard any complaints. Example page: https://pl.wikipedia.org/wiki/Zręczyce It keeps the links inside square brackets, but makes them slightly smaller and places them next to the heading itself, like the experimental implementation does. This will not be such a large design change as the experiment, while keeping the discoverability improvements.
I keep intending to work on this but other things get in the way, so I'll unassign it for now so as to not discourage anyone else from working on it.
Okay, so I'm going to work on this, then. Let's see if it works out.
(In reply to comment #10) > Okay, so I'm going to work on this, then. Let's see if it works out. Glad to see you're interested. :) FWIW, regardless of personal preference, the version with the icon and no brackets was what was A/B tested by Trevor and co. back in the day, and which proved to work better for users. I do think that an acceptable interim solution is to simply move the current appearance of the edit links, ala what's used in pl, fr, and other wikis. But light of the previous testing results, and the fact icons + text are generally more memorable by users in regardless of language, we should still consider that approach.
I submitted a draft at I6a6c12a9, noting the steps to make this work properly in the commit message. I'm hoping to get this done by the end of the weekend.
Out of curiosity, have there been any tests with either no icons or simply a more skin-friendly version? Having more applicable successful results on hand would probably help considerably for convincingly selling this change to other projects, as while those such as plwp have had no trouble from it, that doesn't exactly make a compelling reason for folks to accept the change (and not, as for instance enwp folks are sometimes wont to do, just override it in common.css).
(In reply to comment #13) > Out of curiosity, have there been any tests with either no icons or simply a > more skin-friendly version? I thought this is what Steven meant? (In reply to comment #11) > FWIW, regardless of personal preference, the version with the icon and no > brackets was what was A/B tested by Trevor and co. back in the day, and which > proved to work better for users. Or are you saying that the solution you're suggesting wasn't among the tested ones?
(In reply to comment #14) > (In reply to comment #13) > > Out of curiosity, have there been any tests with either no icons or simply a > > more skin-friendly version? > > I thought this is what Steven meant? > > (In reply to comment #11) > > FWIW, regardless of personal preference, the version with the icon and no > > brackets was what was A/B tested by Trevor and co. back in the day, and which > > proved to work better for users. > > Or are you saying that the solution you're suggesting wasn't among the tested > ones? I mean precisely this: * The version with icon etc. -- http://www.mediawiki.org/wiki/File:Screenshot-SectionEditLinks-Vector.png -- was what was tested. Sticking with the successful version from your A/B test is generally a good idea. * As an interim solution, it totally works for Vector (and probably other skins too) to keep the same appearance but move the position of the link, as Bartosz suggested. We probably won't see the same usability gains measured in the test, but it's a lot better than doing nothing.
This doesn't depend on bug 43940, since my solution won't involve JavaScript (or at least not the same one). The patch (I6a6c12a9) is ready for reviewing, by the way.
(In reply to comment #16) > The patch (I6a6c12a9) is ready for reviewing, by the way. Link, for convenience: I6a6c12a9
Created attachment 12184 [details] Screenshot on my local wiki of patch set 32, before purge I just wanted to post a screenshot of what I got pre-purge on patch set 32, to make sure it's a known issue (may be acceptable). It includes the appearance and the DOM. The HTML is kind of in an in-between state, with mw-section (new class name), but still before the headline. It corrects on purge.
Argh, this is probably a parser cache issue; I commented more extensively on the bug. The parser sucks, damn.
I believe all the complexity is an attempt to cache content while being able to sub in UI language-specific stuff (namely the word 'edit'). It can still be annoying, though. I've updated the Gerrit with a proposed CSS hack. To test: 1. Go to master 2. Purge a page. 3. Go back to this Gerrit. 4. Hard-refresh (e.g. Ctrl-Shift-R in Firefox), but don't purge. Look at the DOM in Firebug.
(This has been worked around in the changeset, FWIW.)
Okay, the relevant patch has been merged. Do we want to announce on relevant mailing lists and Village Pumps with a link to http://meta.wikimedia.org/wiki/Change_to_section_edit_links ? (I can help do this, but I'm deferring to Bartosz here, since it's his patch.)
https://gerrit.wikimedia.org/r/49364 (Gerrit Change I6a6c12a90de3604012420b20c1f520e0ece170ab) | change APPROVED and MERGED [by jenkins-bot]
(In reply to comment #22) > Okay, the relevant patch has been merged. > > Do we want to announce on relevant mailing lists and Village Pumps (...) > > (I can help do this, but I'm deferring to Bartosz here, since it's his > patch.) Please feel free to announce it wherever appropriate, I'm not sure what's the usual process. I suppose wikitech, -ambassadors and EdwardsBot? Anyway, thank you :).
Related URL: https://gerrit.wikimedia.org/r/61621 (Gerrit Change I73fed7551e6ded38a24eb936ad015fe1e57d036d)
Final cleanup in https://gerrit.wikimedia.org/r/#/c/84196/ .
