Community Wishlist Survey 2022/Larger suggestions/Less embellishment

From Meta, a Wikimedia project coordination wiki

Less embellishment

  • Problem: Embellishmentosis
  • Proposed solution: Less embellishment.
  • Who would benefit: Everyone reading a Wikimedia page with a Web browser.
  • More comments: Example: "edit source" suffices; remove "edit".
  • Phabricator tickets:
  • Proposer: PeterEasthope (talk) 01:21, 11 January 2022 (UTC)[reply]

Discussion

  • Hello PeterEasthope, thanks for adding a proposal. Could you provide more examples of the Embellishmentosis? We need to know the specifics of what you mean by the label you use. Perhaps this piece of documentation could be useful. Thanks! SGrabarczuk (WMF) (talk) 01:58, 11 January 2022 (UTC)[reply]
    In accord to the documentation.
    > Pick one specific problem and describe it in detail
    Here are two. No charge for the 2nd. =8~)
    (1) Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing.
    "edit" is slow to load and restricts capabilities. "edit source" loads quickly and allows all editing. Visual editing is relatively recent. Before it was added there was only source editing.
    (2) Multiple "skins" are offered. Consider this principle of the Web: the server presents content with minimal imposition of presentation; the client has as much freedom in presentation as feasible. Imposition of skins is unnecessary. Focus on content.
    > Don't worry about finding the solution
    Here are my proposed solutions. Again, no charge. =8~)
    (1) Drop visual editing. Keep source editing.
    (2) Drop the skins. Impose as little style as feasible. If you want to help readers with presentation, offer style sheets which a reader can use according to taste. Ref. https://support.mozilla.org/en-US/questions/1271227 =8~)
    Regards, ... PeterEasthope (talk) 02:57, 11 January 2022 (UTC)[reply]
    "Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing." is a result of your preference/configuration. You can change that in your personal preference according to my understanding. C933103 (talk) 08:23, 17 January 2022 (UTC)[reply]
    In Preferences I found the switch and shut off visual editing. The wording suggests it's temporary for beta. I'd rather it be permanent. Thx, ... PeterEasthope (talk) 05:17, 21 January 2022 (UTC)[reply]
