Talk:Community Wishlist Survey 2021/Real Time Preview for Wikitext

Project Update: Initial Design Feedback

Hey all, thanks for your comments on the #4 Wish of the 2021 Community Wishlist Survey! The Community Tech has started work on this wish. We wanted to make you aware of this because we'd love to hear your input. Thanks for being such proactive members of the wishlist. NRodriguez (WMF) (talk) 22:37, 30 August 2021 (UTC)

Link to the #4 Wish content: Real Time Preview for Wikitext. --BoldLuis (talk) 09:54, 8 September 2021 (UTC)

Just to make sure: does this only apply to the older (2010) wikitext editor, or will this also be added to the 2017 one? Remagoxer (talk) 20:49, 31 August 2021 (UTC)

Hello there and thanks for your question! This applies to the (2010) Wikitext editor but does not apply to the 2017 Visual Editor wikitext mode. That editor allows users to switch views to a preview of the output within the same step, so we excluded it from our scope since it solutions for it in a different way. We cleaned up the language in our project page to make this clear. NRodriguez (WMF) (talk) 18:22, 2 September 2021 (UTC)

@NRodriguez (WMF): Will this be working for Monobook, too?--- Darwin ^Ahoy! 20:59, 31 August 2021 (UTC)

Yes indeed! It will be working for Monobook. Thanks for your question. NRodriguez (WMF) (talk) 18:22, 2 September 2021 (UTC)

Looking forward to this. I've really been enjoying the live preview in the new DiscussionTools beta feature. That said, the carat icon is completely unintuitive. It should be accompanied by a text label that says something like "preview" (or "preview pane", to use the Windows terminology). Also,any plans to make the preview pane resizable? I could see cases where I'd want to quickly drag the divider to view either the source or the preview wider. Ahecht (TALK
PAGE) 21:29, 31 August 2021 (UTC)

I as well like the instant preview, that I enjoy just now. I can instantly see, whether I link correct and so forth. Perhaps it should be restricted to editing a single section, in huge articles it will be probably be quite difficult a) to see the change, if it's far off the screen and b) to render this big page on the fly. Grüße vom Sänger ♫^(Reden) 04:14, 1 September 2021 (UTC)

@Sänger we are investigating how complex it will be to load large pages, it is something the engineers are actively thinking about and figuring out how to optimize. Thanks for flagging the concern about limiting to a single section as it helps us think of ideas of how to solve the performance issues.

@Ahecht @Sabas88 thanks for these notes! It's really helpful to hear feedback on our proposed designs in the talk page. We are working on testing new button placements so that it is more explicit what the button does. We are thinking of placing it in the toolbar with the word "Preview" explicitly written out, and an option to let folks pick vertical OR horizontal if they are on a desktop that is wide neough. We will ping you when we post the new designs. We also plan on testing them with users to make sure they're intuitive

As for whether or not the pane can be resizeable, we are investigating how technically complex it would be to allow this. We'll keep you updated, for now it is not in scope since we've run into difficulty of a similar attempt at doing this for the Wikisource proofread page in the past.

Thanks and keep the feedback coming! NRodriguez (WMF) (talk) 18:32, 2 September 2021 (UTC)

@NRodriguez (WMF): Hi, will it be usable for all languages?--Cgl02 (talk) 05:26, 1 September 2021 (UTC)

Correct, this feature would be available for any project to leverage so long as contributors are using a non-VE version of a wikitext editor. Thanks for your question! NRodriguez (WMF) (talk) 18:24, 2 September 2021 (UTC)

What about putting the "activation button" in the wikiEditor-ui-toolbar, perhaps all on the right? The decision on where to put the preview (left or bottom) is automatically taken considering the aspect ratio of the display. --Sabas88 (talk) 07:58, 1 September 2021 (UTC)

