Talk:Talk pages project/Replying

About this board

The team would value any thoughts and/or questions you have about this new tool for Replying to specific comments on talk pages.

Parts of the text are erased or scrambled

4
85.250.228.85 (talkcontribs)

I tried this feature several times. It works great for short texts, but when writing a long reply parts of the texts sometimes disappear completely or get scrambled. This can he very frustrating. I use the feature in the Hebrew Wikipedia. Thanks and cheers, Ithamar 85.250.228.85 17:33, 18 July 2022 (UTC)

Whatamidoing (WMF) (talkcontribs)

Are you using the "visual" mode, or the wikitext "source" mode?

HLHJ (talkcontribs)

I got this today in "source" mode (without special chars installed, vanilla installation, writign in plain English). When I tried to paste the title of a WP article for a wkilink, it pasted the formatted title, complete with font and underline, and then the editing field messily and stopped being editable, with deteriorating function. I tried switching to visual mode and back; I couldn't switch. It also looked as if it had lost some of my text, which I copy-pasted back from the unchanged preview. But then the text shifted and it was pasted in the wrong place... In the end I saved it and edited the comment in a seperate edit.

I have previously had intermittent problems copy-pasting into the reply field from other tabs, including from the HTML and from the URL bar. Since I do this all the time, it's very noticable. I paste selections with middle-mouse-button clicks and CTRL-C CTRL-V, and both would not-work simultaneously.

