Hello, the reply-tool is impossible to use. When I type my reply, then the window below the writing field shows a preview of the reply I am writing, updated immediately. That means when I type there is always something moving on the page. That is extremely annoying. I want to turn of the preview, but I don't see how.
Topic on Talk:Talk pages project/Replying/Flow
Have you tried switching to the visual mode?
Ah! Thank you very much!
Most of the "key sequences" that you use in typing wikitext work in the visual mode. For example, if you type [[ to start a link, it will open the link box. If you type <ref, it will offer a reference dialog. Press Escape to get these nowiki'd and back to regular typing.
IMO the only real shortcoming for the visual mode is that you can't add templates (directly). This is because some templates (e.g., infoboxes) can make a real mess right now.
Seems to be mostly in line with the Visual Editor. Thanks again!
I have this issue too, but I can't (and wouldn't want to) use the visual mode. Can there please be a way to switch to a preview button instead? It should at least respect my browser's prefers-reduced-motion settings and not have things moving around on the page when I'm typing.
Nikki, the devs tell me that there's a "unique CSS class" for the live preview area, which means that if you post a request at WP:VPT (or I can, if you prefer), someone ought to be able to throw together a script that would completely hide the live preview for you.
You wouldn't get a preview button this way, but I suppose you could switch to the visual mode to check links. It won't let you switch to visual mode if you have any templates in the message, so this would be an imperfect solution. Maybe it'd be better for you overall than the default, though?
A persistant-state radiobutton next to the grey word "Preview", which froze it or turned it off, would be welcome. Am I right to take it that the browser is actually sending ~every keystroke to the WMF servers, which run it thru Parsoid, and send back the result?
> " ~every keystroke to the WMF servers"
There is a debounce/throttling, so only every second (or something, I don't know the exact timeframe), will it send the input and ask the servers for a new preview.
I don't know how it handles live preview. Extension:DiscussionTools/How it works has some technical information, but I didn't see anything about the preview system.
If I were on an expensive pay-per-bandwidth system, which many poor people around the world are, the minimal bandwidth of just sending the text when completed might be useful. Bandwidth also has a carbon footprint. I don't know what the bandwidth-use difference of this system is in practice, given real-world levels of pausing, deleting, rewriting, typo fixing etc.. It may be quite small, and an acceptable cost for measured benefits. But an estimate of the CO2 cost of this change globally, and the financial cost to the editor in a worse-case scenario, would be really good to have.
I'd guess that the majority of my talkpage edits contain not markup beyond the tildes of my signature, and I really don't need a preview for them. I do want a preview sometimes (I miss it on these talk pages, though the "thank" link is nice), but I'm happy to have preview only on-demand.
Metered connections is a good point. I’m not sure if it causes significant extra CO2 emission, but if one has to pay for every byte, it may very much make a difference for them. The class-based approach I proposed only hides the preview, doesn’t prevent it from being generated, so the costs are still there. Looks like we really need a real solution (I consider this class-based thing rather a quick workaround/hack than a real solution).
I'd be surprised if that matters much. You'll probably need about fifty to a hundred previews like that before you are close to even a single time of opening the edit page itself.
Okay, so let's say I make an edit of a few hundred characters, a typical length, and get a update of the preview once a word or so, which is what seems to be happening; English words average about 5 characters. So that would mean 50-100 previews is about what I get per 250- to 500-character edit, meaning that that, if the data for loading the edit page is about that of 50-100 previews, I double my bandwith consumption for each edit. On the carbon-emissions issue, what matters is really the aggregate effect across all users, which may be fairly negligable, but we must have the A/B data to tell by now.
If you are on a 56 kbaud connection (a single voice channel, still very common), loading even simple webpages can be noticably slow. Images are really slow. In my experience, on lousy connections, if you send data in discrete bursts of low-bandwidth stuff like text, ideally with the transmission manually prompted, it works; stuff that requires fairly continuous 2-way transmission often just doesn't work. This may be due to latency and intermittent signal degredation and lousy error handling and all sorts of other issues beyond straight bandwidth; I don't know. If you turn off the loading of Javascript from en.wikipedia.org, the "reply" links and functionality vanish, and on a slow or expensive connection you'd probably do that. If you had the technical knowledge.
Even on a very fast fiberoptic connection, turning off scripts makes a large proportion of webpages load noticably faster, with no detriment to content; it breaks a small proportion of webpages, and they are mostly pretty useless ones, too (and you can just turn scripts back on for the few that need scripts). And it blocks a lot of tracking and bad ads and privacy/security risks, and slashes your bandwidth requirements and browsing carbon footprint. Nonetheless, I doubt most people in the developed world use a browser firewall to block loading of useless-to-the-user content. So I'm not expecting that most new internet users in the developing world will do that. Also, most browser firewalls can't be installed on smartphones, the favoured way to access the internet in the developing world.
Live-updating text as annoying movement in one's peripheral vision is a completely separate issue, and one some people won't care about. I'd prefer not to have it.
I'd also like the edit summary above the preview, as when it's below, I'm more likely to forget to fill it out.
> On the carbon-emissions issue, what matters is really the aggregate effect across all users, which may be fairly negligible, but we must have the A/B data to tell by now.
While people definitely look at reducing bandwidth usage, cutting features for the sole purpose of reducing carbon is not a good long term strategy. Technology moves fast and it is way more efficient to squash bytes on the 'big stuff' (new types of compression, http2 and http3 usage etc) than choosing to remove functionality that most people expect. Because the best CO2 usage is no website at all (and no computer at home to browse a website for that matter).
> If you are on a 56 kbaud connection
Opening Wikipedia as an editor on a 56kbaud modem should take about 2 minutes to load a single page (1,5 MB). I have trouble believing editors actually use 56kbaud connections to edit. If they are, this won't be many users, and they are already used to having lots of problems with websites.
> This may be due to latency and intermittent signal degredation and lousy error handling
It is. And where found, it should definitely be fixed. But even if it fails, that doesn't necessarily create much impact in this particular case. You'd just get 1 fewer preview.
> Even on a very fast fiberoptic connection, turning off scripts makes a large proportion of webpages load noticably faster
It does, but that doesn't require anything from the website to be achieved.
> turning off scripts makes a large proportion of webpages load noticeably faster, with no detriment to content;
"no detriment to content", seems to me like a very personal judgement call that many people would heavily disagree with.
> I'd also like the edit summary above the preview, as when it's below, I'm more likely to forget to fill it out.
With the current position it is just as close to the submit button, which you will always need to progress right ?
I'm not convinced personally. The only thing I would say is that it might be wise to have a mode, which detects that rendering takes very long (more than a second say) and then automatically disable auto previewing. I'm pretty sure that we have that functionality in another component (the new realtime preview ?). I think that would make sense, especially for ppl on unstable or very slow connections. That will work automatically, which seems much more user friendly to me.
I entirely agree that it's worth emitting carbon for useful features. I don't actually want to cut a feature; I just want to be able to click on the word "Preview" and toggle it on and off. I've maybe been insufficiently clear; I personally find continuous preview actively undesirable, though I can see it has utility, especially for new editors learning markup. I don't want it removed; I would favour adding a side-by-side live preview option to article-space editing, though I don't think I would use it very often myself.
I've read Wikipedia over a voice-width channel. It is indeed patience-demanding (not loading images helps), and I don't think I've ever tried to edit that way; at any rate I doubt I've edited much. Mostly, I've used uneditable offline copies: Kiwix and, before that, CDs. I'd agree that we probably have few editors on very slow or expensive connections, and they would have low expectations for functionality from most websites. I did read of an offline Wikipedia editing project that sneakernetted Wikipedia contributions and manually merged them, so there must be some unmet demand; half the world's population is offline, and a lot of offline people read Wikipedia content. I've taken an interest in asynchronous editors, but nothing has emerged; I should perhaps write a simple one for this usecase.
For reading text-based content, which is a lot of what I do online, I personally find that turning off scripts and occasionally enabling (usually only first-party ones) on an as-needed basis mostly removes the ads and tracking. The most frequent problem is accordions that don't default to unfolded if there is no Javascript (on Wikipedia, the big thing I like about scripts is popup citations). You're quite right that most people don't use the internet that way, and probably many wouldn't want to even if they knew how. But this is by-the-by; my poorly-made point was that new internet users will use the default settings. A default that disables the preview on slow connections sounds great, and very user-friendly for that use case, much more so than my toggle suggestion.
...but it doesn't solve my/Nikki's problem, that we don't like the live preview and want to turn it off.