I generally agree with all of the above. Using the extant menu system makes the best sense, and while half or more users are using mobile devices some of the time, most focused editing is done on desktops and laptops, and ultrawide monitors are much more affordable today (and desirable with virtually universal gaming support now) than they were even two years ago. Layout flexibility is a Good Thing.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:46, 3 September 2021 (UTC)

Changing the text. Imagine I change an article and I see how it is like in real time. Later, I make new changes. How to see how this changes (i.e. add some words to the text or links) in real time?. Do I have to press the Preview Changes button?. Can I see it in real time, without pressing a button??- BoldLuis (talk) 10:05, 8 September 2021 (UTC)

"In real time" means, you'll see asap, as you type, what's that is doing in the text. Same as now with this new discussion tool, where I can see beneath it, how the text will look like, and whether this is a red link or that a blue one. Grüße vom Sänger ♫^(Reden) 11:30, 8 September 2021 (UTC)

September 14: Second Round of Design Feedback

@SMcCandlish @Sabas88 @DarwIn @Sänger @Achect Hello all! We have posted some new designs and questions as a Status Update to add the button to the toolbar and make it more intuitive as you pointed out. We'd love to hear your input, and thanks so much for your continued feedback!. NRodriguez (WMF) (talk) 18:23, 14 September 2021 (UTC)

I like it this new design! --Sabas88 (talk) 10:22, 15 September 2021 (UTC)

Sorry for delay. To answer the posed questions:

"Does the new button placement seem more intuitive to the workflows in the toolbar?" Yes, though it should be called "Live preview" or something, so it's not confused with "Show preview" at the bottom.

"Does the current proposed layout feel like there is enough space to view both the wikitext and the output?" The version that inlines the preview into the editing window ... kind of have to say no. However, it might be convenient enough for spot-checking things. I vastly prefer the "fly-out" options. Regarding those, I think both views should be available when viewing the desktop version of the site. Just have both a right-arrow and down-arrow button. I would absolutely prefer the horizontal fly-out when I'm on my Windows PC with its ultra-wide monitor, but would use the vertical "fly-down" when on my Mac, or if using a tablet or other mobile device (and not using the mobile version of the site – I assume this entire feature set won't be available in the mobile version).  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:25, 26 October 2021 (UTC)

Talk to Us Hours: Video call with Community Tech happening tomorrow

@SMcCandlish @Sabas88 @DarwIn @Sänger @BoldLuis @Remagoxer @Ahecht We will be hosting a video call tomorrow where all are welcome to come and give feedback on our latest designs in real time. We'd love to have you all attend if you have a chance to come by! Thanks for giving feedback in this talk page, check out the agenda for tomorrow here Community Wishlist Survey/Updates/Talk to Us NRodriguez (WMF) (talk) 18:19, 26 October 2021 (UTC)

Dunno whether I could make it or not, depends on my workload tomorrow. Is it better for me to say yes first and not show up, or could I join spontaneously if I could? Grüße vom Sänger ♫^(Reden) 18:35, 26 October 2021 (UTC)

I think I can make this.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:29, 26 October 2021 (UTC)

Data Investigations

Hi! Thanks for your work on this. I'm interested in the questions asked in the project's Data Investigations section—assuming they're about existing practice, did the team find sharable answers to those? (Also, as a heads up, it doesn't look like I received the ping from last August in my Meta notifications so others might not know about this page either.) czar 19:15, 15 January 2022 (UTC)

Opt-out beta feature?

@SGrabarczuk (WMF): According to User:SGrabarczuk (WMF)/sandbox/4, this feature will be an opt-out beta feature on partner wikis. Please don’t do that. Beta features are by nature opt-in; if the feature is mature enough to be opt-in, the beta phase is already over. Either provide no opt-out other than the toolbar button, or provide it on Special:Preferences#mw-prefsection-editing, similarly to VisualEditor, which is an opt-in beta feature available on the beta features panel on some wikis (including Meta), and it’s an opt-out feature available on the Editing panel on most other wikis. —Tacsipacsi (talk) 02:29, 22 March 2022 (UTC)

