Have Show preview and Review your changes more directly accessible in the New Wikitext Editor
Open, NormalPublic8 Story Points

Subscribers
Tokens
"Love" token, awarded by Charlie_WMDE."Love" token, awarded by Quiddity."Love" token, awarded by Jan_Dittrich."Love" token, awarded by thomaskuntzz."Like" token, awarded by Juandev."Love" token, awarded by Johan."Love" token, awarded by MichaelSchoenitzer."Like" token, awarded by Pearli123."Love" token, awarded by KartikMistry."Like" token, awarded by Arrbee."Love" token, awarded by Ltrlg."Love" token, awarded by Lluis_tgn."Love" token, awarded by Raymond."Like" token, awarded by Alsee."Love" token, awarded by Guycn2.
Assigned To
None
Authored By
Amire80, Dec 15 2016

Description

The announcement about the New Wikitext Editor in the Hebrew Wikipedia received several replies that asked for more direct access to diff and preview. Having these two actions "hidden" after the Save button confused people.

Preview, in particular, is not available at all if the article wasn't edited because the Save button is inactive (this also means no null edits). While this could be worked around by opening the "Read" link at the top in a new tab, this requires some extra effort in comparison to the regular wikitext editor, where a preview can be shown upon the first loading of the editing page (it's a preference), making the current content of the article more directly accessible.

Workaround: for those that are interested, the access keys (alt+shift+p / alt+shift+v) will still take you directly to show preview/changes.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 15 2016, 11:42 AM
Guycn2 added a subscriber: Guycn2.
Alsee awarded a token.Dec 16 2016, 9:05 AM
Alsee added a subscriber: Alsee.Dec 16 2016, 9:07 AM
Alsee removed a subscriber: Alsee.
Tgr added a subscriber: Tgr.Dec 18 2016, 8:35 PM

Also, the save button is scary for less experienced users as there is no indication it won't just save the page (IMO something like "Review & Save" would work better).

Switching to visual mode is also a sort of preview, but that's also not obvious, plus it doesn't work on talk pages.

Lluis_tgn added a subscriber: Lluis_tgn.
Ltrlg awarded a token.Dec 28 2016, 2:37 PM
Ltrlg added a subscriber: Ltrlg.
Pearli123 added a subscriber: Pearli123.
Elitre added a subscriber: Elitre.Jan 19 2017, 11:13 AM

I've opened a related feature request to improve the usability of the Preview panel, matching that of the classic Wikitext editor.

https://phabricator.wikimedia.org/T155732 - A Preview panel that doesn't obscure the wikitext box

Johan awarded a token.Jan 24 2017, 9:38 PM

We are looking in to this. Also for those that are interested, the access keys (alt+shift+p / alt+shift+v) will still take you directly to show preview/changes.

Also, the save button is scary for less experienced users as there is no indication it won't just save the page (IMO something like "Review & Save" would work better).

Switching to visual mode is also a sort of preview, but that's also not obvious, plus it doesn't work on talk pages.

That sounds like it should be a separate issue, and is not specific to the wikitext mode.

Elitre updated the task description. (Show Details)Jan 27 2017, 5:13 PM

As part of T44138: VisualEditor: Toolbar "Save page" button is confusing as it merely opens the dialog to save the page I'm thinking of re-organising the toolbar's terminal control into a split button:

[ Save changes | v ]

Clicking on "save changes" would open the save dialog, as now; clicking the 'v' would open a menu of save-related controls like "preview", "Show my changes", "switch editors", "cancel", etc.. Does that seem reasonable?

As part of T44138: VisualEditor: Toolbar "Save page" button is confusing as it merely opens the dialog to save the page I'm thinking of re-organising the toolbar's terminal control into a split button:

`[ Save changes | v ]`

Clicking on "save changes" would open the save dialog, as now; clicking the 'v' would open a menu of save-related controls like "preview", "Show my changes", "switch editors", "cancel", etc.. Does that seem reasonable?

I like this idea. It is simple and understandable and makes these possibilities more directly accessible.

Tgr added a comment.Feb 21 2017, 8:34 PM

That sounds like it should be a separate issue, and is not specific to the wikitext mode.

Filed as T158701: Save button name is misleading in VisualEditor / new wikitext editor.

Clicking on "save changes" would open the save dialog, as now; clicking the 'v' would open a menu of save-related controls like "preview", "Show my changes", "switch editors", "cancel", etc.. Does that seem reasonable?

Sounds like a good solution to me, as long as all options are duplicated to the form (the usual advice for dropdown buttons is to make sure you don't put behind them anything that's not reachable in other ways, since not all users recognize the control).

thomaskuntzz rescinded a token.
thomaskuntzz awarded a token.

@Jdforrester-WMF Could you take a look on this and prepare a patch with your suggestion? I don't see any obstacle or blocker here. Maybe you could resolve T44138 in the same patch too (if there already aren't separate entries for Save page button in top bar and Save page button in save dialog)

@Jdforrester-WMF Could you take a look on this and prepare a patch with your suggestion? I don't see any obstacle or blocker here.

Sorry, thought I'd created the blockers earlier. Now done.

Alsee added a comment.Apr 4 2017, 5:59 AM
  • Burying PREVIEW in a menu behind the SAVE button leaves new users lost and scared when they actively avoid touching the dangerous SAVE button.
  • Burying the most used button in the editor is disruptive for experienced editors.

The most used button in the entire editor, and second most important button in the entire editor, absolutely warrants direct placement next to the SAVE button.

Amire80 added a subscriber: Alsee.Apr 4 2017, 7:16 AM

The most used button in the entire editor, and second most important button in the entire editor, absolutely warrants direct placement next to the SAVE button.