I also often copy-paste from earlier posts to the talk page. I'd like to convert such pasted text to wikisource without prompting when I'm using the source editor; the delay is long even without the pop-up. The most common think I copy-[aste is a username of someone I"m replying to; I've noticed that I have to include a non-marked-up character before their wikilinked username (i.e. " WhatamIdoing") in order to get the option of pasting the linked name instead of plain text. This one is reliably reproducible.

Whatamidoing (WMF) (talkcontribs)

Does this problem seem to appear after copying and pasting? See phab:T319090 for some links to previous bug reports. Also, do you have the GoogleTrans gadget installed? Do you have this problem in safemode?

Reply to "Parts of the text are erased or scrambled"
MB (talkcontribs)

This feature works on a diff listing. After replying on a diff listing, can/should it reload the page itself and not just the diff listing? I think I would prefer to see the page, but perhaps others would prefer to continue to see the diff listing so they can make further replies.

TheDJ (talkcontribs)

What is a diff listing ?

MB (talkcontribs)
TheDJ (talkcontribs)

So you mean just a diff. Presumable a diff, with preview mode enabled ? You are making a reply on that page, and then it refreshes the diff, but not the preview ? Or rather I guess, you see the same diff, with the same preview, and not the later revision that you have just created I guess.

Honestly, I wonder if previews of diffs shouldn't even have reply links...

MB (talkcontribs)

I'm not sure what you mean by "preview mode enabled". If I open a diff listing (commonly by clicking on (xxx changes) on a watchlist entry, I see the changes that were made to the talk page. The reply tool works on this diff listing and I am able to add to the discussion. I see my new comment on the page. So what I am seeing at this point is not really the diff between the versions listed at the top anymore, it is the diff listing I had been looking at with the new comment appended. If I reload the page with the browser reload, the new comment disappears.

It is convenient to be able to reply on a diff listing. but it can lead to confusion also. Sometimes, I do a browser reload to see if there have been responses to my reply, and of course that doesn't work because the url is set to the diff listing, not the "live page".

Perhaps, as you say, "previews of diffs shouldn't even have reply links"

Tacsipacsi (talkcontribs)

I'm not sure what you mean by "preview mode enabled".

There’s a setting on Special:Preferences#mw-prefsection-rendering-diffs labeled Do not show page content below diffs. The default is disabled, so most users probably don’t even know about it.

If I reload the page with the browser reload, the new comment disappears. […] Sometimes, I do a browser reload to see if there have been responses to my reply, and of course that doesn't work because the url is set to the diff listing, not the "live page".

It depends on how you open the diff. Most on-wiki diff links contain the revision ID of both the “before” and the “after” revisions, so they indeed don’t contain changes made after the link has been generated. Links in notification emails, however, contain a special diff link that ends with diff=0&oldid=123456123456 is of course a made-up revision ID and is substituted with the actual revision ID of the “before” revision, but 0 is literally a zero, and means “the latest revision at the moment the page is loaded”, so if I press F5, I see my own comment as well as any eventual replies to it. This is probably a workaround for the fact the link is clicked potentially much later than it’s generated (and thus new edits may happen during this time), but it has the side affect that reloads behave differently (which may or may not match the user’s expectations). These are not some black magic, such links could be generated on-wiki as well, for example using gadgets/user scripts. Actually, there’s one on-wiki place where such links are generated (in this case probably for performance reasons): the diff-to-current links on non-diff old revision pages like https://www.mediawiki.org/w/index.php?oldid=123456. (N.B. There are reply links even on this page, although reloading would clearly not work. The links don’t work as these comments have been archived since, but they would if DiscussionTools could find the comments in the latest version.)

Perhaps, as you say, "previews of diffs shouldn't even have reply links"

I’m strongly against removing the links from diffs. As I mentioned above, in some cases there’s no confusion, but even in others having to navigate to another URL to be able to reply makes one of the core values of the reply tool (being able to reply quickly) less true. Maybe there could be a warning within the tool or after posting that informs the user if the issue is really present (i.e. old revisions without diffs and diff views without diff=0).

Reply to "Reply on diff listing"
Rita2008 (talkcontribs)

Manche Diskussionen sind so lang, dass die Antworttexte immer weiter nach rechts rücken. Das kann dann unübersichtich werden. Es wäre gut, wenn es die Möglichkeit gäbe, wieder ganz links mit dem Schreiben der Antwort zu beginnen.

Reply to "Nach links rücken"
Summary by আফতাবুজ্জামান

Resolving as it is fixed on Mediawiki software.

আফতাবুজ্জামান (talkcontribs)

This is not a bug. Please help me to find it.

Please see this. It says ১ ঘন্টা আগে (1 hour ago). Here spelling for ঘন্টা (hour) is wrong, should be ঘণ্টা Q: Where does it coming from? I was unable to locate it on translatewiki.net.

Matma Rex (talkcontribs)
আফতাবুজ্জামান (talkcontribs)

Thanks. I will file a request. Last time i filed a request, it took a year to fix. I also asked/emailed Nemo bis for an account but never got any reply :/

আফতাবুজ্জামান (talkcontribs)
Matma Rex (talkcontribs)
Matma Rex (talkcontribs)
আফতাবুজ্জামান (talkcontribs)

Thank you. Yes, all the spelling are correct.

Missed special chars.

15
Summary by PPelberg (WMF)

T249072: Add support in toolbar for special characters within DiscussionTools

Dušan Kreheľ (talkcontribs)

The tool doesn't have a special char box with example "–", "€", no-break space or another.

PPelberg (WMF) (talkcontribs)

hi @Dušan Kreheľ – you're right. Currently, the Reply Tool does not offer the special characters box/toolbar that the VisualEditor offers.

Can you please share how not having access to the special character box/toolbar within the Reply Tool has impacted you? Asked in another way: can you share what you use the special character box/toolbar for in the VisualEditor?

Dušan Kreheľ (talkcontribs)

@PPelberg (WMF): I like using:

  • "–" – Dash
  • " " – No-break space

plus in Slovak:

  • "„“" – Quotation mark
Whatamidoing (WMF) (talkcontribs)
Dušan Kreheľ (talkcontribs)

It would be maybe nice. But for me as a programmer, it's not an obstacle to use the "reply" tool.

It might be good to have statistics at the earliest what characters users use.

Ping: @Whatamidoing (WMF).

Whatamidoing (WMF) (talkcontribs)

Presumably that would depend on which language they were writing in. Amire80, has the Language team ever looked into this question (which characters are most used, or most needed-but-missing)?

Aaharoni-WMF (talkcontribs)

No, we haven't looked at it systematically.

HLHJ (talkcontribs)

Ouch. As someone who edits in diacritic-ridden languages, mostly using an English-optimized keyboard, that could make it more difficult for me to write non-English replies. I've had long discussions in French on Commons. This is also a problem offwiki. I have non-WP-specific tools that give me diacritics and special chars for the scripts I write in (including IPA), but on-wiki I often use the intenal tools for proximity. I wish compose keys worked reliably, it would make code-switching far easier.

Could this be done using " Alt-Shift-S for 'Publish' "-like keyboard shortcuts (see topic above)?

Whatamidoing (WMF) (talkcontribs)

I believe that they're hoping to add the visual editor's special character palette to the [reply] tool in the coming weeks/months. If you'd like to have a look at it (NB the first section varies per wiki), then try adding lines 7–15 from m:User:Whatamidoing (WMF)/global.js to your own global.js page. (And then make a note to take those lines back out in a few weeks, so you don't end up with two of them.)