🤔 That's an interesting point. I'll talk to the team and see if we change anything.

Basically, we're asking several wikis to agree to have this feature as default, and if it proves successful, we'll make it default on all wikis. This is this "pilot wikis" model we have in the case of Desktop Improvements as well. SGrabarczuk (WMF) (talk) 13:27, 22 March 2022 (UTC)

I’m not against it on an organizational level, only on a very technical level. I like the idea of “pilot wikis” or “partner wikis” (the latter term is used by the Editing team), I would just like pilot wikis not to offer this feature in the Beta features section of preferences. Maybe the Talk pages project/DiscussionTools extension is a better example, as it’s actively tested on partner wikis and not just seemingly stuck in the beta phase on some wikis. DiscussionTools with all its at least beta-level parts is available as a beta feature on all wikis, and not yet production-level parts are available only on selected wikis—but not as a default-on beta feature, instead one can opt out of them on the Editing section of preferences. (And I’ll try to translate the rest of the message as my time allows, even if this question is not yet resolved.) —Tacsipacsi (talk) 20:59, 22 March 2022 (UTC)

Sorry for the late reply. We discussed this and we're only planning to make this an opt-out beta feature on Polish Wikipedia, which the community has agreed to. Once available to other wikis, it will be an opt-in, and we don't plan on keeping Realtime Preview as a beta feature but for ~6 months at most, hopefully less, barring any problems. Thanks for raising this concern. MusikAnimal (WMF) (talk) 20:12, 18 April 2022 (UTC)

If it’s only one wiki, then the gadget solution I proposed in gerrit:781096 is even more plausible. For example, you could add

* realtimePreview[ResourceLoader|default|dependencies=ext.wikiEditor.realtimepreview]|realtimePreview.js

to pl:MediaWiki:Gadgets-definition (realtimePreview.js needs to be there in order for the gadget to be loaded, but it may be a red link). —Tacsipacsi (talk) 18:40, 19 April 2022 (UTC)

Unfinished sentence

• User screen sizes- This data could be helpful to understand how useful the

@NRodriguez (WMF): Please finish this sentence (added by you), it’s incomprehensible without its second half. Thanks in advance! —Tacsipacsi (talk) 23:41, 5 May 2022 (UTC)

Feedback for realtime preview

Hello everyone, thank you all so much for helping us improve the Wikimedia platforms with the realtime preview feature.

We are always thrilled to co-create with you all and in this spirit, we would love to schedule a 25min call with some of you to get your feedback on the new feature we released on Polish Wikipedia.

How to participate:

You can use this link to schedule a 25min call with our team:

Schedule a call with us

The call will be attended by 1 to 3 members of our team (Product Management, Design, and Community Relations) and we will share a short testing script for you to try out a new feature we have recently released.

We would be extra appreciative if you came to our call with an article in mind you would want to edit since we will be observing your editing process, if you don’t have an article in mind do not worry, we have prepared one for you as well.

If you can't find a time that works for you on the scheduling link above, please reach out directly to us to schedule the call - thank you!

Privacy policy:

This usability test will ask you to share your screen on a Google Meet link while performing some edits on Wikipedia. This test does NOT require you to have your video active during the call as we will only need the screen sharing and audio from our conversation to get your feedback. We strive to respect your privacy and will do so by deleting the recordings after processing them.

We look forward to speaking with you!

Thank you so much,

Community Tech team

NAyoub (WMF) (talk) 20:06, 12 May 2022 (UTC)

Gadget issues

