Topic on 2017 wikitext editor/Feedback

Tracked in Phabricator
Task T153306

Sure, it's 2019 and we're talking about the 2017 editor, so apologies for being late to the party.

• To preview and return to editing, the process of "Publish changes…" – Preview – back-arrow button – X button is cumbersome and confusing. The number one obvious improvement that could be made to this UI is to add a Preview button to the left of "Publish changes…"
  • Of course, visual mode doesn't need a Preview button, but I don't see a problem in having that be different between the two modes.
  • (I would even argue that publish before preview/test is a generally bad idea for any source-code editing. I'm tempted to advocate to replace Publish with Preview when in wikitext mode, but admit forcing all writers to go through a preview step wouldn't fly.)
  • Flipping between source- and visual-edit mode just to achieve a preview (like with this Flow editor I'm using now) is hard to get used to. Not necessarily bad, but a bit of a shock to the system. If it weren't for the "...and you can preview the result" text, I'd be a bit lost. Ditching the Preview button totally from 2017 Editor and requiring visual-edit-to-preview would be a barrier to adoption.
  • Using the keyboard shortcuts is a great tip for a workaround, but it's still just a workaround. I have to try to remember the modifier keys: was it Alt+Shft, Ctrl+Shft, or Ctrl+Alt? Also, at work I've seen end-users take their hand off their keyboard, grab the mouse, drag the pointer across the screen, home in on the next text field in an application, click it, then return their hand to the keyboard. When they could have just pressed Tab to advance from one field / textbox to the next.
• When in Preview, the "Publish changes" (no "...") button doesn't give me a chance to revisit the edit summary and minor-edit checkbox. The whole thing just goes whoosh.
• Edit-summary overlay is presented like a modal dialog, but from there the Preview button produces a full-page overlay. The animations help this to not feel totally weird, but still
• Combining the points above, what I'd like to see instead is:
  • From Editing screen, two buttons: Preview and Publish... which take you to the preview and edit-summary overlays respectively.
  • From Previewing screen, two buttons: Back which returns you to editing (or to whichever previous screen), and Publish... (with "...") which brings up the edit-summary overlay.
  • From edit-summary box, two main navigation/action buttons: Publish and Cancel/Close/Back. Review Changes to show diff (as in visual mode) would still be good, IIRC the diff isn't full-screen and has a shaded surround?
    • Getting to the preview from here is problematic. Cancel and then preview from the edit screen? Make it a toggled alternate state for the diff-viewer? Both?
• Syntax highlighter has problems with line selection, so I had to turn it back off. This is a pity, since syntax highlighting is a huge benefit when editing or reading code.
• Interaction and animations were responsive on a new, well-specced desktop PC with large monitor. I've yet to try this on a lower-powered, smaller-screened laptop or tablet.
• Cite tool is quite different from the one in the 2010 editor, but it works fine (at least for the simple case that I tried). Didn't notice a preview-before-insert option, le sigh.
• In the "normal" editor, the cycle of alter-preview-alter-preview seems to give some protection against tab reloads, browser crashes, etc. (for browsers that have a reload-last-tab-set feature, which is most of them these days). The visual-based editors don't seem to save any local state against mishaps. To spend a lot of time on a carefully-crafted reply or edit and then lose the lot is extremely discouraging. Do we need to go back to the old practice of intermittently pasting our work into an external text document or notepad?

I do hope that dev time can be devoted to getting this editor out of beta, as it shows promise. A consistent toolbar might be appreciated by some of those who toggle often between visual and source modes(?). Just please please don't make it the only choice nor stop maintaining the old editors.

That's a lot of dot points – as I got carried away by detail – so, to summarise, my Big 3 areas for improvement would be: (1) flow of preview–diff–summarise–publish, (2) syntax highlighting, (3) preserve state against loss.

But I just realised (2) might be for Timeless only? Per Topic:V3ap9inic4lnhfim below.

(2) is probably for Timeless only, and (3) is handled with a (silent) auto-save feature. You might lose a little bit, but you shouldn't normally lose everything.

Oh, which editors are meant to have auto-save? I find it not uncommon to lose content that I've been working on. Could you point me to where the feature is described?

Second impressions

Tried just now with Safari, iOS 9.3.5, Vector skin, "desktop site", 9.x-inch Retina display, iPad 3, touch only (no Bluetooth kbd).

Just a quick test: deleted one word, tapped around the toolbar and publish-changes-related screens.

UI still fairly responsive. Feels just a teeny bit slow, but no worse than many sites on this older device. Only exception is the symbols list (omega button) takes a very long time to show.

I see now that you can already flip between Review your changes and Preview screens (dialogs, modes, views, overlays, whatever is the correct term). The relationship between these two screens and Save your changes makes more sense now.

I can see how people might want to publish directly from the diff or preview screens, but still think there is value in having them return to Save your changes before publishing. At the cost of a single click, it means they get a second chance to see the legal copyright note, and to consider their edit summary.

Perhaps the initial "Publish changes ..." button with ellipses could be renamed to "Review and publish..." to reflect its full function and distinguish it more from the second "Publish changes" button. I do notice on the smaller screen there is less free space on the toolbar to accommodate a second button.

Multi-line selection with syntax highlighting turned on works fine with Vector skin.

Bug? Can't paste into Edit Summary box on this platform.

Did the non-pasting Edit summary contain any sort of formatting (e.g., links or images)? There are some things that it won't let you paste because it can't make sense of them. In that instance, "Paste and match style" (or whatever system the web browser has for pasting unformatted text) usually works.

On further testing, it appears to depend where I copied from. More like a VE copying problem than a pasting problem. Will need to check some more platforms. If this only happens on old iOS versions then there's less reason to fix.

With Safari on iOS, I don't have an option to paste as plain text (I do love Ctrl+Shft+V on desktop Firefox!).

Procedure I'm following is: tap in the text field (edit summary) to activate it; tap at the cursor to activate context menu; observe whether menu says "Select | Select All" or "Select | Select All | Paste".

Desktop view: if I copy some words from 2017 wikitext editing mode or from visual mode, they are not pastable into the edit summary. Text from an external application like Notepad is pastable. For what it's worth, I can't paste the same copied text (from 2017 source mode) into this SD-editing box either. If I try to paste it into Notepad, there is a paste option but no content is inserted.

Mobile view: if I copy text from wikitext editing mode it is pastable, but if I copy the same text from visual editing mode it isn't.

Oh ha ha ha face palm.

On iOS 12 Safari, the VE toolbar gives me a warning alert that I am “using a browser which is not officially supported by this editor”. And yet copying works there.

iOS 9 Safari, no alert but copying doesn't work.

We can probably Let It Go … or maybe Let It Be? The user base of older devices shouldn't be ignored if we want to reach people in rural, impoverished, and international situations (or maybe you have user-agent stats saying it's not that important?). But iOS is served primarily by the mobile view and we don't need every editor to work perfectly on every platform.

@Whatamidoing (WMF): Could somebody list this somewhere for the record as "known issue won't fix", if that's appropriate?

Rural and impoverished situations probably aren't using iOS anything. They're probably using Android.

Does phab:T190291 look like this problem? I'm going to put a link to this discussion there.

Yes, that's exactly it, Whatamidoing. And Belezzasolo described it more succinctly than I could. Thanks for adding the comment to that task.

Good point about Android.

I just want to echo Pelagic's comment about the very confusing Preview flow. I tried as hard as I could to predict what would happen when I pressed "Publish" again while in Preview mode, but it still didn't do what I expected (i.e., it didn't do what had happened when I'd pressed an identical-looking "Publish" button just moments before to get into Preview mode in the first place). As a result, I ended up accidentally publishing this change without the edit summary that I had intended to give it.