Page MenuHomePhabricator

Investigate ways to encourage use of the Preview button in the wikitext editors
Open, LowPublic

Description

It's easy to make a typo or to get an unbalanced number of brackets or tags. It may be helpful to encourage editors to preview their work before finishing.

On the other hand, depending upon how previewing is encouraged, then editors may have trouble figuring out how to publish their changes (so perhaps fewer completed content edits), and it may slow down or annoy editors when they don't want to be bothered with previewing (e.g., a quick reply on a talk page).

Event Timeline

Restricted Application added a project: VisualEditor. · View Herald TranscriptJul 10 2017, 5:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

As I've already said at the tech forum of ruwiki, my personal average use of the "Preview" button is much more than that of the "Publish", maybe 10 or 20 times for large edits, and even the smallest edit won't go without one. The same stands for "Show changes". And I do encourage everyone not to hurry too much, given that the published edit will always remain at least in the revision history. So, to get started with, my suggestion is to avoid putting extra emphasis on "Publish" button in the new OOjs UI and keep color the same for all three buttons like it used to be.

my personal average use of the "Preview" button is much more than that of the "Publish", maybe 10 or 20 times for large edits, and even the smallest edit won't go without one. The same stands for "Show changes".

The difficulty is that small numbers of people reporting their personal experiences is a very unreliable indicator of how the majority of the population behaves, particularly when the small sample represents a subset of the population with homogenous characteristics relative to the overall population. Assuming that such samples are indicative of larger behaviour, and using them as a basis of decision making, is a repeated failing of the Wikimedia Foundation and the movement in general. The purpose of this task is to avoid that trap, and to perform proper research to figure out what's best rather than guessing.

The purpose of this task is to avoid that trap, and to perform proper research to figure out what's best rather than guessing.

But it's still useful to have some idea of what some individuals do, because that helps us design relevant research questions.

So there is Mike, somewhere towards one end of a spectrum, who uses preview and show changes very frequently. I'm probably somewhere towards the other end, since I don't usually use Preview, but I will use it if I'm uncertain about whether I've remembered the name of a page (usually a page on another wiki) correctly. I use Show Changes primarily if I'm trying to reproduce a bug in VisualEditor.