Dušan Kreheľ (talkcontribs)

@Whatamidoing (WMF) Widget ok. Design: If he scrolls down the page, there is a border on the right side of the widget. Let there be a border between the widget and the text, and it will also match the slider placed opposite.

Whatamidoing (WMF) (talkcontribs)

I think NAyoub (WMF) will be interested in this detail about the borders.

HLHJ (talkcontribs)

Thank you, WAID, I've added that scriptbit. Unlike the original, I can select one "language" submenu and then scroll to another (i.e. selection "Latin" or "Often used" and scrolling to "Runes"), which was a bit unexpected and caused me momentary confusion.

This user interface might be worth looking at as a way to improve access to special chars; it chunks the special chars, which takes advantage of the fact that an editor will usually want only German special chars, or French ones, or IPA ones, or logic-symbols-related ones. It's a lot faster.

Relatedly, selecting "[underlined "A"]>Language" inserts this text: <span dir="ltr" lang="de">Language</span> I'm not sure what this is for. On en-wiki, there are "lang" and "transl" templates, which do left-to-right or right-to-left as needed.

Dušan Kreheľ (talkcontribs)

@HLHJ: We don't have the global template. Next way, know the user about this extra template? Use the extra addon?

HLHJ (talkcontribs)

The Croatian and Slovak Wikipedias do not have "transl" and "lang" templates? The reply tool could do different things on different wikis.

I don't speak Slovak or Czech, regrettably. I speak German; you can answer me in German, if you like.

Whatamidoing (WMF) (talkcontribs)

The "Language" item adds the HTML markup for the language you're writing in. Dann weiß mein Computer, dass ich diesen Satz auf Deutsch geschrieben habe.

It is very similar to Template:Lang, except that it works at 100% of the wikis, and not just the ~50% of wikis that have the template locally.

Reply to "Missed special chars."

Thanks link

5
Summary by Whatamidoing (WMF)
HLHJ (talkcontribs)

Could there be a thanks link next to the reply link, as on this page? New editors often have trouble finding the thanks facility, and even for experienced editors, it's slower to go to the history page and thank. This would save time visiting pages and reading messages which are purely thanks.

Leonaardog (talkcontribs)

Thank you!

Tacsipacsi (talkcontribs)

It’s already being (not very actively) worked on, see phab:T249893.

Omotecho (talkcontribs)

In jawp, I will appreciate Thanks button very much personally . As in my view and focusing on ja community.

  • it will be a wise tool which will calm down experienced editors when they don't be replied by Junior editors: not like SNS, you don't know if your advice is perceived or not.
  • Another gap a Junior/less than 500 edit history not aware yet of, or often times long term editors tend to forget: they say it's a protocol to reply thanks, but that is not very popular among beginner editors to thank ASAP you read and understand an advice;
  • elders (in age) think it's applicable anywhere in your life on/off wiki.

Are we not ignoring another unwritten but shared knowledge among senior/long-term editors, if limited to particular language community(ies). And IMHO I wish you need not to learn wiki-manner (local) after many wounds by getting scolded/ridiculed you are bad-mannered. /:

Thus, I wish we have thanks button as one remedy, among many, for enhancing friendlier and welcoming exchange of help. (with thanks to (@HLHJ's input, updated as my view could be bound with local culture.~~~~~) Cheers,

HLHJ (talkcontribs)

Long long ago (on English Wikipedia, before 2013), there was no thanks button. If you wanted to thank someone, you had to type a message. Also there were dinosaurs (they went extinct before the 2020s). I do not think it is impolite to not use the thanks tool. But saying thank-you is polite, and the thanks tool makes it faster for the thanker and thankee both.

Reply to "Thanks link"
LittleGun (talkcontribs)

I think the new added "stats" header [Latest comment: för 12 år sedan| 2 comments| 2 people in discussion] disturbs the reading of discussions: It creates an extra grap between header and first actual topic, and it is meta-information that I cant see is normally relevant in an normal discussion flow. It could be added to the "advanced" flipout tab after clicking "reply" instead, as a quick link to the interested of such stats. Or as a advanced setting, but not "forced".

PPelberg (WMF) (talkcontribs)

hi @LittleGun – I appreciate you coming here to share the feedback you have about the new section heading styling (we're calling them "Topic Containers") that became available as a Beta Feature at more wikis yesterday.

Two questions in response to the feedback you shared above:

  1. What – if anything – do you find helpful about the "stats" that appear beneath level 2 section headings?
  2. Were you aware, before me asking this question, that you are able to disable the "new added stats header" by turning off the "Show discussion activity" setting that appears within Special:Preferences?
LittleGun (talkcontribs)
  1. Not much. I go to a discussion page to a) start a discussion, then I scroll through the old ones first to see if it the subject have been handled. That gives me a good view of how many have discussed and when, b) to check out a discussion I see happening or are pinged to, then I want to check the topics comments before answer and get a good view before I answer. If I want to check latest and so on I go to the history tab. Maybe, some isolated time, the topic container could alert me that someone have added a comment in an older thread. That is it, and it is not very often (if ever) I need to know that but it would save me the time to go to history tab. At all other times the unwanted information creates a space separating the heading of the topic from the topic.
  2. No, I did not know that. However, I want to work with and help beginners. To me it is important not to mess with the skins settings too much, because then I will not know their experience or understand their questions. So it is all good that these settings can be adapted for each individual, and I know most settings can either through settings or just to ask people that know about scripts. But it is very important the default skin is as adapted to beginners as possible and is as basic as possible. And they have enough trouble finding edit buttons and editing tools, and is not helped by this meta data in such prominent position, at their first steps replying in a discussion.
PPelberg (WMF) (talkcontribs)

@LittleGun thank you for following up with me! Responses below. Please let me know if anything I've said here brings new ideas/questions to mind.

Not much. I go to a discussion page to a) start a discussion, then I scroll...

I appreciate you describing the typical workflow you follow when arriving at a talk page. As someone who is practiced with using history pages, and talk pages more broadly, it sounds like the additional information Topic Containers show is going to be more distracting than it is helpful to you for now.

But it is very important the default skin is as adapted to beginners as possible and is as basic as possible. And they have enough trouble finding edit buttons and editing tools, and is not helped by this meta data in such prominent position, at their first steps replying in a discussion.

+1! It sounds like we are aligned in thinking it's important that beginners be able to arrive on a talk page and immediately recognize it as a place where they can communicate with other people and, as you said, find the buttons/tools necessary for them to communicate.

In fact, the objectives it sounds like we share are precisely what led us to include this "metadata" in the first place. The thinking here being that people who are new would intuitively recognize the sections on talk pages as discussions if there was information within the interface that reinforced this idea (e.g. the number of people participating in the discussion, the number of comments, the date the last comment was published, etc.).

I too was mindful of the potential for this additional information to distract people who are new. Although, the usability tests we ran proved otherwise: the beginners who participated in the usability tests both understood the metadata and helped them recognize talk pages as places to communicate.


At all other times the unwanted information creates a space separating the heading of the topic from the topic.

Oh, and so you're aware, we are going to decrease the amount of whitespace between the section heading and the topic. This work is happening in T314449.

