Jump to content

Community Wishlist Survey 2021/Editing/Live preview

From Meta, a Wikimedia project coordination wiki

Live preview

Live preview
  • Problem: Wikitext editors often skip the step of previewing their edits, missing simple typos and formatting errors that could be easily avoided if previewed live.
  • Who would benefit: Wikitext editors
  • Proposed solution: Something akin to w:User:TheDJ/Actual Live Preview, though this script hasn't worked for me in years, that would display a live preview side-by-side with the wikitext editor
  • More comments:
  • Phabricator tickets:
  • Proposer: czar 20:05, 22 November 2020 (UTC)[reply]

Discussion

If implemented, this should be a per-edit action (like the existing Preview or Show Changes button), not a per-user preference. I might want a side-by-side preview on a big, wide desktop monitor, but not when using desktop-web on a tablet in portrait mode. For users who change between devices, visiting the pref's each time would be cumbersome. Pelagic (talk) 22:27, 17 December 2020 (UTC)[reply]

This is a very good idea, but it doesn't go far enough. I propose an enhancement under which an editor could freely toggle between three editing modes:

  1. Only wiki markup editing.
  2. Only visual editing.
  3. Both kinds of editing, available concurrently. In this mode, an editor could choose whether the two editing windows will be side by side or one above the other, and which window will be above or at the left. These preferences could be saved. The editor could then edit the wikitext and quickly see the effect on the appearance of the page. This is what Czar had in mind. With this enhancement, however, the editor also could edit visually and quickly see the effect on the wikitext. Why display a non-editable preview, when a visual editing tool exists? Instead, let's open both the wiki markup editing tool and the visual editing tool simultaneously, on a split screen. The editor could then switch from one kind of editing to the other kind, simply by moving the cursor from one editing window to the other editing window.

Continuous, automatic updating might be impractical. It might require too much processing and data transmission. If so, let it occur on demand, whenever the editor clicks on the Update button or invokes the corresponding keyboard shortcut. Ubzerver (talk) 13:33, 21 December 2020 (UTC) Revised. Ubzerver (talk) 14:15, 24 December 2020 (UTC)[reply]

I hadn't even noticed that people had suggested this one (based on something I made before). I do have some points on this and I figured I'd add them for future reference.
Yes, it really only works when you have a pretty large/wide screen. My gadget also used to work like that. It would check if your screen was a certain size and only then enable this functionality, without the appropriate width (1200 web pixels), you would only get the 'regular' preview above or below the edit window, with not updates. While this 'worked', it was also rather confusing to many people. Interface elements that 'randomly' disappear often have this effect and it's a bit bad form. Instead, looking at it again, It would probably be better to have a tabbed interface to switch between source and preview mode (the original WE2010 editor actually had such a tabbed mode interface, but it was never released). Then we could have a separate control to switch between tabbed and side-by-side modes if you have sufficient screen real estate and a control to enable/disable live previews.
Another big problem was keeping proper track of what wiki text corresponded to which part of rendered html (allowing you to keep the part you are editing in the displayed part of the preview). With something like parsoid that might be much easier to fix however. And I do agree that live preview should be an option you can easily toggle on and/or off. Ideally it would test the performance and based upon the test increase or decrease how often an update would occur.
Perhaps it is a good idea to think about the resizable panes and boxes inside IDEs etc for instance, that can be pinned and unpinned in various different ways, orientations and layouts. I think that would make for an interesting exploration. —TheDJ (talkcontribs) 12:58, 6 January 2021 (UTC)[reply]

Voting