@CommTechUser:NRodriguez (WMF)User:KSiebert (WMF)User:DMaza (WMF)User:MusikAnimal (WMF)User:SWilson (WMF)User:HMonroy (WMF)User:DWalden (WMF)User:STei (WMF)User:JFernandez-WMFUser:JMcLeod (WMF)User:TheresNoTime-WMFUser:GMikesell-WMF: There have been a few issues mounting up that seem to all be about the gadget loading on plwiki: phab:T307039, phab:T308176, and phab:T309330. I'd been thinking that, because the gadget is a short-term thing, these could be ignored till the gadget is removed. But that might be ages, so I've made a patch to hopefully sort it out. SWilson (WMF) (talk) 09:36, 9 June 2022 (UTC)

@SWilson (WMF): I see that now a class governs whether the textbox is resizable natively or with real-time preview’s JS-based solution. Would it be possible to defer the addition of the class until the real-time preview is actually opened? Until then, there’s no need to disable the native behavior, and native is probably a bit faster and less error-prone. Since after the beta period, it probably won’t be possible to disable the real-time preview without disabling the whole toolbar, it’s important that it has as little impact as possible until the user interacts with it. —Tacsipacsi (talk) 19:16, 12 June 2022 (UTC)

@Tacsipacsi: That's a good point. At the moment the Realtime Preview module loads with the CSS that sets resize:none on the textarea, so it's already delaying that almost as long as possible. It is possible to shift it a bit later, but I'm not sure it'll make a huge difference. Are you seeing the native drag triangle appear long enough to interact with it?

Oh, although you're saying to not apply it till after the preview pane is opened? (Sorry, I misread.) At the moment, the new resize bar is active even when the preview pane is closed. It gives a better UX, because the native resize handle indicates up-down and side-to-side resizability, which is incorrect. Having the new one apply early also means that it doesn't have to change when the preview pane does open. SWilson (WMF) (talk) 03:53, 13 June 2022 (UTC)

@SWilson (WMF): Yes, I mean not to apply it until the preview pane is opened. For the UX, I don’t think it’s our task to fix browsers’ UIs; if you’re dissatisfied with them, feel free to open bug reports in their bug tracking systems. (By the way, the cursor itself does vary based on the resize direction both in Firefox and Chromium, making the user’s choices clear just before they start to drag. On the other hand, your custom resize UI differs from what users are used to, and thus requires a new learning curve.) For the change: yes, it changes when, and in case, the pane opens. I suspect most users won’t use this feature (which doesn’t mean it’s useless, of course); for them, deferring applying the styles would mean that there’s no change at all, compared to the current situation, when there is (flash of unstyled content). And that the UI remains consistent with other text boxes. —Tacsipacsi (talk) 00:50, 14 June 2022 (UTC)

@Tacsipacsi: It's not really the native UI that's the issue, it's the fact that the native UI would be confusing when there are two panes (because it'd either go on the edit box or the preview box or both) and it's not good to have to switch between the two types of resizing. At least, that's why we've gone the way of making the new one. Also, this will mean that we can get rid of the custom resizer in CodeMirror (it's a legacy jQuery UI component). SWilson (WMF) (talk) 07:24, 14 June 2022 (UTC)

@SWilson (WMF): I know the native UI would be confusing when there are two panes, this is why I asked it to use only when there’s only one pane (the preview hasn’t been opened). Yes, it’s confusing if the two states of the edit box use a different resizing techniques, but it’s also confusing if two different textboxes use different resizing techniques. And if one doesn’t use the real-time preview, they encounter only the latter. (And the native technique’s performance is probably also better.) —Tacsipacsi (talk) 08:59, 15 June 2022 (UTC)

Toggles, please

Tracked in Phabricator:
Task T317088

The live preview on the Reply tool does not seem to meet the Community Wishlist spec in that the preview pane cannot be placed beside the text-entry box. On screens wider than they are tall, this is very useful, especially as it is faster and easier to read shorter lines of text. See w:Line length.

Additionally, I can't turn the live preview off. It is always moving in the corner of my eye and I don't like it. I'm okay with it being on by default, as it is useful to new editors. A little radio button next to the word "Preview", so I could turn it off, would be great. HLHJ (talk) 16:39, 5 September 2022 (UTC)