I realize what you're saying above is slightly different from the issue the ticket I linked to is meant to address and I thought you would still value knowing that we're still iterating on the overall design :)

Лариса94 (talkcontribs)
LittleGun (talkcontribs)

Ok. Also considering newcomers? Do you mind if you have to turn it on instead of it being default?

I can personally live with it, I can understand some very experienced users like it. For beginners it is uneccessary information, causing distraction. The Vector 2022 aim to hide as much as possible, in the reply feature after clicking reply most things are hidden under menues and cryptic icons. Here we should do the opposite. What is the justification?

Лариса94 (talkcontribs)

Новичкам сложно в начале. Потом разбираются и привыкают. "По умолчанию" позволяет экономить время - не нужно искать нужную строку и считать звёздочки (*), чтобы ответить как положено - "лесенкой". Все просто, как грабли:)) нажимаешь - отвечаешь, @Лариса94

LittleGun (talkcontribs)

Yes, we are all beginners in the behinning. All things can be default to save time (even if its something only done once). So, what is the justification to prioritize an advanced feature creating a disturbing effect?

Лариса94 (talkcontribs)

In my opinion, there is no "disturbing effect" in the new function.@Лариса94

PPelberg (WMF) (talkcontribs)

This is great to hear, @Лариса94!

We intentionally made it possible for people to disable the feature thinking there will be people who favor the existing experience and people who will favor the changes the new feature brings about.

Whatamidoing (WMF) (talkcontribs)

One possibility for this feature is that it will help beginners. Specifically, seeing "Latest comment: för 12 år sedan | 2 comments | 2 people in discussion" could help them think "This is a place for comments and discussion. This is not the place to paste my new article".

LittleGun (talkcontribs)

ok. But, as mentioned before, other improvement projects (vector 2022 or this tool) did not previously want to overinform. So why do this feature so prominent for such advanced information.. If it is to clarify for beginners, a more explicit note would be better than cryptic metadata.

I understand we all have different behaviour and needs, but I was really hoping for a better justification and more thought out reason prior to roll out I will however get used to having the information there and maybe found it useful some time, but I have not yet.

Whatamidoing (WMF) (talkcontribs)

It usually takes about two weeks to get used to a big change. I hope you'll give it a fair trial, but if you decide that you hate it, then the devs tell me that it could be easily hidden with a .css user script.

LittleGun (talkcontribs)

I dont hate it. I will learn to live with it. I cannot see the use. I do not understand why this advanced meta data summary shall be so prominent, when the scope in other changes is to hide as much as possible.

I think you fail to justify this. So I think the CSS should work the other way.

I will not remove it. I dont want to customize too much. Then I wont understand what new users or otger fellow user describe.

Reply to "Header with stats"
Xaosflux (talkcontribs)

Just FYI, phab:T316219 is open about the user-fill component being broken right now.

PPelberg (WMF) (talkcontribs)

Thank you for the ping, @Xaosflux. This issue should be fixed today.

Reply to "Find User Broken"
আফতাবুজ্জামান (talkcontribs)
Matma Rex (talkcontribs)

Hi, the page had some mistakes in the wikitext that prevented the reply tool from working.

I fixed it in this edit:

You can find some guidance about these issues at Help:Lint errors/fostered.

When I type, I see text move below

16
Summary by Whatamidoing (WMF)
Ziko (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

Have you tried switching to the visual mode?

Ziko (talkcontribs)

Ah! Thank you very much!

Whatamidoing (WMF) (talkcontribs)

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.

Ziko (talkcontribs)

Seems to be mostly in line with the Visual Editor. Thanks again!

Nikki (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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?

HLHJ (talkcontribs)

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?

TheDJ (talkcontribs)

> " ~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.

Whatamidoing (WMF) (talkcontribs)
HLHJ (talkcontribs)

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.

Tacsipacsi (talkcontribs)

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).

TheDJ (talkcontribs)

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.

HLHJ (talkcontribs)

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.

TheDJ (talkcontribs)

> 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.

HLHJ (talkcontribs)

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.

Reply to "When I type, I see text move below"