Community Wishlist Survey 2022/Mobile and apps/Option to select non-Javascript editor on Mobile Web

Option to select non-Javascript editor on Mobile Web

  • Problem: If a user want to edit Wikipedia through mobile version of Wikipedia, there are currently two version of editors available: the standard one for mobile web browser, as well as a clear one that will be displayed when the JavaScript function of the user's web browser have switched off the JavaScript function of their browser or for the Wikipedia site.

The default web editing is a dynamic one based on Javascript, hence it create a number of problems:

  1. It's slower than the non-Javascript version especially on slower internet
  2. When users switch between browser tabs or apps for reference to edit Wikipedia article, there exist chance that the Wikipedia editing page will be cleared away from device RAM, making reload of the page necessary. And edits in such dynamic mobile editor could not be conserved after reloading the page, unlike the simple non-JavaScript editor.
  3. Pre-filled forms, like this community wishlist submission form, would not be accessible from the default Mobile Web editor.
  • Proposed solution: Add a switch that allow user changing their preferred editor interface on mobile web.
  • Who would benefit: Any users, who edit on mobile web browsers.
  • More comments: This is a re-submission of entry from 2019 Community Wishlist.
  • Phabricator tickets: phab:T205778
  • Proposer: C933103 (talk) 03:23, 17 January 2022 (UTC)

Discussion

  • "It's slower than the non-Javascript version especially on slower internet" I seriously doubt this, if anything its faster as you are not loading a separate page for the editor. But it is less reliable perhaps like you indicate in 2 and 3. —TheDJ (talkcontribs) 16:27, 19 January 2022 (UTC)
    This point was taken from feedback among respondents from last community wish submission. I do not regularly access internet over like GPRS/ADSL/satellite in person to say for sure the slower speed is actually a consequence of the connection itself, as come to think about it the slower perceived could also be a result of the mobile device needing more computational resource hence time to handle/process/render the JavaScript editing interface than a simple textbox? C933103 (talk) 21:47, 19 January 2022 (UTC)
    Most likely this is perception indeed. The JS editor just puts up a spinner while it loads. When you click a normal edit field, you might have to wait for the response of the server, but since users are familiar with that, they ignore it. —TheDJ (talkcontribs) 00:43, 20 January 2022 (UTC)
    Humm, indeed. I tried editing the first section of "5G" article on English Wikipedia over my mid-range Sony Xperia 10 III smartphone through Wi-Fi tunneling via VPN on Chrome in Android 11, and the Javascript editor finished loading in less than two seconds while the non-JS one took more than three seconds to finish loading, after repeated round of tests. So this invalidated that rationale which I will strike out, although other reasons for such wish still exists.
    But if the animation is at fault for making people feel slower, then isn't it performing against what the animation supposed to be doing? I guess it is a deficit that need to file a bug report for on the phabricator? (Also, to anyone facing the same issue, I just found out the version of Mobile Chrome I use - 92.9.4515.159 - allow per-site control of enabling/disabling of JavaScript, which in turns can be act as a band aid fix to force the non-JS editor option on mobile wikipedia site, to anyone using the same browser and same platform as described.) (Edit: submitted to phabricator: phab:T299658.) C933103 (talk) 11:49, 20 January 2022 (UTC)
  • Question: is there something I can tack onto the URL to access the no-JS editor? Pelagic (talk) 23:30, 28 January 2022 (UTC)

Voting