@HLHJ: Thanks for your feedback! :) The reply tool is a separate product, and so isn't within scope of Realtime Preview (although it might seem like a very similar thing!). The discussion page for that is at mw:Talk:Talk pages project/Replying. And as for having a way to turn the preview off, we're already thinking of various ways to do this. Web browsers have a feature that allows people to specify 'reduced motion', and Realtime Preview already looks for this (phab:T314787). But it'd be nice to have an easy way to toggle it on and off as well. I've created phab:T317088 for this, please come and chime in on that ticket if you like. :-) SWilson (WMF) (talk) 09:19, 6 September 2022 (UTC)

DiscussionTools (reply tool + new topic tool) has a ticket about turning off live preview at phab:T313988, you may want to weigh in there. Also, if you absolutely hate the live preview, you can always use the [edit section] link instead of the reply tool, which has the toggleable Realtime Preview. —Tacsipacsi (talk) 18:33, 6 September 2022 (UTC)

Thank you both for the links. I could turn off the tool, and probably will once it's fairly bug-free, or I may just turn off all Javascript as I'm not sure it's doing much for me. From my perspective a much simpler gadget that just added [reply] and [thank] links after each talk-page sig, and opened the section editing window with the cursor appropriately placed, would be preferable (and I'd be fascinated to see if it had similar effects in A/B testing). I've commented on the UI for toggling on Phab; obviously I hope for similar UI features for similar tools. I'm not sure if the side-by-side format has already been suggested for Reply Tool on Phab; I couldn't see it. HLHJ (talk) 01:19, 7 September 2022 (UTC)

What advice would you give to someone who is new to this site?

I just joined today, and I am struggling to find my way around. Any tips or advice from people would be greatly appreciated! Jazzy.nicole (talk) 16:38, 26 September 2022 (UTC)

Hey there, so great to meet you! Welcome to the movement for free knowledge. I recommend starting out with some of our newcomer experiences if you go to your User page you should find an onboarding with some suggested edits. https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage here is the explanation of what you should be seeing. Happy contributing, we're happy to have you here! NRodriguez (WMF) (talk) 15:12, 27 September 2022 (UTC)

Profile View

I feel like wikepedia should had a profile view, where you get to add a profile picture, a banner, and a bit about yourself. I feel like it would be a bit more professional. What about you? What do you think? Jazzy.nicole (talk) 16:41, 26 September 2022 (UTC)

Delay for section previews

I see there is a 2,5 second delay for previews. I think that's quite a bit, but I understand trying to be conservative on this for various reasons. However, I think we can easily make this somewhat depend on the size of the preview. Say we have a range of 300ms to 2500ms, and make the delay depend on the bytesize of the wikitext to be previewed ? —TheDJ (talk • contribs) 10:49, 30 September 2022 (UTC)

Hello there! That's a valid idea for an improvement. We'll discuss it at the next project check in and see about feasibility. Thanks as always for the great feedback and ideas. NRodriguez (WMF) (talk) 00:12, 14 October 2022 (UTC)

Editlinks

If I turn on the feature

1. only templates used in the edited section are shown below the edit window
2. editlinks and protection info is omitted in the same place
3. the sorting of the inserted templated is quite different from the normal editview
4. template redirects are not highlighted (even if turned on).

I'm not sure, if it's a bug or a feature, but it's unpleasant to lose these useful links. — Draceane ^talk_contrib. 11:35, 11 October 2022 (UTC)

Thanks for writing, we will look into what you reported and discuss it as a team to see what we can do about this! We really value the feedback. NRodriguez (WMF) (talk) 00:11, 14 October 2022 (UTC)