Inescapable question: the work on the visual editor was by volunteers or by paid Wikimedia staff or by paid contractors? Thanks, ... PeterEasthope (talk) 17:04, 21 January 2022 (UTC)[reply]
Accidentally clicking the "edit" link for the visual editor results in a delay while editing is set up. =8~( If the visual editor is permanent, then the configuration switch to turn off the edit link should also be permanent.
Dismissing legitimate concerns as curmudgeonly will only discourage some capable and well meaning people from contributing. Look at what's happened with the Web. Many pages aiming to present simple information are severely burdened with JavaScript. Consequently a bus schedule which might be presented efficiently as a table in HTML5, is bogged with JavaScript. No problem for a contemporary iPhone or Android phone containing a JavaScript ASIC. Yes problem for reading the schedule with an old computer and Dillo. Try Dillo on a desktop machine. If possible an older generic machine. Immediately you'll notice how quickly Dillo opens compared to Firefox. Not a criticism of Firefox. Rather an illustration of the pervasive imposition of JavaScript. The endless push to more complex and resource consuming systems is a grave problem for the biosphere.
Climate change
Environmental degradation
We don't have to play into the hands of mega-corporations. Of all people, Wikimedians should exercise principled autonomy and initiative. Regards, ... PeterEasthope (talk) 16:33, 27 January 2022 (UTC)[reply]
I mean isn't it already possible to disable the visual editing at Special:GlobalPreferences#mw-prefsection-betafeatures?
Currently, yes, in Wikibooks I disabled visual. I hope the personal configuration option isn't dropped. Regards, ... PeterEasthope (talk) 17:53, 27 January 2022 (UTC)[reply]
I recall having to make some special config to get multiple edit buttons? C933103 (talk) 17:27, 27 January 2022 (UTC)[reply]
In Wikibooks, my default was "edit" and "edit source". In Preferences, I switched off "edit". Here I have only "edit" (= edit source). Apparently visual editing isn't available here.
This discussion is itself an example of why I advocate for simplicity. This morning I've spent at least an hour here which could have been spent on editing and writing. Exactly my concern. When a technology becomes established, focus shifts to embellishment with unnecessary complexity. Consequently some of the original value is lost. Illustrated by the Web as noted above. At some point people should recognize success and stop. Regards, ... PeterEasthope (talk) 18:26, 27 January 2022 (UTC)[reply]
Thanks for elaborating, Peter. Of course we should focus on simplicity, a minimum of JS bloat, and the like. It was your final comment about the "inescapable question" that struck me as unhelpful. The visual editor has increased the # of people I've successfully gotten to edit many times over, and was the most-requested feature by non-editors in the years leading up to it. –SJ talk  03:24, 28 January 2022 (UTC)[reply]
'... most-requested feature by non-editors ...'
Fair enough but please leave a permanent option for visual vs. source editing preference. As mentioned, inadvertently choosing visual wastes time. Might be only 20 seconds but a distraction nevertheless and seconds add up. The principle of "user centered interface", familiar to Mac users, is significant. A user should be presented with only pertinent and significant information. If a user uses only one of the two edit interfaces, there is no need for two edit links. It's a matter of psychology. Less can be more.
'...comment about the "inescapable question"...'
Accountability may be embarrassing but is necessary where a cooperative effort is aimed to a result. Without accountability efforts go astray. A harsh reality.
Regards, ... PeterEasthope (talk) 15:34, 28 January 2022 (UTC)[reply]

┌─────────────────────────────────┘
After writing the preceding sentence I happened to the read the "Wikipedia has Cancer" essay by Guy Macon. Disturbingly congruent to my concerns. Any donor should be seriously concerned about the noted refusals for financial accounting. The scenario of bankrupcy and acquisition by a mega-corporation is gravely disturbing. Exactly the fate of Mountain Equipment Coop, started in Vancouver by a group of outdoor enthusiasts. For several decades a wonderful success. Then it began to grow like a mushroom, opening stores across the country. Opposition to the growth was met with stonewalling. =8~| No problem for a few years. Then the economy shifted. MEC became bankrupt and was forced to sell assets to a private interest. I really don't want Wikimedia to fall to the same fate but, without accountability, that might be inevitable. =8~( Regards, ... PeterEasthope (talk) 15:42, 29 January 2022 (UTC)[reply]

Valerio Bozzolan> Comment "Please invest more than 1 minute in writing a good proposal."
Before I attempt to rewrite the proposal please make one specific criticism or ask one specific question. The meaning of "less embellishment" is clear. I gave two examples. An alternative statement in one word: simplify. Sorry to resort to a flippant cliche but what part of simplify is not understood?
> "The world is watching this conversation."
Encouraging although authorization of a change and implementation are controlled by a few people. If the authority doesn't support a proposal, it won't progress. Hypothetically, the board of directors has ultimate authority. The board can advance an interest or delegate to paid staff, few of which will support a proposal limiting employment. In any case there is risk of benefit to interests of a relatively small group of people on a relatively small time span. As noted above, the analogy to MEC is frightful. =8~(
Incidentally, the absence of an answer to my "inescapable question" suggests exactly one explanation: the answer is too embarrassing to state.
Regards, ... PeterEasthope (talk) 15:50, 13 February 2022 (UTC)[reply]
A third simplification, additional to the two above.
(3) For some links to articles, hovering the mouse pointer on the link gives a small preview of the article. I question the worth of the preview. In a page containing a high density of links, just moving the pointer across the screen can produce several unwanted activations. Every unwanted activation is a distraction and delay. Rather than use computational resources for preview, simply open the full article with a click. In absence of a click, do nothing. If previewing must remain, make it optional; provide a option to shut it off. Wirth's dictum again: resouces needn't be consumed merely because consumption is possible. PeterEasthope (talk) 16:57, 13 February 2022 (UTC)[reply]
@PeterEasthope: I'm on your side, but if the proposal is poorly written, the proposal readers (lot of people) invest too much time to understand how to help and sustain you, resulting in no one being able to support you. If you think that «Embellishmentosis - Example: "edit source" suffices; remove "edit".» is a good proposal, I thank the six people who put +1 understanding what you wanted. I didn't get it. Valerio Bozzolan (talk) 09:45, 14 February 2022 (UTC)[reply]
Another question which might help: what fraction of readers in Wikipedia adjust their Preferences? Thanks, ... PeterEasthope (talk) 15:33, 15 February 2022 (UTC)[reply]

Voting