There are probably people who use these tools less than I do (including never). Then there is the Chinese Wikipedia, with its unusual dual-script system. (Mike, it's similar to writing Russian articles in a mix of standard Cyrillic and a Latin transliteration, except that very few people in the world can read both of the scripts. The software auto-converts the whole page to whichever script the reader can read – compare https://zh.wikipedia.org/wiki/睡莲属?uselang=zh-hans with https://zh.wikipedia.org/wiki/睡莲属?uselang=zh-hant – but editors can add sentences in either, and they see the resulting mishmash when they edit.) That wiki, perhaps in an effort to discourage people from mistakenly blanking content in the 'wrong' script, has installed a local script that forces editors to preview the page before the "Publish" button can be used. It may be helpful in their specific circumstances, but it's very likely to discourage new editors from editing, and to annoy experienced editors who are certain that their edit is correct.

Also, previous user research has found that some new editors save their changes *before* clicking the Preview button. They say that they don't want to risk losing their work if the Preview button broke somehow. I suspect that they are thinking of something analagous to printing a document: first, you write your paper for school, then you save it, and then you print it. (This is one of the reasons that "Save" now says "Publish" on most wikis.)

All of this suggests several things that could be tested:

  • Do new editors understand what the Preview button does? Would they use it more if there was an explanation next to it?
  • How often do people use this button? Does this change over time/with experience?
  • What circumstances prompt people to preview? When do they find the most value in it?

Do new editors understand what the Preview button does? Would they use it more if there was an explanation next to it?

There are even some editors who had been around for years and still have no idea about this button. They just never try to use it until someone points it out for them, and then they say thanks a lot and wonder how could they miss such a useful tool. (Based on what I've actually seen at ruwiki's forums.)

Others put on their user pages a userbox that says "This user goes for a minimal edit count and supports the use of the Preview button". Of course this userbox wouldn't have existed if such behaviour was widespread.

That's exactly why the previewing needs encouragement, whereas "Publish" is something that everyone uses and knows about.

How often do people use this button?

Maybe some kind of counter could be installed to count the clicks? Surely, the numbers are better than assumptions.

There are some more ideas at T111088#3023900 (and elsewhere in that task) about the appearance of the Preview button.

I want to +1 this and also add a couple of somewhat related notes.

  1. When you're editing in VE/NWE, the button says "Publish changes". This can throw off people who might think clicking that button would instantly publish the edits and they won't get to review it. I'd like to propose having a separate "Preview changes" button.
  2. Once you hit "Publish changes" and then you click on "Preview my changes" the two options you have from there are either "Resume editing" or "Publish changes". If they look good, I hit Publish but sadly this time I don't get a dialog box for adding an edit comment. Is this a bug or is it intentional?
Whatamidoing-WMF added a comment.EditedJul 12 2017, 9:41 PM

If they look good, I hit Publish but sadly this time I don't get a dialog box for adding an edit comment. Is this a bug or is it intentional?

Intentional, because a few editors asked for it. As always, please mind the gap between "intentional" and "best possible design". Ideas for a better design are always welcome.

If they look good, I hit Publish but sadly this time I don't get a dialog box for adding an edit comment. Is this a bug or is it intentional?

Intentional, because a few editors asked for it. As always, please mind the gap between "intentional" and "best possible design". Ideas for a better design are always welcome.

Few editors asked for having the comment box or not having it?

I'd like an edit comment box before the edit is published in any case.

The workflow was:

  1. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
  2. Click the "Review your changes" button under the edit summary box.
  3. Click the "Return to save form" button to exit the diff. You will see the edit summary box again. (Optionally, type or change your edit summary now.)
  4. Click the button above the edit summary box to save and publish your changes.

The request was to provide this optional workflow:

  1. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
  2. Click the "Review your changes" button under the edit summary box.
  3. Click the blue button above the diff to save and publish your changes.

The difficulty is that some people click the blue "Publish changes" button in step #3, when they probably wanted to click the "Return to save form" (where they could finish typing their edit summaries) instead.

TheDJ added a subscriber: TheDJ.EditedJul 13 2017, 8:52 AM

I too use preview a LOT, especially icw source editing. So much so, that I even made a gadget https://en.wikipedia.org/wiki/User:TheDJ/Actual_Live_Preview that has the edit surface and the preview side by side.

Also:

We should not forget that for VE you always are previewing (by it being WYSIWYG), but for source editing you by default are not. It's not unreasonable to have two different flows in that case.

The workflow was:

  1. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
  2. Click the "Review your changes" button under the edit summary box.
  3. Click the "Return to save form" button to exit the diff. You will see the edit summary box again. (Optionally, type or change your edit summary now.)
  4. Click the button above the edit summary box to save and publish your changes.

The request was to provide this optional workflow:

  1. Click the blue Save/Publish button. You will see the edit summary box. (Optionally, type your edit summary now.)
  2. Click the "Review your changes" button under the edit summary box.
  3. Click the blue button above the diff to save and publish your changes.

The difficulty is that some people click the blue "Publish changes" button in step #3, when they probably wanted to click the "Return to save form" (where they could finish typing their edit summaries) instead.

Thanks for explaining that. I believe I do the same thing you just described and now that I went back and took a closer look, I realize I never even saw the "Return to save form" button which appears at the bottom left of the screen. I feel it's quite unintuitive because the way "Show preview" currently works for you is that you see a full page preview. It doesn't look like a dialog box. You don't expect to see buttons at the bottom left. If that button were moved next to "Publish changes", that would solve most of the problems, I imagine.

Deskana triaged this task as Low priority.Jul 18 2017, 7:17 PM
Deskana moved this task from To Triage to Freezer on the VisualEditor board.

Note: We can get similar result using the VisualEditor view and Preview. VisualEditor doesn't show 100% the final view, but at least similar.
In many cases it is enough, if we switch between VisualEditor and WikiTextEditor, and we don't need the preview button.

jrbs added a subscriber: jrbs.Aug 30 2017, 10:20 PM
Samat added a comment.EditedSep 10 2017, 4:27 PM

After some days of testing, I am more sure that we should provide the "Preview" and "Show changes" buttons the same level where the Publish button is, instead of hiding them at the bottom of the publish popup.

  1. It is quite confusing. If somebody try to see the preview or what she/he changed, before he/she would like to publish the result, she/he doesn't want to click the Publish button. This happened with me at the first time.
  2. The workflow is quite complicate now. After I clicked the Publish button, I click on the Preview button, from there on the Resume editing, from there Publish again, then Show changes (this cycle happens several times), then Publish (and don't be surprised that there is no edit summary at the end). If I click on Publish changes, then there shouldn't be other function, then publishing the changes (with optional Edit summary and a Back button), because this is what can be naturally expected.
  3. I thought I can use the Visual editor for Preview for most of the cases, but

3/A Switching between WikiTextEditor and VisualEditor is very slow for larger pages, many time even stuck. (It was especially inconvenient when I presented a live demo about Wikipedia in front of a larger audience and I couldn't load the page for editing...)
3/B There are many pages outside the main namespace, where VisualEditor isn't activated, so this option doesn't work.

  1. As Mike mentioned at the beginning, usage of the preview button is higher than the publish button. It is not practical to force the user to click two times (and wait for the popup in between) instead of ones in such a case.

Question: is there a special reason to change the short key ENTER to CTRL+ENTER for publishing the changes?

Question: is there a special reason to change the short key ENTER to CTRL+ENTER for publishing the changes?

See T153241

Samat added a comment.Sep 15 2017, 5:57 PM

Is it possible to implement an (probably optional) preview feature (ideally live, but a manually refreshed would be also helpful), which shows the preview of my text below or above the WikiText part?

(We don't have to go far for an example, see what happens here, when you write into the text box.)

TheDJ removed a subscriber: TheDJ.Sep 15 2017, 7:39 PM