This is how “live preview”, on which real-time preview builds, has been working for ages, except for #1, which is how both live as well as traditional preview has been working for ages (and as such, I don’t think it should be changed, since it’s not a regression). While #2 and #4 makes no sense and should probably be fixed, #3 actually makes sense, and I prefer it as a techy editor: it sorts templates based on the order they first appear on the page. This is quite useful when I try to figure out why a meta-template gets transcluded. (On the other hand, this may be surprising and confusing for you and other users using the real-time preview for the first time, so maybe it should be possible to switch between the orderings? But introducing a lot of preferences can cause problems.) —Tacsipacsi (talk) 21:37, 15 October 2022 (UTC)

@Tacsipacsi: Thank you for the response. Fixing at least #2 and #4 would be nice. — Draceane ^talk_contrib. 14:47, 1 December 2022 (UTC)

@Draceane: I created a task for #4 and submitted a patch for that: phab:T327354. There are tasks for #2 and #3 as well: phab:T321032 and phab:T315746. —Tacsipacsi (talk) 23:34, 18 January 2023 (UTC)

Issue regarding the preview in conjunction with Vector (2022)

Tracked in Phabricator:
Task T322337

I have stumbled upon an issue that arises when using the preview feature while also having the Vector (2022) theme enabled.

When I use the preview feature on Vector (2010), the preview shows the article text at the same font size as the text would be if I was reading the article normally. However, when I use the preview feature on Vector (2022), the text is roughly 125-150% larger than it appears when reading the article normally.

To make sure Vector (2022) was the cause, I A/B tested the problem on both a page in the article namespace and a page in the Wikipedia namespace on the Danish Wikipedia using both themes. I'm using Firefox 106.0.3 (64-bit) InsaneHacker (talk) 14:43, 3 November 2022 (UTC)

Hey InsaneHacker, thank you for the comment — I think this sounds like this bug report? Would you mind taking a very quick look and confirming if it's the same? ~TheresNoTime-WMF (talk) 15:08, 3 November 2022 (UTC)

@TheresNoTime-WMF: I'm not sure it's the same. When I use the normal "Preview" button, the preview has the font size I would expect, while the live preview is too big. I've uploaded an example screenshot here. The text at the top is what is shown when I use the old school preview feature (normal size), the text on the left is the wikitext editing window and the text on the right is the live preview (large text). InsaneHacker (talk) 15:14, 3 November 2022 (UTC)

@InsaneHacker: Hmm, thank you for the clarification (and screenshot!), this does indeed seem a little different — are you comfortable filing a bug report on Phabricator? ~TheresNoTime-WMF (talk) 15:17, 3 November 2022 (UTC)

@TheresNoTime-WMF: It's been a while since I've done so, but it should be up now at task T322337. InsaneHacker (talk) 15:31, 3 November 2022 (UTC)

@InsaneHacker: A perfect bug report, thank you! I think there's probably a relation between task T322337 and task T321728, but someone will look at this shortly — thank you again for raising it! ~TheresNoTime-WMF (talk) 15:34, 3 November 2022 (UTC)

Scroll sync

If I recall TheDJ's script correctly, one of the things I liked was being able to see not so much the full article previewed in real time but my active section. I.e., I might have loaded the full page's wikitext to be able to jump between paragraphs, but all I really want to see on the right is that the paragraph I have in view is formatted correctly. If there were some way to toggle a scroll lock/sync so that the preview pane always showed what I was editing on the left (as I bounce between sections in the wikitext) that would be perfection. czar 04:44, 28 November 2022 (UTC)

How to activate?

Hi, I'm new to Wikipedia editing and pretty confused here. I learned about this tool through Preferences/Beta Features and can't figure out how to use it. Do I need to have MediaWiki installed? If so, how do I do that for use on Wikipedia? Thanks. Wracking (talk) 23:19, 2 January 2023 (UTC)

