Last modified: 2013-07-29 23:24:02 UTC
To follow up on this: * We've got requirements and implementation ideas for the current state of the editing experience: https://www.mediawiki.org/wiki/Confirmation_message * A/B testing documentation, including results and data: https://meta.wikimedia.org/wiki/Research:Post-edit_feedback Consistent confirmation messages are a pretty obvious usability enhancement for an editor, especially one where the update to a page is not always visually obvious. When we A/B tested this against a control and variant of the text, a plain "your edit was saved" with the design described in the links led to a significant increase in the productivity of new editors. I've listed some requirements for incorporating this into MediaWiki as it exists, but haven't specified anything for VisualEditor. I would say that the essential elements for either system is that it included an icon, the text we tested, and that it is visible when editing any part of the page (i.e. it's not hidden if a section anchor is present).
Created attachment 11124 [details] Confirmation previously A/B tested
Can you expand on "previously A/B tested"? This design is nice, but completely out of place. 1. That is not a safe location to put a notification because it may obscure navigation controls. 2. The size is out of proportion with the rest of the UI 3. The colors and shading are out of sync with the rest of the UI I would like to see us make notifications work together with the skin, not just succeed at getting people's attention because they are sufficiently loud. Blending in can be detrimental to the function of a notification, but making it look out of place just causes other problems.
(In reply to comment #3) > Can you expand on "previously A/B tested"? I don't want to replicate the entirety of the documentation here on Bugzilla. See the Meta link above for all details, and especially the results subpage. The summary is that we tested this for all new registered editors on English Wikipedia for two weeks. The simple confirmation we're suggesting be implemented was the most successful when looking at a variety of metrics, from sheer volume of edits to quality indicators like revert rates. > This design is nice, but completely out of place. To be clear here: I'm _not_ suggesting this exact design be implemented in VisualEditor. I just provided the screengrab so you wouldn't have to guess what the previously tested version looked like. :) > 1. That is not a safe location to put a notification because it may obscure > navigation controls. > 2. The size is out of proportion with the rest of the UI > 3. The colors and shading are out of sync with the rest of the UI > > I would like to see us make notifications work together with the skin, not just > succeed at getting people's attention because they are sufficiently loud. > Blending in can be detrimental to the function of a notification, but making it > look out of place just causes other problems. I'm not sure if your critique is in the context of the current editor or only VisualEditor, but in addition to my comment above, I'd like to reiterate that this was an experiment, not a permanent implementation. The question we asked was: does it make a measurable difference to new editors to get a confirmation? The answer is a resounding yes. To respond on the first point: it didn't much matter that it obscures navigation, because in our implementation of the attached design, it only persists on screen for three seconds.
I agree 100% that we need a notification and I'm glad that there was some testing that went into it. VisualEditor currently uses the notification bubble stuff in MediaWiki for this, and I think it's an especially good example of a place where it's needed because the save occurs without very much else changing on the page (not even going to a different URL) Thank you for the clarification, I wanted to make sure we didn't have people changing the notification styles to match that until we had considered a few things first.
OK, after talking with Steven, [[mw:Extension:PostEdit]] is going to be moved in MW core at which point we can depend on it, and not re-implement the wheel. This means that users will get the same styling and text of messages whether they save via the wikitext editor or VisualEditor; yay.
*** Bug 43091 has been marked as a duplicate of this bug. ***
Looking at the code https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fmediawiki.action%2Fmediawiki.action.view.postEdit.js it appears this extension is not designed to work asynchronously. It expects a cookie to have been set, then fires immediately on page load. In VE, saving an edit does not cause you to reload the page, so we can't use the mechanism.
(In reply to comment #8) > In VE, saving an edit does not cause you to reload the page, so we > can't use the mechanism. It would only require a very modest refactoring to make the 'postEdit' hook triggerable by VE.
Related URL: https://gerrit.wikimedia.org/r/69855 (Gerrit Change I778b18bc051c51de355e122d8d4517b5a651ed4c)
Related URL: https://gerrit.wikimedia.org/r/69856 (Gerrit Change Id4a8bc22c09a552ef79670b0d4fc4a70df07ec33)
*** Bug 50642 has been marked as a duplicate of this bug. ***
Change 69855 merged by jenkins-bot: Allow postEdit hook to be triggered asynchronously https://gerrit.wikimedia.org/r/69855
Change 69856 merged by jenkins-bot: Use postEdit mw.hook for save notifications https://gerrit.wikimedia.org/r/69856
This has now (finally!) OK to merge, and has been.