Is there data that says that it is actually the most used button, or is it a guess? It would not be preposterous if it is a guess, but actual data would still be better.

Tgr removed a subscriber: Tgr.Apr 4 2017, 8:38 AM
TheDJ added a subscriber: TheDJ.EditedApr 4 2017, 9:24 AM

i'd say that for wiki text,, we should actually encourage people to always go through preview. Maybe we could make that the default for the 'Save' button, and have the button behave as a dropdown, like on the editor switcher as well ?

[Preview]

  • [Save]
  • [Preview]
  • [Show changes]

Seems like an interesting experiment to me.

A very typical wording for the save button would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.

IMHO the Preview panel should have its own separate button rather than being available in a dropdown (thus requiring two clicks).

A very typical wording for the save button would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.

"Publish" is already too long in English, and interferes with the functional design especially for users with mobile devices or with eyesight issues. In other languages, like Polish, it's even worse. The principal functionality of this button needs to be briefly communicated. It's exceptionally unlikely that we would make the label multiple words.

IMHO the Preview panel should have its own separate button rather than being available in a dropdown (thus requiring two clicks).

If we were to take over (even) more room on the toolbar, we would have to demote other features from the toolbar for space (we're currently at the limit for space for the average desktop user, at 1000px wide at normal zoom on Vector).

Which do you propose to make this work? Should we get rid of the Cite button? The link and menu buttons? Fundamentally, preview is not more important thank anything already in the lists, I fear.

dialmove added a comment.EditedApr 6 2017, 10:44 AM

IMHO the Preview panel should have its own separate button rather than being available in a dropdown (thus requiring two clicks).

If we were to take over (even) more room on the toolbar, we would have to demote other features from the toolbar for space (we're currently at the limit for space for the average desktop user, at 1000px wide at normal zoom on Vector).

Which do you propose to make this work? Should we get rid of the Cite button? The link and menu buttons? Fundamentally, preview is not more important thank anything already in the lists, I fear.

If there are problems of space, why not move the Preview button to the bottom of the screen, where there would be enough room for separate Preview and a Save buttons?

The standard placement in web design for submit buttons is below the form they are sending, anyway; and, as an added benefit, it would be more consistent with the placement in the old editor. I never understood why the submit button was placed at the top right in the new editors.

For people accustomed to writing wikicode directly, Preview is way more important than any helper button to insert code; having a look at the final result before submitting is essential and can't be accomplished by any other means, but conversely any wikicode could be written by hand without a button. The old editor has direct buttons for Save, Preview and Show changes, so it's way better than the new editor in that regard.

Having these two actions "hidden" after the Save button confused people.

"Save" can be a sort-of-sensitive action: After you saved, your changes are public.Thus, some people I know say they always preview etc. (especially, if they work in a kind of conflict prone context in WP). Problematic is not the additional click imho but that the button indicates it will save right away.

This is not a new problem, and in desktop applications there is the useful standard of suffixing "…" to items that yield an additional dialog to say "The action will not be executed now, but you will get a dialog before and then be able to do it". I know it is still extra space, but it would use an established standard and would not require huge shifts.

Dvorapa added a comment.EditedApr 7 2017, 9:25 AM

@Jan_Dittrich This is also discussed in task T44138

As part of T44138: VisualEditor: Toolbar "Save page" button is confusing as it merely opens the dialog to save the page I'm thinking of re-organising the toolbar's terminal control into a split button:

`[ Save changes | v ]`

Clicking on "save changes" would open the save dialog, as now; clicking the 'v' would open a menu of save-related controls like "preview", "Show my changes", "switch editors", "cancel", etc.. Does that seem reasonable?

If we want to make preview more independent from the save process, we can also present "preview" as another mode at the same level of visual and source editing. I have illustrated the idea below.

Keyboard shortcuts can be shown as part of the menus if we want advanced users to have a quick way to switch modes.

Dvorapa added a comment.EditedApr 19 2017, 5:43 PM

@Pginer-WMF I don't think this is a good idea to hide preview into editor switch. It is like trying to sell a painting between blank papers. On top of that preview is crucial for wikitext mode, but for visual mode it is not necessary so much.

Maybe we should first find out, how users behave when editing in wikitext editors and then think how to make it easier to them. Preview is certainly one of the most important features of textual editors, maybe we could get an inspiration from some markdown or HTML editors.

I think every user sometimes adds some markdown not sure about the result, then previews it if it is ok and return back to continue in work.

Aklapper renamed this task from It would be nice to have Show preview and Review your changes more directly accessible in the New Wikitext Editor to Have Show preview and Review your changes more directly accessible in the New Wikitext Editor.Jun 26 2017, 5:20 AM
Izno added a subscriber: Izno.EditedAug 30 2017, 5:25 PM

Maybe we should first find out, how users behave when editing in wikitext editors and then think how to make it easier to them. Preview is certainly one of the most important features of textual editors, maybe we could get an inspiration from some markdown or HTML editors.

I think every user sometimes adds some markdown not sure about the result, then previews it if it is ok and return back to continue in work.

That's my workflow when I am unsure, which is when I most want to preview a page. When I am certain of the result I skip previewing and go straight to save.

It might be reasonable to consider a second row of commands indeed. Someone suggested such a row at the bottom--I'm not really enthusiastic about that since I hate scrolling my mouse down. You could also have a column down the right or left hand sides with actions, rather than the wikitext manipulation toolbar (PageCuration comes to mind), or a second row at the top--one for actions and one for wikitext manipulation

Edit: And some stuff more about T155732: Provide a Preview panel that doesn't obscure the wikitext box and maybe the skin's sidebar (?).

Daylen added a subscriber: Daylen.Sep 5 2017, 11:36 PM