@Wracking: Welcome! And sorry for the confusion. If you want to use Realtime Preview on Wikipedia, there's no need to install MediaWiki yourself — it's already installed and is the software that runs Wikipedia (and Meta Wiki, here). You've done all the set-up that you need: enabling the Beta Feature is all that's required, and now when you edit a page with the wikitext editor (i.e. the Source, not Visual editor) you should see a new 'Preview' button at the right end of the toolbar. That's what opens the Realtime Preview pane. There is some more documentation at mw:Help:Extension:WikiEditor/Realtime Preview. SWilson (WMF) (talk) 04:03, 3 January 2023 (UTC)

@SWilson (WMF) Thanks so much for the quick response! I've enabled the beta feature but I don't see the "Preview" button, no matter what I do. I have the "2010 wikitext editor" box checked in preferences and I am looking at the Source editor. I've included a photo of what I see.

Wracking (talk) 05:32, 3 January 2023 (UTC)

@Wracking: Ah, it makes sense now: what you're looking at there is the 2017 wikitext editor, which is a source editor but it's not the one that Realtime Preview works with! (This is a pretty common confusion.) To use the 2010 wikitext editor, you need to disable the 'New wikitext mode' Beta Feature. SWilson (WMF) (talk) 05:41, 3 January 2023 (UTC)

@SWilson (WMF) Got it! I didn't realize those contraindicated each other. Thank you so much!! Wracking (talk) 05:48, 3 January 2023 (UTC)

@Wracking: Oh good! And yeah, it's not super obvious! :-) But after next Monday it'll be slightly less confusing because Realtime Preview will no longer be a Beta Feature and instead will just be present whenever anyone uses the 2010 wikitext editor. (I'm not sure that'll make it clearer for people who find themselves in the 2017 editor and wonder where the preview button is… but we'll sort that out later perhaps!) SWilson (WMF) (talk) 05:57, 3 January 2023 (UTC)

Wrong preview on table

Tracked in Phabricator:
Task T327049

It is good to be able to display the page and the editing window not only above it, but also below it. However, with wide tables, it is not good to see the management of the table content. Dušan Kreheľ (talk) 09:29, 10 January 2023 (UTC)

@Dušan Kreheľ: Do you mean that, rather than side-by-side, it would be good to be able to view the realtime preview pane above/below the editing box? That's currently not possible, but there is a preference "Show preview before edit box" that can be used with traditional (non-realtime) previews to put the preview above or below. Combining that with another preference "Show preview without reloading the page" might get you some way to the functionality you want. SWilson (WMF) (talk) 03:13, 11 January 2023 (UTC)

@SWilson (WMF): "Do you mean that, rather than side-by-side, it would be good to be able to view the realtime preview pane above/below the editing box?" Yes. On 1024px monitor, the actual solution for the table (if the user is interested) is inappropriate.. Dušan Kreheľ (talk) 11:53, 11 January 2023 (UTC)

@Dušan Kreheľ: That makes sense. This isn't currently possible (I'd recommend the live-preview workaround I mentioned above) but I've created a feature request for it so it can be tracked. You can add any comments you want to that task. Thanks! SWilson (WMF) (talk) 07:44, 16 January 2023 (UTC)

How to disable?

Hello there. It appears that the English Wikipedia has recently enabled this feature for all users using the 2010 wikitext editor (I don't know if it's on other wikis as well, I haven't checked). While I do appreciate the option and I can see how some will find this helpful, I find this button redundant given that there is already a "Show preview" button below the edit box, and I dislike the narrowed edit box when the feature is being used. Is there a way to disable this functionality? Thanks! InfiniteNexus (talk) 06:08, 16 January 2023 (UTC)

@InfiniteNexus: To hide the button you can add the following to your global.css (or common.css if you only want to hide it on one wiki):

.tool[rel="realtimepreview"] {
    display: none;
}

I'll add this information to the feature's help page as well. SWilson (WMF) (talk) 06:55, 16 January 2023 (UTC)

Thank you, that worked. Cheers! InfiniteNexus (talk) 00:49, 17 January 2023 (UTC)