Wikipedia

Wikipedia:Requests for comment/2020 left sidebar update

< Wikipedia:Requests for comment
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
This was a very wide-ranging RfC, with dozens of individual discussions and questions. There are a few specific issues that need further discussion in order to be implemented or to find a consensus.
  • We found consensus to add a link to an "introduction to contributing" page, but there is no clear consensus regarding elements including, what page should be linked to, what label text should be used, its placement on the sidebard and what the tooltip should be. A follow-up discussion or RfC should be held to establish this consensus.
  • We found consensus to change the tooltip for the Community portal link, but there is no clear consensus regarding what the new tooltip should be.
  • Owing to low turnout, further discussion is needed regarding any change to the tooltip for the current events page's link.

We have included individual closing statements for each of the discussions below. In total, we found consensus for the following link changes (not including labels and tooltips):

  • Adding a new contribute section
  • Moving "print/export" above "tools"
  • Adding a link to an introduction page
  • Removing the links to featured content and the wikipedia store

Submitted by:

Barkeep49 (talk) 02:31, 4 June 2020 (UTC) • DannyS712 (talk) 03:08, 4 June 2020 (UTC)[reply]
Shortcut
An annotated version of the Wikipedia Vector interface as a logged-out user, with the main sidebar at left

This RfC consists of a series of independent proposals to modify the sidebar located on the left side of every page in the desktop default skin view of Wikipedia (encoded at MediaWiki:Sidebar), aimed at improving usability and ease of navigation.

It is being launched and listed on the centralized discussion template (among other places) following a half-month incubation period at the Village Pump Idea Lab.

You may participate by !voting in the polls or contributing to the discussion section under each proposal, or by adding new proposals. Refactoring may be done as needed to keep this RfC organized. – {{u|Sdkb}} talk 21:46, 10 April 2020 (UTC)[reply]

Background

edit

The content of the left sidebar has changed remarkably little since the mid-2000s, despite the many advances in web usability best practices since then. In fall 2013, Steven Walling (ret.) launched an RfC proposing a major overhaul. The close (by Keithbob) noted that All participants seemed to agree that the sidebar's content, design and appearance could be improved but that there was a wide variety of suggested changes none of which appeared to have universal support, so no changes were implemented. Since then, only minor changes have been enacted, such as the removal of the "create a book" link last December.

The 2013 RfC articulated the following principles, most of which are copied here given their continued applicability:
  1. Even compared to other pieces of site-wide navigation, the sidebar is an extremely important navigation tool. With the vast majority of readers and editors using a skin (Vector or Monobook) with the sidebar placed on the left, it is in a natural position of importance considering English speakers tend to scan left to right.
  2. The sidebar is currently cluttered. On the Main Page, English Wikipedia readers see 22 linksin 2020, it's 21, not including language linksor "In other projects" links. Basic usability principles tell us that more choices increases the amount of time users have to spend understanding navigation (see Hick's law), and that simplicity and clarity are worthwhile goals. The most recent design of the homepage of Google.com, famous for its simplicity, has half the number of links, for comparison. While removing some semi-redundant links (like Contents or Featured contents) would be preferable, if we're going to have this many links it means prioritization is key, leading to the next point...
  3. The sidebar has poor prioritization. Users read top to bottom, and it is not unfair to say that the vertical order of the links should reflect some basic priority. However, currently, this prioritization is sloppily done. Even if we assume all the current links are important and should stay, the order needs work.
  4. The names for some links are overly verbose or unclear. Brevity is the soul of wit, and of good Web usability. We should not use two or three words where one will do.

Monthly pageviews of the links in the sidebar typically range in the hundreds of thousands. The ongoing Desktop Improvements Project being undertaken by the WMF may result in future changes to the user interface on all Wikipedias that could affect the sidebar, but it is not focused on the contents of the sidebar, so should not conflict with the proposals here. – {{u|Sdkb}} talk 21:46, 10 April 2020 (UTC)[reply]

Reorderings

edit
edit
Consensus in favor of the proposal with the amendment that special pages be placed under tools. Barkeep49 (talk) 01:40, 4 June 2020 (UTC), DannyS712 (talk) 02:51, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current Layout Proposed Layout

Interaction

Tools

Print/export

  • Download as PDF
  • Printable version

Contribute

Tools

  • Page information
  • Wikidata item
  • Permanent link
  • What links here
  • Related changes

Print/export

  • Download as PDF
  • Printable version
  • Cite this page

This proposal changes the ordering of the sidebar links in the manner shown at right. Only a section is renamed, and no links are added or removed. The "In other projects" and "languages" sections are ignored in the previews.

The main rationales here are to improve prioritization (by placing important links high up) and categorization (by placing links in more intuitive places, grouped with other similar links). For prioritization, important links like WP:About are moved up. For categorization, the vaguely-named "interaction" section is renamed to the clearer "contribute", and universal editor-focused links are consolidated there, while page-specific editor-focused links are consolidated in the "tools" section. Reader-focused links are consolidated in the top ("navigation") and "print/export" sections.

Survey (Contribute section)

edit

Discussion (Contribute section)

edit

I note that the "Tools" section and everything below it is defined directly in the software, rather than being defined by MediaWiki:sidebar -- how do you plan to implement this? * Pppery * it has begun... 23:38, 10 April 2020 (UTC)[reply]

@Pppery: I'm not a technical expert, so I won't be the one doing the implementation. If it's defined in the software, some assistance from WMF might be needed (the folks at the WMF Desktop Improvement Project are aware of this RfC). I think the best course of action is to establish what the community consensus is here first, and then figure out implementation subsequently. {{u|Sdkb}} talk 23:51, 10 April 2020 (UTC)[reply]
If we're going to establish community consensus first and figure out implementation later, then I propose adding a link to the sidebar that, when clicked, will send the user a million dollars. :-) Levivich [dubious – discuss] 00:11, 11 April 2020 (UTC)[reply]
This is a terrible idea and obviously a joke, but it's still a better use of funds than the Fram ban or the upcoming rebrand. —pythoncoder (talk | contribs) 00:37, 13 April 2020 (UTC)[reply]
SGrabarczuk (WMF), if there is consensus here, would you or someone else at WMF be able to assist with implementation? {{u|Sdkb}} talk 05:05, 11 April 2020 (UTC)[reply]
This would be a great use case for phab:T249673 I think DannyS712 (talk) 06:31, 11 April 2020 (UTC)[reply]

How is this meant to work in other skins like Timeless?

  • View this page in the skin:
  • View Funabashi (city) in the skin:

- Evad37 [talk] 01:00, 11 April 2020 (UTC)[reply]

Timeless skin sidebars
Current Layout Proposed Layout
Left sidebar Right sidebar Left sidebar Right sidebar

Navigation

  • Main page
  • Contents
  • Featured content
  • Current events
  • Random article
  • Donate to Wikipedia
  • Wikipedia store

Interaction

  • Help
  • About Wikipedia
  • Community portal
  • Recent changes
  • Contact page

Wiki tools

  • Upload file
  • Special pages
  • Cite this page

Page tools

  • Move

More

  • What links here
  • Related changes
  • Permanent link
  • Page information
  • Wikidata item
  • Page logs

Print/export

  • Download as PDF
  • Printable version

Languages

(...list of languages...)

In other projects

(...list of projects...)

Categories

(...list of categories...)

? ?
Note: Combined into one sidebar, or split into collapsed menus, for smaller screen sizes – see screenshots
@Evad37: This is a proposal for the default Vector skin (which I'd assume is used by 99% of desktop visitors). Whether/how to update Timeless is a separate discussion, and one that wouldn't need such widespread input. There are some things I like about Timeless, but my understanding is that a proposal to make it the default was rejected a while back. {{u|Sdkb}} talk 01:12, 11 April 2020 (UTC)[reply]
Apologies, I missed that the top section said it was for the default skin only. Still, if there is consensus, then other skins do have to be considered in the implementation details, lest we end up with duplicated links or missing links in the non-default skins. - Evad37 [talk] 01:27, 11 April 2020 (UTC)[reply]
I have removed the inaccurate notice in the top section that states this only impacts the default skin only. Any changes to Mediawiki:Sidebar are sitewide and impact all skins that include a sidebar; the only skin that would not be impacted would be Minerva (mobile). I am not sure what the notice was intended to indicate, and have no opposition for a corrected notice to be re-added. It felt inappropriate to leave the notice and await further discussion when it gave inaccurate information during active voting. ~riley (talk) 05:18, 11 April 2020 (UTC)[reply]
@~riley: I was going off what Sdkb wrote just above here. Sdkb, can you clarify? If this proposal is to affect other skins, that should be mentioned in the top section instead of just saying Vector, and my query about what is proposed for other skins like Timeless is relevant. If not, can the removed notice or something similar be restored to the top section? - Evad37 [talk] 14:25, 11 April 2020 (UTC)[reply]
@Evad37 and ~riley: I'm not a technical expert when it comes to skins, so someone else can probably provide better clarification. My intention is for Timeless to be unaffected as I stated above, and I wasn't the one who added the notice to the top. Given that Timeless already moves some links around (e.g. "upload file" is in a separate tools section than "page information", unlike Vector), I assume that its creators have at least some flexibility and could choose to either mirror the relevant changes to Vector proposed here or stay the same. - {{u|Sdkb}} talk 17:43, 11 April 2020 (UTC)[reply]
@Evad37 and Sdkb: To be clear: Anything on this RfC that involves changing the top sidebar (Main page, contents, featured content, etc) and the interaction sidebar (Help, About W, community portal, etc), as listed on Mediawiki:Sidebar, impacts all skins. Based on that, 95% of what I am seeing in this discussion impacts all skins. Any references that say "proposal for default Vector skin" or for "default desktop skin" are incorrect and misinforming voters. Those disclaimers can go into individual sections (i.e. if voting on changing the "Tools" sidebar in Vector) if needed. Please make these corrections sooner than later as this is an open RfC. ~riley (talk) 19:02, 11 April 2020 (UTC)[reply]
I too am concerned about any impact on Timeless. Pinging Isarra who is the main magician behind that excellent skin. Oh, Evad37 has notified them on their talk page, please consider the ping as a mention not a summon. Pelagic (talk) 20:54, 20 April 2020 (UTC)[reply]
Note split into collapsed menus at the bottom of that table. I see now that medium-width Timeless (tablet in landscape mode) has four drop-downs for Navigation, Wiki tools, Page tools, and Other projects; in narrow layout (portrait mode) they are icons and the latter two are below the red line. Only Navigation draws from Mediawiki:Sidebar, I guess the others are coded in the skin somewhere and shouldn't be affected by this RFC (see #Technical underpinnings). It does give us a good precedent for separating Page tools from Wiki tools (and using those names) as discussed elsewhere on this page. Aside: This digression on Timeless deserves its own section, but I don't want to relegate it to the bottom of the page where it will be seen less. Pelagic (talk) 21:38, 24 April 2020 (UTC)[reply]
How this would actually affect Timeless would very much depend on how you intend to make the changes. Timeless takes the core sidebar as part of the assembled array of all the navigation, and them sorts the contents into its own arrays in order to do the multiple sidebar blocks and cactions and whatnot, so if the changes are intended to be to that array, Timeless is likely to not even be affected, beyond the MediaWiki:Sidebar stuff. Other than that, I don't even know. There's a lot going on here. -— Isarra ༆ 21:40, 28 April 2020 (UTC)[reply]

Apologies if this is the wrong section for this comment. I think the proposal looks great. The one thing that stood out to me was putting "Cite this page" under "Print/Export" (whereas it seems to fit quite naturally as a page tool). Curious what your thinking there is? Also, it might make sense to rename "Tools" > "Page tools" so it is more explicit, especially to let people know that those tools are specific to that page. AHollender (WMF) (talk) 14:09, 14 April 2020 (UTC)[reply]

I tend to use BibTex so when I think of citations I do think of exporting the citation rather than looking for a citation tool, though I appreciate that I am likely a minority. In that sense, I prefer "Cite this page" as an export method rather than a "Page tool". — Wug·a·po·des​ 21:25, 14 April 2020 (UTC)[reply]
@AHollender (WMF): My thinking with that is that citing a page is something a reader might want to do, so it should go in a reader-focused section, whereas tools is an editor-focused section. Print/export is the section for reader-focused page-specific tools, and it's our good fortune that this can be added there without needing to change the section name. Regarding the name of the section, I think both your suggestion and Wugapodes's suggestion of "editor tools" would be an improvement over the status quo. I'll start a new renaming section for a fuller discussion on that. {{u|Sdkb}} talk 07:36, 15 April 2020 (UTC)[reply]
  • Seems like "cite this page" was sort of just slipped in to the mockup in this section, but there was no mention of it above. Citing isn't about "printing and exporting". — xaosflux Talk 02:45, 20 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move Wikidata to "In other projects"

edit
There is consensus against this proposal. Barkeep49 (talk) 01:41, 4 June 2020 (UTC), --DannyS712 (talk) 02:51, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move Wikidata link from "Tools" to "In other projects" section. "Tools" are more links to help with a page on Wikipedia. Wikidata links to entirely different project. Never quite understood why it's in "tools" section to begin with.

Survey (move Wikidata)

edit
  • Support as proposer. Renata (talk) 04:37, 14 April 2020 (UTC)[reply]
  • Support. Wikidata is a project. —⁠烏⁠Γ (kaw) │ 07:44, 14 April 2020 (UTC)[reply]
  • Weak oppose per AHollender's rationale. {{u|Sdkb}} talk 04:40, 15 April 2020 (UTC)[reply]
  • Oppose. The "In other projects" already has a Wikidata link if a page has an equivalent in Wikidata. For example, Wikipedia:Administrators' noticeboard links to Wikidata item "Special:EntityPage/Q4580256" from the tools section, and to Wikidata page "Wikidata:Administrators' noticeboard" in the other projects section. Peter James (talk) 10:41, 15 April 2020 (UTC)[reply]
    • How does that work? I've never noticed it in article space. Pelagic (talk) 21:22, 20 April 2020 (UTC)[reply]
      • @Pelagic: That's because there are no articles that have equivalent pages on Wikidata. Each Wikidata item can be linked to a page on each wiki, including Wikidata itself. (In these cases, the linked Wikidata page will itself have a "Wikidata item" link in the Tools section.) Most items with pages on both Wikipedia and Wikidata are for project pages, help pages, templates, modules, or user categories. --Yair rand (talk) 18:41, 21 April 2020 (UTC)[reply]
        • Oh, I get it. As in: Wikidata has a main page which is functionally equivalent to the main Commons page or our Main Page. And it also has an item about the concept of "Wikimedia main pages" that binds those all together. Thanks for explaining, Yair rand. It creates a tricky edge case. Pelagic (talk) 20:52, 21 April 2020 (UTC)[reply]
  • Oppose per AHollender and Peter James. – Teratix ₵ 12:58, 18 April 2020 (UTC)[reply]
  • Neutral Oppose: Meta-WIki is an multi-language wiki, and it's a project, but does not contain content. Same for MediaWiki. However, Wikidata is a multi-language wiki, and it's a project, and contains content provided for projects, making it a secondary project. So it's a project by contributors, for contributors. What's the difference between an article about amazon on the English Wikipedia compared to the Simple English Wikipedia? It's a different language with the same content (apart from complexity). Now what about comparing them to wikidata? Not the same content. Hmm. Maybe make this as a preference or a gadget, or in the tools section. {{replyto}} Can I Log In's (talk) page 03:29, 20 April 2020 (UTC); edited 06:04, 20 April 2020 (UTC)[reply]
  • Support, as you're looking at the topic from another project's view. >>BEANS X2t 12:29, 20 April 2020 (UTC)[reply]
  • (ec) Support because I personally conceive of Wikidata as a sister project and keep looking for it under that heading, then doing a double-take and scanning the rest of the sidebar to find it. Yes, a part of Wikidata is inter-language linking for the Wikipedias, but it does have content which goes beyond that. Pelagic (talk) 21:26, 20 April 2020 (UTC)[reply]
    Changed to neutral. Though counter-intuitive, the current placement is a case of "form follows function" as discussed with Peter James and Yair rand above.
  • Oppose. As previously mentioned, Wikidata may be another project but it doesn't function as one. The average non-editing reader would gain nothing of use from it. It is a tool used to provide cross-project structure, and it should be treated as such.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • I would like to but...: I would like to see this change, in principle. But after reading Peter James' concerns, I think this is something that would require more thought about the right UX. --MarioGom (talk) 18:45, 27 April 2020 (UTC)[reply]
  • Oppose. Although Wikidata is another project, it has special status as the linchpin of the Wikipedia universe. -- The Anome (talk) 15:18, 29 April 2020 (UTC)[reply]
  • Weak oppose. This change would be helpful for longtime editors but, per Peter James above, this seems like a bad idea. comrade waddie96 (talk) 08:54, 14 May 2020 (UTC)[reply]

Discussion (move Wikidata)

edit

So I agree that Wikidata could make sense in the "In other projects" section, as it is quite literally another project. If I were to try to make an argument for why it also makes sense in the "Tools" section, I would think less about the technical categorization, and more about the intent of the user. What is someone expecting to get if they click on a link within the "In other projects" section? I'm totally guessing here but I imagine people see those links as sort of a "Read/learn more about this topic in one of our other projects". So going to Wikiquote or Wikivoyage makes a lot of sense. However Wikidata is a bit different from other projects in that it is more of a "tool" rather than a content/learning experience. AHollender (WMF) (talk) 14:17, 14 April 2020 (UTC)[reply]

  • Note: Many (most?) articles currently don't have an "In other projects" section at all. This move would frequently cause there to be an extra section that otherwise wouldn't be there. --Yair rand (talk) 16:52, 23 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move "In other projects" under "Print/export"

edit
Proposal to be adopted. OhanaUnitedTalk page 00:13, 17 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

That way "In other projects" and "Languages" are shown together and not separated by a random tool section.

Survey (move In other projects)

edit

Discussion (move In other projects)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Separate "Page tools" and "User tools"

edit
There is no consensus for this proposal. Barkeep49 (talk) 01:42, 4 June 2020 (UTC), --DannyS712 (talk) 02:52, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current Layout Proposed Layout
(without taking into account other proposals)

Tools

  • What links here
  • Related changes
  • User contributions
  • Logs
  • Block user
  • Email this user
  • Mute preferences
  • User rights management
  • Upload file
  • Special pages
  • Permanent link
  • Page information
  • Wikidata item
  • Cite this page

Page tools

User tools

  • User contributions
  • Logs
  • Block user
  • Email this user
  • Mute preferences
  • User rights management

"User tools" would show up only in user space and "Page tools" would be same as on other pages.

Survey (user tools)

edit
  • Support as proposer. Renata (talk) 05:09, 14 April 2020 (UTC)[reply]
  • Oppose. Each namespace has a different set of tools, and the Userspace is no exception. Still, I don't believe there is enough of a need to warrant parsing the "Tools" section in two for user pages only. In the example, many of the tools that have been moved to the "User Tools" are exclusive to administrators, which would leave a majority of the editors with an unnecessarily small "User Tools" section when the few that are added could be merged with the rest of the "Tools". This begs the question of whether the "Tools" section is worth being parsed in the first place, but this is a different topic all together. Utopes (talk / cont) 23:20, 14 April 2020 (UTC)[reply]
  • Oppose per Utopes. {{u|Sdkb}} talk 04:32, 15 April 2020 (UTC)[reply]
  • @Utopes: So, for those not logged in, the User tools section would contain "User contributions", "View user groups", and "Logs". Non-admin users would have "Mute preferences" and "Email this user" added. Blocking is the only admin-specific addition, as user group management has a non-admin equivalent item in the list. Even just three items would be larger than Print/Export, which only has two. Seems to me like it would be a helpful division. (Support.) --Yair rand (talk) 17:53, 19 April 2020 (UTC)[reply]
  • Don't see a need to divide just for userspace. ~ Amory (u • t • c) 09:57, 20 April 2020 (UTC)[reply]
  • Support the term Page Tools as suggested by AHollender (WMF) in other section above. Do this consistently everywhere, and add User Tools in userspace. Pelagic (talk) 22:20, 20 April 2020 (UTC) fixed typo Pelagic (talk) 22:22, 20 April 2020 (UTC)[reply]
  • Support - The Tools section can get unwieldy in userspace, and I am not even an administrator. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]

Discussion (user tools)

edit
  • One issue: The links for "Special pages" and "Upload file" really aren't specific to the page. Labeling them "page tools" would be problematic. However, the reordering proposal above moves both of these into the new "contribute" section. --Yair rand (talk) 21:15, 21 April 2020 (UTC)[reply]
    • If not technically feasible to put "Special pages" and "Upload file" in Contribute (could impact non-Vector skins), then they'd need a new section with a name like "Wiki tools". Pelagic (talk) 22:19, 24 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move "Print/export" above "Tools"

edit
Proposal to be adopted. OhanaUnitedTalk page 00:14, 17 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Desktop Improvement Project made it clear that casual readers had no use or understanding of "tools" section, but they understood and could use "print/export" functions. Therefore, proposing to move the section up above "Tools" [which could get very bloated in some namespaces] to make it easier to find. Editors will find their tools regardless.

To clarify: if both this and the #Move "In other projects" under "Print/export" are agreed on, then the order would be: Print/Export, Tools, In other projetcs, Languages. Renata (talk) 06:27, 21 April 2020 (UTC)[reply]

Survey (move up print/export)

edit

Discussion (move up print/export)

edit
  • If both this proposal and the one above, #Move "In other projects" under "Print/export", pass, then we'd have print/export, then tools, then "in other projects, then languages. That seems alright to me. {{u|Sdkb}} talk 22:14, 18 April 2020 (UTC)[reply]
    • It depends on which order you apply the proposals in. It would be truer to the intent of the first proposal (to avoid splitting "print/export" and "in other projects" with the "tools" section) to apply this second proposal first (move "print/export" above "tools"), then the first proposal (move "in other projects" under "print/export"). This results in a new order of "print/export", "in other projects", "tools", then "languages". – Teratix ₵ 01:37, 21 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Renamings

edit

This set of proposals suggests renamings of the labels used for some of the sidebar links.

edit
Proposal to be adopted. OhanaUnitedTalk page 00:15, 17 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia store → Merchandise

edit
Proposal to be adopted. OhanaUnitedTalk page 00:17, 17 May 2020 (UTC)[reply]
While there is a consensus in favor of this proposal the proposal is moot in light of consensus to remove this item. Barkeep49 (talk) 01:44, 4 June 2020 (UTC), --DannyS712 (talk) 02:52, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion (Wikipedia store → Merchandise)

edit
  • Thanks for the input Quiddity (WMF), I appreciate you engaging with the discussion here. One can go shopping at a store so I don't think it would astonish people to click "Shop" and end up at a page headed "Wikipedia Store". There is value in consistent terminology and branding, so what terms the Foundation use should be considered. (I won't suggest re-titling it to "Wikimedia Store" to be consistent with the DNS domain!) In terms of the store vs. the shop as nouns, is that a US/UK English thing? You probably have more important things on your plate right now, but would you consider a straw poll of your non-US WMF colleagues to gauge how they feel about the various words? Pelagic (talk) 01:17, 23 April 2020 (UTC)[reply]
  • It seems to me that there are two aspects to this proposal: (a) something shorter than Wikipedia store as the Wikipedia context is evident; (b) which term to use – Store, Shop, Merchandise, other. My question is how much of the support above, which precedes suggestion of alternatives for Merchandise, is just for (a) and how much also for (b)="Merchandise"? Pelagic (talk) 01:17, 23 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

About Wikipedia → About

edit
There is consensus against this proposal. Barkeep49 (talk) 01:46, 4 June 2020 (UTC), --DannyS712 (talk) 02:53, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Contact page → Contact

edit
Proposal to be adopted. "Contact us" appears to be the preferred choice over "Contact". OhanaUnitedTalk page 00:18, 17 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Main page → Main Page

edit
There is consensus against this proposal. Barkeep49 (talk) 01:47, 4 June 2020 (UTC), --DannyS712 (talk) 02:53, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  • I'm not sure as I haven't looked too much into the issue, and in my opinion they are two different matters, so my !vote here wouldn't influence my !vote there. GoodCrossing (talk) 12:44, 22 April 2020 (UTC)[reply]
  • I would support the move, as I think that our titles ought be sentence case, and that "page" is not being used as a proper noun, rather "main" is describing page as a regular noun. However I would caution that re-opening such a discussion might be seen as re-litigation. However the opening of it on April Fools may have also led to its speedy demise, as many came across it first as a joke, which might reduce people's angst about a new discussion. CaptainEek Edits Ho Cap'n!⚓ 16:07, 22 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Logs → Logged actions

edit
There is consensus for changing the label to User logs. Barkeep49 (talk) 01:48, 4 June 2020 (UTC), --DannyS712 (talk) 02:53, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Languages → In other languages

edit
There is no consensus for this proposal. Barkeep49 (talk) 01:48, 4 June 2020 (UTC), --DannyS712 (talk) 02:53, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

To mirror "In other projects" section.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

User rights management → Manage user rights

edit
There is consensus in favor of "Change user groups" for admins. Barkeep49 (talk) 01:49, 4 June 2020 (UTC), --DannyS712 (talk) 02:54, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Shorter and starts with an action verb like every other user-related link (e.g. "email user" or "block user"). Renata (talk) 05:20, 14 April 2020 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Tools section → ???

edit
There is no consensus in this discussion. Barkeep49 (talk) 01:50, 4 June 2020 (UTC), --DannyS712 (talk) 02:54, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

We have a few options for renaming the tools section to help makes its purpose clearer and reduce confusion. "Editor tools" (from KarasuGamma and Wugapodes) would make it clearer to casual readers that they can ignore this section. "Editing tools" would be similar, and perhaps a little better at breaking down the editor/reader barrier. "Page tools" (from AHollender (WMF)) would help make it clear that the section is for page-specific tools. What do you all prefer? {{u|Sdkb}} talk 07:56, 15 April 2020 (UTC)Refactored 23:05, 15 April 2020 (UTC)[reply]

  • Support any over status quo, with a weak preference for "editing tools". {{u|Sdkb}} talk 07:56, 15 April 2020 (UTC)[reply]
  • Support. "Editor tools" was my suggestion initially. I would prefer "Editing tools", though I'm fine with either. —⁠烏⁠Γ (kaw) │ 08:25, 15 April 2020 (UTC)[reply]
    @KarasuGamma: Oops, sorry, I overlooked the discussion section where you made that proposal. I've refactored above. {{u|Sdkb}} talk 23:05, 15 April 2020 (UTC)[reply]
  • Support, "editing tools" first choice, "editor tools" second. Renata (talk) 19:47, 18 April 2020 (UTC)[reply]
  • Oppose. There's nothing that makes these tools exclusive to editing or editors. I think renaming the section would actually reinforce the "reader/editor barrier". the wub "?!" 21:39, 18 April 2020 (UTC)[reply]
  • Support page tools, and maintaining a separation between page-specific and site-wide tools. Though this would mean putting Upload file and Special Pages into a small section of their own ("Wiki Tools"?), and "heading overload" could be a valid objection. I note that Timeless has separate drop-downs for the two. Oppose editing tools because some items such as What links here and Permanent link are useful for other tasks, not just editing. Oppose editor tools because of the previous reason, and because we shouldn't be sending a message that there is a divide between editors and readers. (After writing this, I realised that my oppose reasons are pretty much identical to those put forward by the wub. The ideas weren't that well-formed in my head until I actually wrote them out.) I think people will ignore the "Tools" section if it's not relevant to their purpose, regardless of what it's called. Pelagic (talk) 21:16, 22 April 2020 (UTC)[reply]
    • Sorry to keep mentioning Timeless, but as a some-times user of that skin and an often user of mobile, those experiences do influence my perspective on different design approaches. Pelagic (talk) 21:16, 22 April 2020 (UTC)[reply]
  • Oppose. There is nothing cofusing about the Tools header and I can't imagine much confusion arises from it. Given the other motions to reorder the menu the negative impact of a more concise heading would be pretty limited.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Support either "editing tools" or "page tools", prefer former on condition that tools not specific to editing is reordered. (Also, shouldn't the title of this section be "Tools → ???"?)--YTRK (talk) 13:28, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Print/export → Export

edit
There is no consensus for this proposal. Barkeep49 (talk) 01:51, 4 June 2020 (UTC), --DannyS712 (talk) 02:54, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Renaming makes the section header more concise and removes the ugly slash, while retaining the key information (these tools can be used to generate an external copy of the page). There is still a clear link to a "printable version", avoiding any reader confusion.

  • Support as proposer. – Teratix ₵ 14:24, 18 April 2020 (UTC)[reply]
    @Teratix: Looks like people are misunderstanding your proposal. they seem to think that you're trying to remove the "print" option instead of renaming the section header 🤷. Daveout (talk) 22:53, 22 April 2020 (UTC)[reply]
  • Neutral, agree on "ugliness" of the slash, but also find "print" a lot clearer and informative than just "export". Renata (talk) 19:22, 18 April 2020 (UTC)[reply]
  • Neutral per Renata. Something to keep in mind is that many of the readers who want to print articles may not be the most technologically savvy, so they may need more cues. {{u|Sdkb}} talk 21:52, 18 April 2020 (UTC)[reply]
  • Oppose: Welcome to 2020 where we are in the middle of a pandemic. Meanwhile in technology, users on the English Wikipedia are arguing over if printing and exporting are the same. Really they are. You can "digitally print" with PDF, or save to Google Drive. It's the same thing! But just leave it alone! {{replyto}} Can I Log In's (talk) page
    @Can I Log In: I understand the sentiment, but here's another way to frame it: we're making a change that'll be reflected on every page of a website that gets about 10 billion pageviews a month. Even very minor changes become consequential and worth discussing when you multiply them by 10 billion. {{u|Sdkb}} talk 02:02, 20 April 2020 (UTC)[reply]
    This doesn't really say much other than showing me some pretty cool stats. That cool I love stats! Where's the stats for printing and exporting? Show me that it's disproportionate in favor of exporting and I'll change my !vote to support. {{replyto}} Can I Log In's (talk) page 03:14, 20 April 2020 (UTC)[reply]
    @Can I Log In: I'm a bit confused by your comments; you've acknowledged printing and exporting are very similar functions, suggesting the dual header is unnecessary, yet you are opposing. – Teratix ₵ 03:32, 20 April 2020 (UTC)[reply]
  • Oppose for possible usability/readability issues. "Export" reads to me as a digital/computer term. I don't have any usability research on this, but I assume people with less digital or computer literacy understand the word "Print" better than "Export". (Less importantly, print and export also mean two different things, and the section includes both: directly printing the page, or exporting it as a PDF.) - Whisperjanes (talk) 15:08, 20 April 2020 (UTC)[reply]
    Although I would support it being changed to "Print or export" as suggested by KarasuGamma below, if others think that looks better. - Whisperjanes (talk) 06:24, 19 May 2020 (UTC)[reply]
  • Oppose. "Export" will be meaningless to less tech-savvy users. Support "Print or export". CJK09 (talk) 04:58, 22 April 2020 (UTC) I misunderstood the proposal. Striking my vote. CJK09 (talk) 01:51, 23 April 2020 (UTC)[reply]
  • Support (strongly). per Proposer's rationale. You don't have to be a technology expert to know what "export" means. It will make the sidebar visually cleaner indeed. Daveout (talk) 12:12, 22 April 2020 (UTC)[reply]
    @Daveout: It's not about being an expert. The set of people who know what a "print" button will do is larger than the set of people who know what an "export" button will do. Therefore, it should contain "print" in its text. CJK09 (talk) 21:56, 22 April 2020 (UTC) Facepalm Facepalm CJK09 (talk) 01:51, 23 April 2020 (UTC)[reply]
    @CJK09: There will be no button called "export". It's just a section header, right under it the user will see two self-explanatory options: "print" and "download pdf". it can't get any clearer than that. "Export" is a broader term that comprises both print and download. Daveout (talk) 22:19, 22 April 2020 (UTC)[reply]
  • Support "Print or export". —⁠烏⁠Γ (kaw) │ 21:07, 22 April 2020 (UTC)[reply]
  • Just a general reply to opposers; even if this proposal went through, there would still be a clear and obvious link to a "printable version", so it seems highly unlikely even technologically challenged readers are going to be confused about where to find the print function. – Teratix ₵ 01:07, 23 April 2020 (UTC)[reply]
  • Support to increase usability. Wouldn't have a major impact but removing the slash and unnecessary words would streamline the menu.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose There are still a lot of people who may not really know what "export" means. From a user perspective "print" > "export". --Enos733 (talk) 03:48, 27 April 2020 (UTC)[reply]
  • Weak oppose: "Print/Export" is a really poor heading for a section with two items: "Download" and "Print". A lot of people has no clue about what "export" is. Still, "print" is online one line away, so it probably does not matter much. --MarioGom (talk) 19:36, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Mute preferences → Mute this user

edit
There is consensus for this proposal. Barkeep49 (talk) 01:54, 4 June 2020 (UTC), --DannyS712 (talk) 02:55, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Huh? I keep thinking this has something to do with my or that user's preferences that they set in Special:Preferences. This is really trying to mute a user, not preferences.

  • Support as proposer. Renata (talk) 08:25, 21 April 2020 (UTC)[reply]
  • Support: Per the proposal reasoning. {{replyto}} Can I Log In's (talk) page 00:50, 23 April 2020 (UTC)[reply]
  • Issue: The text would stay the same even if the target was already muted. "Mute/unmute this user" would be more accurate, but unwieldy. I'm unsure whether "mute this user" would be a positive change. --Yair rand (talk) 16:57, 23 April 2020 (UTC)[reply]
  • The premise of this proposal is flawed. The text means this is a link to preferences about Mute feature, not a way of "muting preferences" themselves as the proposer incorrectly assumed. The link can also be used to unmute user, therefore the proposed name is not quite accurate. "Mute preferences" is more appropriate as it shows you're clearly going to a certain preference page to activate some settings which include, muting and unmuting of mention and email. These are four different settings and so using the proposed "Mute user" to represent them is inadequate. "Mute/unmute this user" is what can serve as a possible name, but in comparison to current "Mute preferences", it can be easily dismissed as a cosmetic change that's no benefit. – Ammarpad (talk) 13:58, 24 April 2020 (UTC)[reply]
  • I am undecided about this proposal but recommend that "user" be changed to "editor" as that is the terminology used throughout most of the project. (I also acknowledge that this is inconsistent in some areas with "user" appearing to be used more often in more technical areas e.g., user rights.)ElKevbo (talk) 19:25, 26 April 2020 (UTC)[reply]
  • Support for clarity, I have also experienced this confusion.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Support for clarification. SemiHypercube 13:54, 27 April 2020 (UTC)[reply]
  • Support but prefer "Mute user" as more consise. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Printable version → Print

edit
There is no consensus for this proposal. Barkeep49 (talk) 01:55, 4 June 2020 (UTC), --DannyS712 (talk) 02:55, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When you click this link, it simply leads you to the operating system's or the browser's print page dialog. Also for simplicity and popularity (many web pages, including encyclopedia britannica, have a simple "print" option, and often just a printer icon).

Clicking on that link has the same effect as pressing Ctrl P on: Opera, Firefox, Chrome and Edge. Daveout (talk) 18:56, 22 April 2020 (UTC)[reply]
  • Comment On second thought, I'm not sure between "Print" and "Print this page". The latter would be more consistent with "Cite this page" (which imo is probably appropriately named), but the former would be more consistent with "Download as PDF", which is not (and shouldn't be) titled "Download this page as PDF". I lean a little toward "Print this page", since the demographic doing most of the printing needs a little extra help, and "this page" adds a bit of clarity. {{u|Sdkb}} talk 19:51, 22 April 2020 (UTC)[reply]
  • Oppose Split: It's literally what it says. It's a printable version of the page. It's not going to give you a print preview and a printing dialogue. It does two things. If you open it in a new tab, it will literally show the printable version. But, if you primarily click on it, it does print. {{replyto}} Can I Log In's (talk) page 01:24, 23 April 2020 (UTC); edited 02:38, 23 April 2020 (UTC)[reply]
    @Can I Log In: Which browser are you using? Everyone here so far reported the opening of a print dialog. Daveout (talk) 02:23, 23 April 2020 (UTC)[reply]
    Derp. I did middle click, not primary click. Now we have something new to consider. Do we want to see the printable version or just print? {{replyto}} Can I Log In's (talk) page 02:38, 23 April 2020 (UTC)[reply]
    Why would anyone like to se a "printable version" of a page if not to... you know... print it? Daveout (talk) 02:44, 23 April 2020 (UTC)[reply]
  • Support. Menu should be concise and "Print" is exactly the function of the link.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Remove altogether? most websites do fine with printing handled by the browser menu. And use of printing is declining, even if your computer won't be handy to read a Wikipedia page your smartphone probably will be. Blythwood (talk) 14:45, 27 April 2020 (UTC)[reply]
    @Blythwood:You're absolutely correct. People should be encouraged to use (or learn how to use) the browser's print functionality. This feature is very easily accessible and intuitive in every browser. And it can be useful for any site, not only wikipedia. However, most ppl here object the removal of the in-site link. We could at least make it less bizzare, calling it just "print" instead of "printable version" Daveout (talk) 17:21, 27 April 2020 (UTC)[reply]
  • Support. More concise and equally descriptive. Most people won't care about the small technical difference. --MarioGom (talk) 19:34, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Download as PDF → Save as PDF

edit
There is consensus against this proposal. Barkeep49 (talk) 01:57, 4 June 2020 (UTC), --DannyS712 (talk) 02:55, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It simply sounds and looks nicer.

Also, some have raised concerns about the use of technological jargon (which may be intimidating for the elderly, for example). In that case, the word "download" may be triggering for those who are less familiar with the whole computer\internet scene.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Additions

edit

This area is for proposals to add new links to the sidebar not present in the current version. When adding a new one, please specify the label you would like for the link to have, the location you would like it to have, and the tooltip you would like to display when a reader hovers their cursor over it.

An introduction to contributing page

edit
There is consensus in favor of an addition but there is no clear consensus regarding elements including, what page should be linked to, what label text should be used, its placement on the sidebar and what the tooltip should be. Barkeep49 (talk) 01:59, 4 June 2020 (UTC), --DannyS712 (talk) 02:56, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Attracting new contributors is of the utmost importance to the project. I therefore propose the addition of a link going to an introductory page. Personally, I believe this should be Help:Introduction, the gateway to our recently revamped tutorial set that has been made the primary button in our new standard welcome message, but other possibilities could be Help:Introduction to Wikipedia (the first module of the tutorial set), WP:Contributing to Wikipedia (a single-page intro), or Help:Getting started (which links to tons of different intros). I would prefer the location directly beneath "Help", with the label "Tutorial""Editing tutorial"Changed 14:47, 29 April 2020 (UTC) per below and the tooltip "Learn how to edit Wikipedia".

Survey (Introduction)

edit
Help:Introduction.... 60 plus pages to click through is definitely not user friendly - even worst then collapsed content because you needs to load.every page. click -load..-click -load.click -load.etc...60 more times.--Moxy 🍁 06:01, 11 April 2020 (UTC)[reply]
Really wish choice of help pages was based on editor retention and accessibility. The idea of the Wikipedia:Adventure that has a 50 percent drop in views by the second page....with a loss of 90 percent by page 3 simply a bad idea. I can see why the adventure is visually appealing but according to data on how users navigate it's a bad choice. --Moxy 🍁 22:30, 18 April 2020 (UTC)[reply]
66 pages vs one with a TOC is less daunting? O well...perhaps best the new generation learn for themselves what works and doesn't work.--Moxy 🍁 22:30, 18 April 2020 (UTC)[reply]
Sure you want to link a giant tuorial that is losing us thousands of editors? Should have a separate talk for this link with those familiar with how to retain and gain editors

page view stats showing the loss of interest editor's by thousands . --Moxy 🍁 18:05, 8 May 2020 (UTC)[reply]

Discussion (Introduction)

edit
  • Is the idea that this would go away for "experienced" users? Not sure how feasible that is, and without that I'd certainly oppose adding a new, useless link for experienced folks. ~ Amory (u • t • c) 10:22, 20 April 2020 (UTC)[reply]
  • We need a helpful, accessible, readable, community-backed tutorial before this proposal is implemented. – Teratix ₵ 02:02, 21 April 2020 (UTC)[reply]
I am working on a new page that actually follows Wikipedia:Help Project/Guidelines. Disheartening to see us going down a path that doesn't follow our basics. Wonderful to see new editors involved in the help page system..but some choices as of late have been detrimental.--Moxy 🍁 03:10, 21 April 2020 (UTC)[reply]
@Teratix: I think the general view is that Help:Introduction is all of those things, Moxy's lone dissension notwithstanding. If you haven't explored it before/recently, I'd encourage you to check it out. @Moxy: I'm interested to see what you create. Is there a reason you're working on a new page rather than making/suggesting edits to an existing one? {{u|Sdkb}} talk 04:47, 21 April 2020 (UTC)[reply]
Your view of what is good for accessibility is based on what you like....not the raw data or the experience of longtime editors or are guidelines. As for making a new page....best to start from scratch..--Moxy 🍁 05:13, 21 April 2020 (UTC)[reply]
My view is based on the feedback we received when you brought the page to WikiProject Accessibility. {{u|Sdkb}} talk 06:03, 21 April 2020 (UTC)[reply]
Perhaps best review gudlines project page you just joined Wikipedia:Help Project/Guidelines....telling someone to collapse every section and removal of a TOC leads me to believe you have not see the projects recommendations. It would save us loss the interest of thousands of potential editors -Moxy 🍁 06:16, 21 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

An FAQ page

edit
Withdrawn. Interstellarity (talk) 14:46, 1 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Many websites have an FAQ page. I think this website should have one as well.

Survey (FAQ)

edit

Discussion (FAQ)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A dashboard

edit
Withdrawn. Interstellarity (talk) 14:47, 1 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I think this link would be helpful to people so people can see what's going on behind the scenes with Wikipedia.

Survey (Dashboard)

edit

Discussion (Dashboard)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Logs

edit
There is consensus against this proposal. Barkeep49 (talk) 02:00, 4 June 2020 (UTC), --DannyS712 (talk) 02:56, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The logged actions of any page are important for any page, so linking Special:Log with parameter &page={{FULLPAGENAME}} in the sidebar would save time, especially for users with slow internet connection. The existing "Logs" tab for users should be renamed to "logged actions", or else this one can be called something like "Page logs". It should be located under the "Tools" header after either "Related changes" or "Page information", with the tooltip "A list of logged actions at this page, excluding edits".

Survey (Logs)

edit

Discussion (Logs)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Deleted contributions

edit
There is consensus against this proposal. Barkeep49 (talk) 02:01, 4 June 2020 (UTC), --DannyS712 (talk) 02:56, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

For admins only and in the user namespace, add a link to the user's deleted contributions under tools. I find the omission of this to be somewhat annoying.

Survey (Deleted contributions)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Search page

edit
There is consensus against this proposal. --DannyS712 (talk) 02:58, 4 June 2020 (UTC) & Barkeep49 (talk) 03:04, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add link to the Search page in the main section -- it has all the ways to browse for content, but does not have search. I recently read somewhere (can't find where now) that many readers don't realize Wikipedia has a search function and rely on Google to find info and articles. Gripes about the quality of our search aside, we should be promoting searching within the project.

Survey (Search page)

edit

Discussion (Search page)

edit

@Renata: Perhaps somewhere in this report? {{u|Sdkb}} talk 04:54, 15 April 2020 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Removals

edit

This area is for proposals to remove links in the current version of the sidebar.

Featured content

edit
There is consensus for this proposal. Barkeep49 (talk) 02:03, 4 June 2020 (UTC), --DannyS712 (talk) 02:58, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Modern readers use the search function or blue links to find the pages they are interested in, not a list of pages, as evidenced by pageview statistics. There should be (at most, and possibly less) one directory-style list of pages in the sidebar, and it should be the main one, WP:Contents. Featured content could be added as a module to the main contents page so that it remains highlighted, plus it will continue to be linked from the Main page's "Today's Featured Article" module.

Survey (Featured content)

edit
  • Support as proposer. {{u|Sdkb}} talk 21:46, 10 April 2020 (UTC)[reply]
  • Neutral I agree with the rationale above....but content editors work very hard to get those things on that page. It's contributing encouragement page and I can see some upset if it's removed.... should have a section to remove portals.--Moxy 🍁 22:10, 10 April 2020 (UTC)[reply]
  • Oppose people should be able to browse if they want. Plus Sdkb’s logic assumes MediaWiki’s search is functional. It is not. There’s a reason the only way to navigate commons is via categories: the native search function in MediaWiki might as well not exist outside of direct matches, so unless you know the name of a redirect or the title page, you very well might not be able to get somewhere. If a reader wants to browse, let them. Lack of page views isn’t a particularly good excuse either. We should make it easy for people to be able to browse featured content as a category if they want. This harms nothing by keeping it these and is a possible benefit to readers. No case for removing has been made. TonyBallioni (talk) 23:33, 10 April 2020 (UTC)[reply]
  • Support - I partly disagree with TonyBallioni's reasoning. The page WP:Contents is the main way to browse Wikipedia and there's a link to it at the bottom of the page. To simplify the page, I think it should be removed so if readers want to browse Wikipedia and/or see featured content, they can click on WP:Contents and then look for the featured content at the bottom of the page. Interstellarity (talk) 23:42, 10 April 2020 (UTC)[reply]
    • That makes zero sense: why on earth would anyone look at a contents page of a 6 million article website. Also why would we want to point them there rather than to the actually good content; most of our articles aren’t that great...
      It also defeats the entire point of it being featured content. Featured means called out. If anything get rid of the actual contents page in it’s entirety. I’d probably not comment either way on it, but if you want to do the makework or cleaning up pages 99% of editors don’t have an opinion on, that’d be the one I’d get rid of. TonyBallioni (talk) 23:55, 10 April 2020 (UTC)[reply]
  • Support – per nom and Interstellarity. The sidebar should have one link for browsing, and it should be to WP:Contents. As it is now, both WP:Contents and WP:FC are linked in the sidebar, and WP:Contents gets about 33% more page views than WP:FC, so I think that's the one "browsing" link to keep. Featured content is already featured on the main page; it doesn't need a link on every page. Levivich [dubious – discuss] 23:52, 10 April 2020 (UTC)[reply]
  • Oppose per Tony: why on earth would anyone look at a contents page of a 6 million article website. Also why would we want to point them there rather than to the actually good content. If I had to make a choice, I'd rather direct readers to our best content than WP:Contents. — Wug·a·po·des​ 00:14, 11 April 2020 (UTC)[reply]
    I disagree with that because the purpose of the link isn't to direct readers to content that we want them to read, it's to direct readers to the content that they want to read. (And if they find that content lacking, perhaps they'll, you know, edit it.) So if someone wants a topical directory to browse all content, WP:Contents would be the only place to start. (Whereas if the reader is looking for our best content, that's already really easy to find: it's at the top-left corner of the main page.) Levivich [dubious – discuss] 01:48, 11 April 2020 (UTC)[reply]
    I think Levivich makes a good point regarding WP:READER. But my chief concern here isn't that we give too much emphasis to featured content — I don't think that's the case — but just that we have too many links on the sidebar and need to consolidate some. In my ideal scenario, WP:Contents gets substantially redesigned so that featured content becomes a major part of the page. (And some user research on who is visiting WP:Contents and why would be useful — something tells me it's 90% technophobic senior citizens who will switch to using the search box as soon as their grandchild shows them how.) {{u|Sdkb}} talk 04:35, 11 April 2020 (UTC)[reply]
    I'm neutral on this proposal, but I would quite like to see such a redesign. (I have never clicked either link before this discussion.) —⁠烏⁠Γ (kaw) │ 04:40, 11 April 2020 (UTC)[reply]
  • Oppose Building on TonyBallioni's point, we should be very proud of featured content and should emphasize that to the relatively few editors who do the heavy lifting in that area. Johnuniq (talk) 03:27, 11 April 2020 (UTC)[reply]
  • Oppose per TonyBallioni. Useful link for showcasing our best content. SD0001 (talk) 04:22, 11 April 2020 (UTC)[reply]
  • Support As a person interested in *Wikipedia* per se I would be interested in featured content, as a person seeking *specific information* I'm interested in the contents. Two very different purposes - pointing people who are interested in specific information to random (high quality) content seems superfluous. The question of whether Contents should be better is a different issue.--Goldsztajn (talk) 13:03, 11 April 2020 (UTC)[reply]
  • Support The link is redundant to the adjacent Contents link. The Contents page naturally has a sub-section about featured content and that seems the appropriate level for it – alongside other content classifications such as vital, popular, topical, &c. Andrew🐉(talk) 09:32, 12 April 2020 (UTC)[reply]
  • Support and redesign WP:Content. People do not go to Wikipedia to find featured articles, they are usually looking for specific info. buidhe 23:40, 12 April 2020 (UTC)[reply]
  • Support, thought about it a lot. The page is ugly and in a way duplicates links on Main page. Also the main link section is already cluttered. Might reconsider if and when featured content page gets a redesign. Renata (talk) 19:26, 18 April 2020 (UTC)[reply]
  • Oppose. These pages (Wikipedia:Featured content and the specific types it links to like Wikipedia:Featured articles) could definitely use a redesign, but they are a showcase for our best work. That showcase is valuable to both readers and the editors creating them. Sometimes people do come to Wikipedia just wanting to see some of our best rather than look up something specific: the entire Main Page is built around that use case, but only spotlights a limited amount of content at any one time. Wikipedia:Contents has its own use for browsing, but only links to featured content right at the bottom of the page. the wub "?!" 14:47, 19 April 2020 (UTC)[reply]
  • Support, people generally don't read articles because they are listed in a "featured\good articles" section, they read articles they are looking for, featured or not. One section presenting the wiki's contents is enough Daveout (talk) 05:08, 20 April 2020 (UTC)[reply]
  • Why on Earth would we not advertise the best we have to offer? I'm not particularly wild about the page itself, but a portal to the best content on the project is awesome! Vastly more useful than linking to a random page, and I certainly wouldn't want to get rid of that. ~ Amory (u • t • c) 10:28, 20 April 2020 (UTC)[reply]
  • Oppose as Featured content is probably the easiest way to view high-quality pages. Contents should be removed if anything.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose: casually browsing and searching something specific are very different things. I think featured context has nothing to do with search. I think it is good to be able to learn about the existence of featured context and also access it whenever you want to check out how the best articles look like, both as reader and as editor. --MarioGom (talk) 19:49, 27 April 2020 (UTC)[reply]
  • Support - I appreciate the work that goes into the featured content, but most casual readers don't even know what it is, much less browse it. Therefore it is well served being on the main page only. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]
  • Support - If any of the links in the top section should be removed, it's this one. Instead, we should direct people to featured content from the contents page. Kaldari (talk) 17:13, 30 April 2020 (UTC)[reply]
  • Support. We need to be assisting people find the content they want to read rather than the content we want them to read. Featured articles and Good articles are part of an internal system to help us improve the content, it is not a substitute Wikipedia of articles we prefer people to read. We are not estate agents directing people away from the rooms they want to see because they are in poor condition, and instead directing them to the lovely view out the window. We help people find what they want, and if the readers are not happy with the condition of the room, they can roll up their sleeves and help improve it. By being simple and honest we help the reader and the reader helps Wikipedia. It's a win win. Featured articles are part of the content, not a replacement for it. SilkTork (talk) 10:10, 5 May 2020 (UTC)[reply]

Discussion (Featured content)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Upload file

edit
There is consensus against this proposal. --Barkeep49 (talk) 03:03, 4 June 2020 (UTC) & DannyS712 (talk) 02:59, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A vast majority of uploads should happen on Commons. Those who have the know-how and understanding for why and how to uploaded files locally, know where to go. This is an old link that has very infrequent use now.

Survey (Upload file)

edit
  • Support as proposer. --- C&C (Coffeeandcrumbs) 23:03, 10 April 2020 (UTC)[reply]
  • Strong oppose only place for info on uploading media. The link allows you to choose Commons or here to upload files.--Moxy 🍁 23:08, 10 April 2020 (UTC)[reply]
  • Oppose This doesn't appear to be technically possible. Even if it were, I agree with Moxy that it is not a good idea. * Pppery * it has begun... 23:17, 10 April 2020 (UTC)[reply]
  • Oppose I think it is nice to have a link that directs people on how to upload the file. It is a matter of convenience. Interstellarity (talk) 23:31, 10 April 2020 (UTC)[reply]
  • Support there is so much content already uploaded and in my experience the good quality content is batch uploaded on commons. We don't need a link here that every person and their dog are invited to use. We are beyond that point. --Tom (LT) (talk) 00:14, 11 April 2020 (UTC)[reply]
  • Oppose the page gets like 5k views a day. There's no reason to make uploading harder. — Wug·a·po·des​ 00:17, 11 April 2020 (UTC)[reply]
    Wugapodes, 5k is almost nothing. Other links get 10s of thousands of views. --- C&C (Coffeeandcrumbs) 01:05, 11 April 2020 (UTC)[reply]
    It's also nothing to thumb our noses at. That's 1.8 million clicks per year which help expose readers to the process of contributing files. Like I said, there's no reason to make it harder to upload media. — Wug·a·po·des​ 02:55, 11 April 2020 (UTC)[reply]
  • Oppose, making it harder for people to get the upload link isn't friendly to new editors - we already have it pushing them to commons via the dialog that is used when you click there. — xaosflux Talk 02:05, 11 April 2020 (UTC)[reply]
  • Oppose per Xaosflux. Personally, I use this all the time to upload new film posters. Lugnuts Fire Walk with Me 07:47, 11 April 2020 (UTC)[reply]
  • Oppose I use this link more than most on the left. Many of our articles lack good images and we should not make it harder for people to add them. Andrew🐉(talk) 09:25, 12 April 2020 (UTC)[reply]
  • Oppose - any images added to Wikipedia can always be transferred to Commons at a later date, so why make them have to move over to Wikimedia Commons just to add an image to an article? Seems unnecessarily tedious to have to switch projects when you want to upload an image every time when you can add a semi-temporary version on Wikipedia and go through the trouble of transferring to Commons later. Kirbanzo (userpage - talk - contribs) 21:49, 12 April 2020 (UTC)[reply]
  • Weak oppose Many non-free images (eg. covers of works, historical portraits) are uploaded or could be uploaded locally. I use this more frequently than most of the other links and it would be annyoing to have it go away. buidhe 23:37, 12 April 2020 (UTC)[reply]
  • Oppose If anything should be changed, it should be the upload page, which should have a concise explanation of why things should be uploaded to commons. When I was a new user, I was thankful that the button existed, as I had no clue that you could upload files, let alone to commons. CaptainEek Edits Ho Cap'n!⚓ 22:07, 17 April 2020 (UTC)[reply]
  • Strong support: our current editors can learn to navigate to a different place for this, or spend an extra couple of clicks (it's not like the NFC uploading process isn't already fairly lengthy). Putting it on the main sidebar visible on every page just encourages readers or new editors to misuse the feature by uploading non-free content that doesn't meet our NFCC—as commonly and regularly happens. It also wastes comprehension time for everybody else reading the sidebar.
    If someone asked us to redesign the sidebar bar for Wikipedia from scratch, by describing the purpose of the sidebar and asking which functionalities should be present, I am confident that not a single editor who opposes this removal would ask for a button for "Upload a file which belongs locally rather than at Commons". Thus we should remove it. — Bilorv (talk) 17:32, 18 April 2020 (UTC)[reply]
  • Support I'd recommend a maximal utilitarian approach here – what is the greater good? I agree it is essentially an open door for abuse. For dedicated users of that link an optional simple javascript code could be created and the link inserted on an individual basis. --Goldsztajn (talk) 11:14, 21 April 2020 (UTC)[reply]
    Making it harder for people to contribute because of the possibility they might not contribute well seems very against the spirit of Wikipedia. {{u|Sdkb}} talk 11:43, 21 April 2020 (UTC)[reply]
  • Strong oppose Wikipedia is already impenetrable enough. We shouldn't add yet another barrier to entry for new editors. CJK09 (talk) 05:03, 22 April 2020 (UTC)[reply]
  • Oppose, this would be an unnecessary loss of functionality.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose, one of the few sidebar links that was actually useful for me. Not because of frequency, but because of discoverability. It has appropriate pointers to Commons, so it serves as a good entry point for uploading media. --MarioGom (talk) 20:51, 27 April 2020 (UTC)[reply]
  • Strong oppose - New editors may not be aware of Commons, but will still need to upload files on occasion. The wizard in the link guides them to Commons when appropriate, so removing the link would also reduce correct usage of Commons. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]
  • Oppose - non-free media files, such as album covers, need to be uploaded on Wikipedia, and it is useful to have a link on the article page itself so people don't have to look elsewhere. My main qualm is with the word "file", as that doesn't speak to me as a reader to mean I can upload the missing image. When I started on Wikipedia, images were called images, but at some point they got renamed to files, though the guidance still talks about images. So we have a file: File:RayCharlesDebut.jpg, and we have advice about images: Wikipedia:Images; and we are supposed to intuitively know that files and images mean the same thing on Wikipedia, and that the guidance on images actually refers to files. SilkTork (talk) 10:25, 5 May 2020 (UTC)[reply]

Discussion (Upload file)

edit
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
edit
There is consensus against this proposal. Barkeep49 (talk) 02:05, 4 June 2020 (UTC), --DannyS712 (talk) 02:59, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

As I understand it, the main benefit of this tool, for readers, is easy access to a reproducible, stable link to mainspace articles for citations. This function is duplicated by Special:CiteThisPage, which provides the link as part of the bibliographic information. If editors or other interested parties need a permanent link to non-mainspace content, where "Cite this page" does not appear, they only need spend one more click (→page history→latest revision). I suppose this may be a slight inconvenience, but one that could be likely remedied with a userscript or preference and is outweighed by the usability benefit of removing low-utility links from the sidebar.

Survey (Permanent link)

edit
  • Support as proposer (assuming technical possibility), though I'm interested to know if I've missed any helpful uses of the tool. – Teratix ₵ 13:57, 18 April 2020 (UTC)[reply]
  • Support: "Cite this page" is new to me, whereas "Permanent link" is one of the ones I actually use. Nonetheless, I'll happily spend an extra click per usage to de-clutter the sidebar. We should not have both, because other than for experienced editors with obscure purposes, the main use for a permalink is indeed citations. — Bilorv (talk) 17:38, 18 April 2020 (UTC)[reply]
  • Oppose removing permanent link which is often required by editors when reporting issues. We could achieve the fake ideal of a perfect design with minimal clutter by hiding every link behind a single "tools" button that opened a cascade of options—totally useless for a working encyclopedia. Johnuniq (talk) 00:03, 19 April 2020 (UTC)[reply]
  • Support Maybe the "cite this page" link could use a little more info about permalinks. But as stated, they are mostly redundant. Also, the "reporting of issues" seems to be done mostly by diffs. Daveout (talk) 05:26, 20 April 2020 (UTC)[reply]
  • Oppose. An extra click is an extra click, and removing "Permanent link" would inconvenience readers who want to cite Wikipedia URLs in their (external) articles. feminist #WearAMask😷 07:43, 20 April 2020 (UTC)[reply]
  • Strong Oppose I know I use this link all the time, and I use it on other projects constantly. It is a core function (unlike C-T-P which is an extension) that just works. — xaosflux Talk 14:08, 20 April 2020 (UTC)[reply]
  • Support. While I do appreciate the presence of the "Permanent Link" link (as I use it myself), I understand that it is probably useless for a majority of our readers who don't plan on editing. To that regard, I'd think that it may be more useful to implement a gadget or a user script that adds the "Permanent Link" link to the sidebar, rather than have it be standard by default. Removing the link should not be undercutting its usefulness, as all of the functionality is one click away in the "Cite this page" tab. I do see the appeal with making the "Permanent Link" link accessible, but this feature being commonly used by readers; only a selection of editors working in the Wikipedia namespace. Utopes (talk / cont) 15:13, 20 April 2020 (UTC)[reply]
  • Strong oppose. I do use this, though I might also get the rev. ID from the History page with some extra clicks. Internally I use [[Special:Permalink/…]], the permanent URL is for readers who want to link from outside, more so than editors. The big reason for having it is that it tells people there is such a thing as a permalink to a specific revision. It sends the message "hey this content is always changing, there is a right way to link to this". The phrase cite this page doesn't convey that up-front, and how many non-academics would be interested in "citing" rather than "linking"? Pelagic (talk) 14:06, 21 April 2020 (UTC)[reply]
  • Strong oppose – Wikipedia is already too complicated. This should stay, it's useful and necessary in a variety of contexts. Many people will have no idea how to generate a permanent link otherwise. And even if they realize they need to start at "view history", there's a very strong possibility they'll be confused by all the links on that page, and give up. CJK09 (talk) 05:06, 22 April 2020 (UTC)[reply]
  • Oppose. Unconvincing reason. – Ammarpad (talk) 14:03, 24 April 2020 (UTC)[reply]
  • Oppose, as the reasoning seems pretty shaky.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose. And by the way, permalink/permanent links pointers are pretty standard. --MarioGom (talk) 20:53, 27 April 2020 (UTC)[reply]
  • Support - It is easily accessible from elsewhere, and is of no use to most readers and a significant portion of editors. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]
  • Support - This isn't useful for most people and people who need it can still find this functionality elsewhere. Kaldari (talk) 17:10, 30 April 2020 (UTC)[reply]

Discussion (Permanent link)

edit

@Pelagic: You raise some interesting thoughts about why a reader might want to use the permanent link button. In most cases, when citing a page, it's probably best to use the permanent link button so that people know exactly what you were citing. In other cases, it might be best to link to the "fluid" version, so that people who follow your citation can benefit from any potential improvements to the page. It's kinda analogous to the subst vs. transclude options we have for templates. On a mostly unrelated note, you inspired me to think about the permanent link notice which led to this. {{u|Sdkb}} talk 21:43, 22 April 2020 (UTC)[reply]

I completely agree, Sdkb, it depends on your purpose. I was overstating things when I wrote "the right way". I was trying to curb my natural inclination toward verbosity and over-qualified statements. 😉 Pelagic (talk) 04:31, 25 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia store

edit
There is consensus for this proposal. Barkeep49 (talk) 02:06, 4 June 2020 (UTC), --DannyS712 (talk) 03:00, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It links to https://store.wikimedia.org/. Per Hick's law, every link on the sidebar is a net negative unless it can demonstrate a significant and frequent usage by readers. I don't know how many people are buying a $40 hoodie with the Wikipedia logo on it in 2020, but it is surely a negligible proportion of desktop readers, all of whom see this link on every page they visit. Does not serve readers and does not serve editors. Anyone wishing to buy Wikipedia merchandise has a huge number of avenues available to them, including many which will take them immediately to Wikimedia's store (e.g. any search engine). Their first instinct will not be to read all the sidebar links from the article WrestleMania 36 (or whatever they happen to be viewing). Additionally, this page is only applicable to certain countries (not all English-speaking ones, even), and we have readers from all the countries in the world.

EDIT: Per Quiddity (WMF) below, roughly 20% of the purchases from the donation store originate from a click of "Wikipedia store", the other 80% from other avenues.

Survey (Wikipedia store)

edit
  • Support as proposer. In additions to the reasons I listed above, which I imagine most editors and readers will find agreeable, I personally believe that Wikimedia should not be using our editors' work as a vehicle for profit promoting donations in the way that they do, which ranges from this link in the sidebar to the intrusive, persistent, misleading and frequent "FOR THE PRICE OF A CUP OF COFFEE" banners they advertise all over our articles with. A link to the "Wikipedia store" may have been a good novelty in 2003, when the concept of Wikipedia was modern and hip and you might want a water bottle to show your support, but in 2020 when we are just a part of everyday life, it's about the most bland and useless link we could put on our sidebar. Imagine if one of the links at the top of every Amazon page was a link to a collection of T-shirts with the Amazon logo on it. — Bilorv (talk) 18:08, 18 April 2020 (UTC)[reply]
    Changed "using our editors' work as a vehicle for profit" to "promoting donations" upon learning what the donations are earmarked for. — Bilorv (talk) 11:41, 23 April 2020 (UTC)[reply]
  • Support as mentioned above, per Bilorv. Anyone interested in merchandise can still find it with relative ease (if I Google "Wikipedia merchandise" the first hit is https://store.wikimedia.org/ ). If it's a major source of money (which I doubt, but what do I know), it could be linked from https://donate.wikimedia.org instead (which is where I land if I click "Donate to Wikipedia" in the sidebar). Ajpolino (talk) 18:22, 18 April 2020 (UTC)[reply]
    @Ajpolino: Re money: See m:Merchandise income, and m:Wikimedia_merchandise#Who_profits_from_this_store? ("All proceeds are filtered back into the store to keep production costs low, subsidize shipping and help to provide merchandise specifically aimed towards community members."). --Yair rand (talk) 17:11, 19 April 2020 (UTC)[reply]
  • Support per above. Money isn't an issue here, because the profits from the store don't fund Wikipedia, they're used to fund free merchandise giveaways to editors [2]. I'm generally opposed to merchandising Wikipedia because it leads to nonsense like this (300-euro shirts and 120-euro hats) and this (how did that happen?). Anyway, anyone wanting to find the store will easily be able to find it; it's not necessary to put a link to the store on every page, and if anything, it draws clicks away from the "donate" link. Levivich [dubious – discuss] 18:52, 18 April 2020 (UTC)[reply]
  • Support, prominent location for a link with negligible net benefit to the foundation and the project. Renata (talk) 19:06, 18 April 2020 (UTC)[reply]
  • Oppose, I wouldn't even know it existed if it weren't there. But if it were removed I agree that it should be linked in the donate page. GoodCrossing (talk) 23:30, 18 April 2020 (UTC)[reply]
  • Support, this type of thing should be merged with the "make a donation" section. Daveout (talk) 04:58, 20 April 2020 (UTC)[reply]
  • Support per Daveout. feminist #WearAMask😷 07:43, 20 April 2020 (UTC)[reply]
  • Comment, WMF would prefer to keep this for now, and perhaps revisit it later. The store is used by people who love Wikipedia, and the money is earmarked to supply gifts to community-nominated volunteers, a programme we are in the midst of refreshing. Quiddity (WMF) (talk) 23:09, 21 April 2020 (UTC)[reply]
    @Quiddity (WMF): thanks for providing the WMF stance, which I respectfully disagree with. Do the WMF have any record of what proportion of items bought on this store originate from a click from this particular link (rather than e.g. search engine traffic)? — Bilorv (talk) 11:41, 23 April 2020 (UTC)[reply]
    @Bilorv: (sorry for the reply delay). The link in the sidebar leads to roughly 20% of the items bought at the store. The majority of the remainder of the traffic and purchases come via the "Thank you for donating" confirmation-emails. HTH. Quiddity (WMF) (talk) 19:26, 7 May 2020 (UTC)[reply]
    @Quiddity (WMF): thank you, this information is very useful. I've mentioned it in the top of this section so that people can use it to inform their opinion. — Bilorv (talk) 21:00, 7 May 2020 (UTC)[reply]
  • Oppose. This is a classic example of the kind of link that has low usage, but has extremely high value for the 0.1% of readers who want it. It's worth keeping for those 0.1% of users. SnowFire (talk) 06:32, 25 April 2020 (UTC)[reply]
  • Support This is nowhere near important enough to merit such a prominent spot. * Pppery * it has begun... 22:27, 25 April 2020 (UTC)[reply]
  • Weak support, as long as the link was moved to the donations page.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Weak oppose, no better place for it to go I think (it should be displayed somewhere).--YTRK (talk) 13:28, 27 April 2020 (UTC)[reply]
  • Oppose, one might disagree with the existence of an official Wikipedia Store or its prices, but given its existence, I think it really belongs there, close to Donate/About/Contact/etc. --MarioGom (talk) 20:48, 27 April 2020 (UTC)[reply]
  • Oppose If it exists, and I suppose some people actually do want to buy the merchandise, It should go where such things are is normally found on websites, with donations. I suggest a single Support Wikipedia link, which goes to the various possibilities. it should be a on the Donations section of things. DGG ( talk ) 22:08, 27 April 2020 (UTC)[reply]
  • Support - I think most people who want Wikipedia merch (which isn't exactly a large market) would be able to find it elsewhere. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]

Discussion (Wikipedia store)

edit
  • Discussion is related to Wikipedia store → Merchandise above, and partly spun out of it due to users Ajpolino and Levivich saying that they could support a removal of this link. — Bilorv (talk) 18:10, 18 April 2020 (UTC)[reply]
  • @Seddon (WMF) and SHust (WMF): I'd be interested to hear you or your colleagues' perspective on this. {{u|Sdkb}} talk 22:08, 18 April 2020 (UTC)[reply]
    IIRC, Seddon's role as Advancement department liaison is currently being held by User:Quiddity (WMF), while Seddon is temporarily working with the Product department. --Yair rand (talk) 17:25, 19 April 2020 (UTC)[reply]
    Also, it may or may not be the case that the store is now managed by User:KHansen (WMF). It's hard to tell. Unfortunately, much about the store (and the staff roles) is terribly documented. --Yair rand (talk) 03:31, 20 April 2020 (UTC)[reply]

  • If I oppose, will I get a t-shirt in the mail? [just kidding] [FBDB] I don't think I've ever tapped that link before today. Never is a long time, but not in recent years anyway. It's probably more noticeable to new or infrequent visitors who haven't yet become accustomed to ignoring segments of the UI. For those who do notice, it does serve to bring to mind the idea of wiki-merch. If they then go on to a web search and find a €300 hoodie, then fine. Can we make a deal with Randall to sell these?

    I do note that this and many other sidebar elements were intentionally left out of the Minerva/mobile and mobile-app interfaces, and that mobile is a primary medium for many of our readers. So a large part of our audience is already not seeing the link.

    Sure, Wikipedia is an encyclopaedia, but it's also a website. That we have on the desktop site a store, and badges which say "a Wikimedia project" and "powered by MediaWiki", and legal disclaimers, etc. doesn't bother me: it goes with the territory.

    [Sorry if my formatting is objectionable; I'm thinking about ways to do multi-paragraph talk-page posts. It feels like we can do well-structured output or readable source code but not both.]

    – Pelagic (talk) 22:41, 22 April 2020 (UTC)[reply]

    @Pelagic: Many people (including volunteer-me, years ago) have suggested that we stock Citation needed stickers in the store. The hesitation is that we don't want to encourage what could be seen as public-property vandalism, e.g. someone putting these stickers on bus-stop advertisement posters, or within busses, etc.
    I'll also note that we're currently investigating the feasibility/cost of offering 3D-printed Wikipedia puzzle globes in the store, for people who don't want to go through the hassle of using the freely available files themselves. Cheers. Quiddity (WMF) (talk) 22:07, 7 May 2020 (UTC)[reply]
    public-property vandalism oh, good point! Pelagic ( 📝 messages ) 🌲 – (23:14 Sun 10, AEST) 13:14, 10 May 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Print/export (both "Download as PDF" and "Printable version")

edit
There is no consensus for this removal. Barkeep49 (talk) 02:07, 4 June 2020 (UTC), --DannyS712 (talk) 03:00, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Those options have already been included in virtually all web browsers for quite some time now. (Chrome, Firefox, Opera, Etc). Really. Even simple mobile browsers have those.

Survey (Print/export)

edit
  • Support as proposer. Daveout (talk) 21:48, 21 April 2020 (UTC)[reply]
  • Strong oppose for ease of use reasons. We need to keep in mind systemic bias here – the demographic of editors differs vastly from the demographic of readers. Many older people have difficulty navigating the zillions of menus and buttons on modern operating systems, browsers, etc, and stick to workflows they are familiar with. I've observed this helping my father, who's in his 60s, with computer stuff. I've also seen it far more acutely when my grandmother was alive (I helped her with her email). I see no good reason to remove a simple and obvious one-click workflow in exchange for a (presumed) alternative workflow usable only by means of (often hidden) menus and/or keyboard shortcuts. CJK09 (talk) 05:11, 22 April 2020 (UTC)[reply]
  • Oppose per CJK09, who makes the point about systemic bias very well. And it's even more important when we're talking about the print function, given how much the older generation likes to print things rather than view them online. {{u|Sdkb}} talk 11:04, 22 April 2020 (UTC)[reply]
  • Weak Oppose the way to save as a PDF on google chrome requires you to press print and then select save to PDF as the printer. This is slightly counterintuitive (as you print to save). Therefore, for those who find it hard to save the page as a PDF document through the browser, having this link is useful and quicker. Dreamy Jazz 🎷 talk to me | my contributions 22:10, 26 April 2020 (UTC)[reply]
  • Support, as the modern browser does both quite easily.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Weak oppose to plain removal. I would rather get it elsewhere if there is any major UX revamp. --MarioGom (talk) 20:54, 27 April 2020 (UTC)[reply]
  • Support - As others have said, these features are included in most browsers. Though there are some who don't know how to access them, I doubt that they are often enough used to warrant sidebar entries anyway. Most people - even those who are bad with technology nowadays - would bookmark a page to make note of it instead. - Axisixa T C 03:46, 28 April 2020 (UTC)[reply]

Discussion (Print/export)

edit
@Yair rand: Hi, Yair. That's because most of them use the term "Print to PDF" instead of "Save as PDF". Just look for the option to "Print" the page (keyboard shortcut: press "Ctrl" "P" at the same time) and the option to print to PDF will definitely appear. Daveout (talk) 21:46, 21 April 2020 (UTC)[reply]
  • Question When I click the printable version, it goes right to my browser's (desktop Chrome's) print dialogue. Is that the case for all users? If so, perhaps we should rename "printable version" to "print this page". {{u|Sdkb}} talk 11:06, 22 April 2020 (UTC)[reply]
It should be called just "Print". Daveout (talk) 11:51, 22 April 2020 (UTC)[reply]
I get the same on an iPad (Safari). Though if I cancel then subsequent attempts produce a dialog box "this website has been blocked from automatically printing [ignore] [allow]". Probably the only users who get a "printable version" onscreen without a print dialog would be those with JavaScript disabled? (haven't tested this) Pelagic (talk) 00:11, 23 April 2020 (UTC)[reply]
Pelagic, correct —TheDJ (talk • contribs) 10:31, 14 May 2020 (UTC)[reply]
  • Another question: when using the browser's Print function, do we use the magic of CSS @media to get the same layout as from "Printable version" (no navbars, alternate fonts), or is it different? Pelagic (talk) 00:11, 23 April 2020 (UTC)[reply]
    They should be the same. You can preview this "printable version" in browser (without the system's print dialog) by copying the link's url and pasting it in another tab. Daveout (talk) 00:52, 23 April 2020 (UTC)[reply]
    @Daveout: I see, so the &printable=yes does do what it says and strips out the navigation elements server-side. (And the two approaches do look identical.) Combining this with what TheDJ said above, and testing a bit with some desktop browsers (where I can access F12 tools): it appears that, when JS is enabled, we intercept the click and just launch the native print dialog, allowing @media selectors to do their job and saving a round-trip to the server.
    That explains why, for users who (a) have working JS and the right level of CSS support (most people), and (b) know how to use the browser's print function (maybe not as many as we'd assume, see TheDJ's comment below), this link is unnecessary.
    Do we keep this for those who lack (a) or for (b)? For me, the (a) case merits consideration, making Wikipedia usable on as many devices as possible. Whether that has to accommodated in the default Desktop skin is an open question.
    – Pelagic ( messages ) 🌲 – (11:43 Sun 17, AEST) 01:43, 17 May 2020 (UTC)[reply]
    @Pelagic: I can't see how this link could be useful for someone who lacks (a). In case (a), if someone wants to print the page they are previewing, they would need to resort to the browser's print option anyway (which probably already has a "print preview" feature). Daveout (talk) 04:58, 17 May 2020 (UTC)[reply]
    @Daveout: If the web browser doesn't have a sufficient level of CSS support to do it for you, then the &printable=yes version provides another means to strip out the extraneous navigation elements, for printing ... or other reasons. Another rare (these days) use case occurred to me: say you wanted to "save page as HTML" without the cruft, you could load the printable version then save that. Sigh, I've been around the interwebs too long. Simplified view and click here to print are two different things that we've smooshed together in the belief (probably true) that most people only care about the latter. Pelagic ( messages ) Z – (08:06 Mon 18, AEST) 22:06, 17 May 2020 (UTC)[reply]
    Printing and exporting might be old-school, but an analogous modern feature that produces stripped-down pages is the "reading view" found in several non-Google web browsers. (I do wonder how many people use reading view for accessibility compared to those who use it as an ad killer, noting that the latter doesn't apply to Wikipedia since we're ad-free.) Pelagic ( messages ) Z – (08:06 Mon 18, AEST) 22:06, 17 May 2020 (UTC)[reply]
    @Pelagic: Those are very -very- extreme scenarios indeed 😅. but i'm guessing that if someone really really wanted to do those things (strip the webpage), they probably would be able to find a 3rd party workaround to do that somewhere in the internet Daveout (talk) 22:54, 17 May 2020 (UTC)[reply]
  • As someone who has advocated for the removal of printable version link for a LONG time. I will note that I have been surprised by the amount of users who CANNOT find the print feature in their browser. Yes I know it sounds insane, but long time users (especially those who long clung to IE) are so used/trained to having to use a 'print link' because each ticketing service they use has a 'print ticket' button, that they are unaware that their browsers are perfectly able to handle printing these days. This is why eventually I chose to rename it to 'print' instead and just trigger the JS print() function. —TheDJ (talk • contribs) 10:29, 14 May 2020 (UTC)[reply]
    needless to say that 'download as pdf' is an even bigger crowd (which is why the foundation spent so much engineering trying to keep that functionality alive). —TheDJ (talk • contribs) 10:33, 14 May 2020 (UTC)[reply]
    @TheDJ: I'm surprised there wasn't a push for 'Download as ePub / Mobi / etc.' when e-book readers were all the rage. Pelagic ( messages ) 🌲 – (11:46 Sun 17, AEST) 01:46, 17 May 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Random article

edit
NOT REMOVED
Kept per WP:SNOW. 207.161.86.162 (talk) 07:06, 4 May 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

One of the reasons presented in favor of putting the "Featured Content" inside "Contents" was that most "Modern readers use the search function or blue links to find the pages they are interested in". Based on that logic, with which i agree entirely, the "Random Article" link should be a simple button on the main "Contents" page. Daveout (talk) 15:50, 20 April 2020 (UTC)[reply]

Survey (Random article)

edit
  • Oppose. It is difficult to articulate why, especially without straying into WP:ILIKEIT territory, but this is a widely-used button that serves both to entertain and to find articles on smaller topics, which likely spurs editing. I predict a snowstorm. —⁠烏⁠Γ (kaw) │ 21:04, 20 April 2020 (UTC)[reply]
  • Oppose. The "Random article" link is basically part of Wikipedia's identity, and shows the scope of what types of pages Wikipedia offers. I don't have statistics for its usage, but I am aware of its popularity.[citation needed] I echo KarasuGamma that my !vote is influenced by personal preference, but the "Random article" link is still very useful for Random page patrollers. Utopes (talk / cont) 21:44, 20 April 2020 (UTC)[reply]
  • Strongly oppose. You might say [citation needed] but I think the random article function is very iconic as Utopes says. Also, it's useful, for finding cool things to learn about or articles that need some corrections. Definitely keep. GoodCrossing (talk) 23:24, 20 April 2020 (UTC)[reply]
  • Heck no, my favorite link in the toolbar, even if it leads to one-sentence substub on a village somewhere. Renata (talk) 05:59, 21 April 2020 (UTC)[reply]
  • Super duper strong oppose it takes all oppoose everywhere in wikimedia: If it's taken away, then we'll once again, have to press more buttons. You can't even transclude a random page.[dubious – discuss] Look (see the source code)! Special:Random Random Page Patrollers would have to click up to twice as much buttons. {{replyto}} Can I Log In's (talk) page 16:44, 23 April 2020 (UTC)[reply]
  • Oppose: this iconic link is easily the most famous of the links on our left sidebar. It serves a clear purpose that a casual reader would never learn how to find otherwise, and serves as symbolic of a site where we hope readers learn something they never expected to learn, as well as the stuff they wanted to. — Bilorv (talk) 21:58, 26 April 2020 (UTC)[reply]
  • Oppose. It is iconic. People play the "random article game" where they click on the random article link in the sidebar and try to get to a predefined article through wikilinks in articles. I even played this game a few years back before I started regularly editing. This example isn't probably the main use case of the link, but there are plenty more use cases for the link. If I want to improve a random article, the link is very useful as it allows me to quickly move on to the next article if the article I just randomly visited was not in need of editing / had just been edited. Also it shows off our breadth of content to readers. A random visit to a article with a grammar mistake or spelling mistake may encourage a reader to edit to fix said mistake and so this article would receive edits where it otherwise might not have. Dreamy Jazz 🎷 talk to me | my contributions 22:21, 26 April 2020 (UTC)[reply]
  • Strong oppose. Random article is used for a variety of reasons. As mentioned above, this function is actually the focus of a few Wikipedia games. It is also used by editors (including myself) to find articles in need of improvement outside our usual interests, as well as casual readers trying to find new content.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose per reasons above, it can be a way to learn about something new or find an article to work on.
  • Oppose - It is far more used than some of the links that are being proposed. - Axisixa T C

Discussion (Random article)

edit
  • We don't have access to pageviews since it doesn't lead to a page, but I share the perception that, among sidebar links, the random article link is uniquely beloved by those who know about it. I've been thinking about it and discussing it briefly recently, so I'm glad to have a space to bring it up here. Regarding its appropriateness for the sidebar, it has a unique argument for a persistent presence, since unlike any other link in the sidebar, it's nice to be able to click it over and over, whereas if it was just a button on the Main Page (which perhaps it still should be), clicking it would take you away from the button, so you'd have to go back to use it again.
    The main issue with the link is that, while it's useful for getting a sense of the full scope of Wikipedia, most articles it leads to are stubs about small towns, minor sports topics, or obscure species, and thus of limited interest to actually read. There could be several other versions of the button, leading for instance to a random good/featured article, or to a random vital article at a designated level. I can envision a module with two sliders, one for quality and one for obscurity, that editors could adjust before clicking the button, but I don't know how that could be integrated into the sidebar. @Daveout, KarasuGamma, Utopes, and GoodCrossing: What do you all think? {{u|Sdkb}} talk 05:40, 21 April 2020 (UTC)[reply]
    • I think it's really fine as it is, even if it does tend to lead to stubs. However, I'm all for customization, so having a way to configure the quality of the random articles sounds like a good feature (although in my case, since I like the current random button, I'd leave the settings like that) for the people that don't want to see just stubs when they click the button. GoodCrossing (talk) 10:40, 21 April 2020 (UTC)[reply]
    • I had no idea that this link was so beloved by so many editors, User:KarasuGamma was right, this was a snowball in hell, lol. /// @Sdkb: I have no idea of how to implement those variants. Maybe after someone clicks the link for the first time, other options could appear bellow it?, maybe a narrow top-banner with more options could appear for those randomizing articles? I don't know... Daveout (talk) 11:34, 21 April 2020 (UTC)[reply]
    • I think the button would be improved if it only led to articles B-class or higher. Still a fairly large selection, but with the worst filtered out. --Yair rand (talk) 21:24, 21 April 2020 (UTC)[reply]
  • Comment I'm not too familiar with closing RfCs, but it seems like this can be closed as WP:SNOW, right? GoodCrossing (talk) 18:17, 25 April 2020 (UTC)[reply]
    @GoodCrossing: This was definitely a snowball in hell. I'm not sure how to proceed tho. Should I simply delete it? or should I let it here for "documental reasons"? Daveout (talk) 19:47, 25 April 2020 (UTC)[reply]
    @Daveout: I believe as per WP:CLOSING an uninvolved editor should close this. GoodCrossing (talk) 19:53, 25 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Recent changes

edit
NOT REMOVED
The link is kept per WP:SNOW. A strong majority of !voters note value of recent change patrolling. (non-admin closure) {{u|Sdkb}} talk 14:29, 29 April 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I think that this link is not (at all) useful to the average reader or editor. It should be left inside the "special pages".

  • Support as proposer Daveout (talk) 23:17, 22 April 2020 (UTC)[reply]
  • Oppose: You the proposer are a vandal for proposing this. I'm calling WP:ARBCOM to WP:SITEBAN you! Stuck because WP:AGF If I want to go recent changes patrolling, then I'll press that button on the left. Sure you can do [alt-shift-r], but nah. So what do you want us to do? Not RCP? I'm not going to press and extra button and scroll through to find recent changes. Otherwise, I might have to resort RCPing on my userpage! For example, see this new invention.
Go recent changes patrolling here! Purge to update.
List of abbreviations (help):
D
Edit made at Wikidata
r
Edit flagged by ORES
N
New page
m
Minor edit
b
Bot edit
(±123)
Page byte size change

23 December 2024

P.S. I would support this, but it's not very interactive. {{replyto}} Can I Log In's (talk) page 01:13, 23 April 2020 (UTC)[reply]

I certainly won’t object your mass patrolling habits, but you gotta admit that patrolling 6.000.000 pages at once is not something average users normally do. This seems to be a feature used by advanced editors only, and they can easily bookmark that page in their browsers so it will be one click away. People say that we shouldn’t rename ‘’print this page’’ to ‘’print’’ because the elderly might get confused, imagine what would happen to grandmas if they clicked on that ‘’recent changes’’ by mistake, they would probably drop dead out of mental overload. Think about that. Daveout (talk) 02:13, 23 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Autocollapsing

edit

A key component of usability is reducing visual clutter by hiding less important links. Accordingly, these proposals suggest collapsing some sections by default, with readers able to click to expand them if desired.

"Tools" section

edit
There is consensus against this proposal. Barkeep49 (talk) 02:08, 4 June 2020 (UTC), --DannyS712 (talk) 03:01, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The links in this section are used only moderately frequently even by editors. Far more importantly, though, Wikipedia should be designed for readers, not editors, and there is definitely no need for readers to see these links on every page they visit. A recent user research report confirms that readers do not understand and are confused by them. A setting could be introduced for editors to keep the section expanded by default if they want.

Survey (collapse Tools)

edit
  • Support as proposer. {{u|Sdkb}} talk 21:46, 10 April 2020 (UTC)[reply]
  • Support Although collapsing is strongly discouraged every where when concerning readers due to accessibility.... we all know that collapsed things make people look.--Moxy 🍁 22:08, 10 April 2020 (UTC)[reply]
  • Oppose Explaining to someone how, for example, that a hidden category can be seen by clicking "Page information" should not be complicated by some design dream of the perfect page where nothing is visible. People who vaguely remember that there is an "information" something can search and find it under Tools. They would never find it if Tools is collapsed. Collapsing requires JavaScript which is not compulsory for Wikipedia. Johnuniq (talk) 23:33, 10 April 2020 (UTC)[reply]
  • Oppose usability > design. Also per Johnuniq. TonyBallioni (talk) 23:39, 10 April 2020 (UTC)[reply]
  • Qualified support if, like a "normal" website, we could make it a preference whether to collapse or expand the tools section by default. Something tells me not to assume that this is doable, even if other websites have had this functionality for years. My understanding is that the number of web users without javascript is incredibly tiny, like 0.1%, so if that's true I don't think that's a concern. Levivich [dubious – discuss] 00:07, 11 April 2020 (UTC)[reply]
  • Weak oppose prefer just renaming it something like "Editor tools" or "Advanced tools". I get that readers may be confused by it but this seems like more work than it's worth. Readers aren't spending hours every day looking through the "tools" section and wondering what it all means; they may spend a few seconds, go "huh" and then move on with the rest of their lives like they do with every other editorial button. Most of our readers are on mobile where they don't even see the toolbox. — Wug·a·po·des​ 00:24, 11 April 2020 (UTC)[reply]
  • Oppose likely to cause accessibility problems. And those who want to use the links will need to make one extra click. There is a lot of space in the sidebar, I see no reason to collapse. SD0001 (talk) 04:21, 11 April 2020 (UTC)[reply]
    @SD0001: Fair enough, but consider that there's also a lot of empty space on Google's homepage (and plenty of products that could reasonably fill the space), but there's good reason they keep it that way. Every item that we remove or collapse helps the remaining items stand out more and makes it quicker for readers to find them. {{u|Sdkb}} talk 04:47, 11 April 2020 (UTC)[reply]
  • Oppose, due to both accessibility problems and I don't believe an extra click is required on the side bar, which is designed for easy navigation around Wikipedia. An extra clicking step defeats the purpose, (and there's so much room!) Utopes (talk / cont) 22:23, 14 April 2020 (UTC)[reply]
  • Oppose any collapsing option, these are meant to be quick links. — xaosflux Talk 22:28, 14 April 2020 (UTC)[reply]
  • Oppose As an editor, I would constantly be using an extra click, which would drive me nuts. I'm with Tony: if it ain't WP:BROKE don't make it more complicated The only way I might support would be if you could turn it off in preferences, but that sounds like more coding and back-end work than is needed. Addendum: I would also support if it were only auto collapsed for logged out users, if that is technically feasible. CaptainEek Edits Ho Cap'n!⚓ 22:09, 17 April 2020 (UTC)[reply]
  • Not helpful in the least. ~ Amory (u • t • c) 10:31, 20 April 2020 (UTC)[reply]
  • Oppose, might rename the section and move it down, but it should not be hidden. Renata (talk) 08:36, 21 April 2020 (UTC)[reply]
  • Out of scope. WMF has a separate effort looking at the design and behaviour of the sidebar, this RFC is meant to be about content only. Also, design philosophy of current Vector is to put all the things out in the open (compare user links – name, Sandbox, Preferences, … – at top right which are also not hidden in a drop-down). A single collapsible section feels out of place, would want all headings collapsible for consistency. Pelagic (talk) 20:32, 21 April 2020 (UTC) Edited Pelagic (talk) 00:22, 23 April 2020 (UTC)[reply]
  • Support for logged-out users only: While I believe they should be shown by default for editors, they're of no use to the average reader. —pythoncoder (talk | contribs) 21:40, 25 April 2020 (UTC)[reply]
  • Strong oppose. You're saying you want editors to have to expand the tools menu every time they want to use it? Sure, it's one click, but that's one extra inconvenience every time I want to use it. There is no usability issue with leaving it open and I get the feeling this change would quickly reverted once the entire editor base experienced it.
    Support for logged-out users only per nominator.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
    @5225C: My intention is that most active editors would choose to keep the sidebar expanded by default, so it would be no different than now. Would you be open to supporting this for logged out users only, as per PythonCoder above you? {{u|Sdkb}} talk 04:33, 27 April 2020 (UTC)[reply]
    Yes, I've missed that. Thanks.
    5225C (talk • contributions) 04:53, 27 April 2020 (UTC)[reply]
  • Oppose, I feel it won't look very "beautiful", if you get what I mean. Renaming it so that people would know the tools aren't intended for them would be better I think.--YTRK (talk) 13:28, 27 April 2020 (UTC)[reply]
  • Out of scope - this is major UX work that shouldn't be included in this RfC. I would rather see WMF's proposal for skin changes, or a dedicated proposal with actual UX rationale and implementation details. --MarioGom (talk) 20:57, 27 April 2020 (UTC)[reply]
  • Oppose Major loss of discoverability and convenience for only a very marginal improvement in appearance. -- The Anome (talk) 15:22, 29 April 2020 (UTC)[reply]

Discussion (collapse Tools)

edit
  • Wouldn't this problem be solved simply by renaming it "Editor tools"? I acknowledge that it would make it look like there's a wall between readers and editors, but I contend that that wall already exists and this merely makes it visible, with the addition of not forcing readers to feel like they need to worry about this section. I'm neutral on the specific proposal to collapse. —⁠烏⁠Γ (kaw) │ 22:56, 10 April 2020 (UTC)[reply]
  • Neutral I would support this for logged out editors if there was a way to have it autoexpanded by preference or for logged in editors. It is very useful.--Tom (LT) (talk) 00:14, 11 April 2020 (UTC)[reply]
  • Neutral per Tom, I would like to see it collapsed for logged out users and autoexpanded for me. buidhe 23:38, 12 April 2020 (UTC)[reply]
    @Tom (LT) and Buidhe: collapsing only for logged out users would be fine by me. Is there someone we could ping who might know how technically feasible that is? {{u|Sdkb}} talk 19:17, 13 April 2020 (UTC)[reply]
  • Opposers @Johnuniq, TonyBallioni, Wugapodes, SD0001, Utopes, Xaosflux, and CaptainEek: Would you be willing to support collapsing only for logged out users? If so, would you mind noting this in your !votes? This division covers 99% of non-editing readers and removes 99% of active editors, and the tools in this section are basically 100% useless to users who do not actively edit. (For enticing readers to edit, the soon-to-be "contribute" section will be far better, whereas the tools section links are terrible for newcomers, and the contribute links will be more noticeable if the tools section is collapsed.) {{u|Sdkb}} talk 02:16, 20 April 2020 (UTC)[reply]
    • No. I don’t see the point of any of this. That’s more complicated. The more complicated things are the easier it is for there to be issues. TonyBallioni (talk) 02:19, 20 April 2020 (UTC)[reply]
    • I know people are looking for things to do in these difficult times, but fiddling with the sidebar is not helpful. Wikipedia is and should be focused on content, not design. A key point is discoverabiity: in principle, someone could click all the expand buttons and eventually discover what is possible, but it's actually a lot better to leave the discoverable items expanded because most people have worked out that websites which hide content with beautiful design don't actually have any content and it's not worth clicking those useless buttons. What benefit will come from all this discussion? Johnuniq (talk) 02:24, 20 April 2020 (UTC)[reply]
    • No, just checks out a page as a logged out user, I don't see any benefit of adding a collapsing section there - it is very easy to ignore that part, and one thing that is very reader useful is in there: "Cite this page". — xaosflux Talk 02:43, 20 April 2020 (UTC)[reply]
  • To see drop-down menus done well in a design that's responsive to different window sizes, try Timeless. Contrast the mobile app, where the space on the left is used for ToC navigation instead. Intead of addressing a single section of one design, let's consider some bold alternatives! (but outside of this RFC) Pelagic (talk) 00:19, 23 April 2020 (UTC)[reply]
  • I agree that the sidebar should be very different and much shorter for logged out users. Almostall ofthem have not come here to write anything., tho they may want to print something or to contribute funding. DGG ( talk ) 22:51, 19 May 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Changing tooltips

edit

Most of the links in the sidebar feature an additional tooltip that appears when the cursor hovers over the link. These tooltips contain explanations for the functions of their respective links, and are useful for accommodating all types of readers and editors who may be unsure about what a page does before they follow the link. These proposals outline potential changes in the wordings of the tooltips.

Comprehensive overview

edit
Link Current tooltip Ok? Proposed changes[needs update]
Main page Visit the main page [Alt-Shift-z] Green tickY
Contents Guides to browsing Wikipedia Green tickY
Featured content Featured content – best of Wikipedia Red XN The best content of Wikipedia
Current events Find background information on current events Red XN Articles on current events
Random article Load a random article [Alt-Shift-x] Red XN Visit a random article
Donate to Wikipedia Support us Red XN Support us by donating to Wikipedia
Wikipedia store Visit the Wikipedia store Red XN Support us by purchasing Wikipedia merchandise
Help Guidance on how to use and edit Wikipedia Green tickY
About Wikipedia Find out about Wikipedia Red XN Learn more about Wikipedia and how it works
Community portal About the project, what you can do, where to find things Red XN The hub for editors
Recent changes A list of recent changes in the wiki [Alt-Shift-r] Red XN A list of recent changes made by editors [Alt-Shift-r]
Contact page How to contact Wikipedia Red XN Contact Wikipedia editors and report issues
What links here List of all English Wikipedia pages containing links to this page [Alt-Shift-j] Green tickY
Related changes Recent changes in pages linked from this page [Alt-Shift-k] Green tickY
Upload file Upload files [Alt-Shift-u] Red XN Add images or other media for use on Wikipedia [Alt-Shift-u]
Special pages A list of all special pages [Alt-Shift-q] Question? ??
Permanent link Permanent link to this revision of the page Red XN Permanent link to this revision of this page
Page information More information about this page Red XN Statistical information about this page
Wikidata item Link to connected data repository item [Alt-Shift-g] Question? ??
User contributions A list of contributions by this user Green tickY
Logs View the list of actions by this user Red XN A list of logged actions by this user
Email this user Send an email to this user Green tickY
View user groups <none> Red XN ??
Mute preferences <none> Red XN Mute emails or notifications from this user
Download as PDF <none> Red XN Download this page as a PDF file
Printable version Printable version of this page [Alt-Shift-p] Green tickY

General tooltip discussion

edit

@Renata3: Thanks for delving into this! I'm wondering, do you think there are any links that don't have a keyboard shortcut that ought to? {{u|Sdkb}} talk 10:05, 21 April 2020 (UTC)[reply]

Featured content tooltip

edit
There was consensus for "The best of Wikipedia". This consensus is moot as there was consensus to remove. Barkeep49 (talk) 02:10, 4 June 2020 (UTC), --DannyS712 (talk) 03:01, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Featured content tooltip, which currently reads "Featured content – the best of Wikipedia", is the only tooltip on the sidebar that separates the name of the link and its purpose with an en dash. While many of the tooltips are redundant to the names on the sidebar, no other link in the sidebar has a tooltip in the format of "Title – Purpose". With this being said, I propose that the tooltip be changed to read "The best content of Wikipedia". The associated MediaWiki page is MediaWiki:Tooltip-n-featuredcontent.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current events tooltip

edit
Further discussion is needed to determine consensus owing to limited participation. Barkeep49 (talk) 02:10, 4 June 2020 (UTC), --DannyS712 (talk) 03:01, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current events tooltip is oddly specific. "Find background information"? This implies that there are no articles about the actual current events. Propose to simplify to "Articles on current events".

  • Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)[reply]
  • I'd prefer Articles related to current events, since "on" seems to imply that we're writing news articles, which we're not, especially in cases like recent deaths. Support either over status quo, though. {{u|Sdkb}} talk 09:24, 21 April 2020 (UTC)[reply]
  • Weak Oppose both. While we technically have articles about current events, we don't really have "articles" about current events. It's important to note that Wikipedia is not a reliable source, as it can be edited by anyone. Therefore, all we have is information, and we should continue to describe it like so. (My oppose is weak because I agree that "find background information" is not the strongest wording. Do keep in mind that the current events link targets a portal, and not just a list of articles on or related to current events.) Utopes (talk / cont) 16:31, 21 April 2020 (UTC)[reply]
  • Support "Articles related to current events", as we don't actually have coverage of recent events in the style of Wikinews.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Random article tooltip

edit
There is consensus for "Visit a randomly selected article". Barkeep49 (talk) 02:11, 4 June 2020 (UTC), --DannyS712 (talk) 03:01, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is no article being "loaded", and is the only tooltip to use this language. I propose "Visit a random article" instead, or perhaps "Visit a randomly selected article". I have more of a preference towards the latter, because the former may give off the impression that the random article has already been picked and is just being delivered to you. (Plus, redundancy). Regardless, I would like to remove "load" from the tooltip.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
edit
There is consensus for "Support us by donating to the Wikimedia Foundation". Barkeep49 (talk) 02:13, 4 June 2020 (UTC), --DannyS712 (talk) 03:02, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The tooltip on this link currently reads simply, "Support us". In line with the proposed change above to rename this link "Donate", the tooltip should have further explanation; I propose "Support us by donating to Wikipedia", or a similar wording such as "[...] to the Wikimedia Foundation" (credit to Bilorv) as appropriate.

Discussion (change Donate tooltip)

edit
  • Regarding the proposals, I think it'd be more streamlined to use just "Support Wikipedia" or "Support the Wikimedia Foundation". Regarding the overall idea of redoing this tooltip, I'd like some perspective from WMF folks with marketing experience. We shouldn't let marketing incentives detract from usability/design considerations (e.g. we're not going to use giant blinking red font screaming "CLICK HERE!!!" for the link itself), but if something like "Support our vital mission" for the tooltip would lead to more engagement, I'd be fine with going with that. Pinging Quiddity (WMF) and Seddon (WMF): if possible, it'd helpful to know if you have any thoughts before this goes too much farther, as it'll be harder to change course once consensus starts to form. {{u|Sdkb}} talk 00:23, 21 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia store tooltip

edit
Moot in light of removal. Barkeep49 (talk) 02:14, 4 June 2020 (UTC), --DannyS712 (talk) 03:02, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip "Visit the Wikipedia store" is redundant and provides no new info. Suggest changing to "Support us by purchasing Wikipedia merchandise" so that it is parallel with the proposed "Donate" tooltip. (This might be mute if proposal to get rid of the link altogether goes through.)

  • Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)[reply]
  • Comment the best tooltip here is highly dependent on the outcome of the renaming discussion above. Hopefully someone will come in soon and start closing some of the more SNOWy proposals, but until then, it might be best to put this on pause. {{u|Sdkb}} talk 09:27, 21 April 2020 (UTC)[reply]
  • The WMF doesn't make money off the store, so this might be misleading. People wearing/using Wikipedia-branded items is "supporting" in a certain sense, but with this located just below the donate button, it might be taken another way. --Yair rand (talk) 17:24, 21 April 2020 (UTC)[reply]
    It could be argued that providing money for the WMF to buy merchandise for active contributors, which then boosts editor retention, is a form of support. But yeah, it's somewhat more indirect than e.g. server maintenance. {{u|Sdkb}} talk 17:55, 22 April 2020 (UTC)waiting to be nominated someday...[reply]
  • Oppose. A tooltip is not required to provide new info. It should be used to aid a reader when they're not sure what the purpose of a link is. In that regard, the "Wikipedia store" is pretty self explanatory, and the funds do not go to the WMF. Therefore, the link's function is as a way to access the Wikipedia store. To this point, I suppose that what is defined as "new info" is subjective and many of the changes that have been suggested are trivial in the whole scheme of things. But these tooltips to not need to become this long when the purpose of the link is very much clear. Also, "visit" would be consistent with other tooltips. Utopes (talk / cont) 20:23, 24 April 2020 (UTC)[reply]
  • Support per nominator.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
  • Oppose per Yair rand. Also if the link is renamed (and I think it's pretty likely), it will be providing new information.--YTRK (talk) 13:28, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

About Wikipedia tooltip

edit
There is consensus for "Learn about Wikipedia and how it works". Barkeep49 (talk) 02:14, 4 June 2020 (UTC), --DannyS712 (talk) 03:03, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip "Find out about Wikipedia" is not very helpful. We have an article on Wikipedia in the main space. It seems that Wikipedia:About describes more about how things work. Therefore, I suggest "Learn more about Wikipedia and how it works".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Community portal tooltip

edit
There is consensus for a change but further discussion is needed to establish what that change should be. Barkeep49 (talk) 02:15, 4 June 2020 (UTC), --DannyS712 (talk) 03:03, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Community portal tooltip, which currently reads "About the project, what you can do, where to find things" is somehow a violation of WP:XY, which shouldn't even apply here. This is the only tooltip that uses punctuation besides the Featured content tooltip, and gives three different ambiguous uses for the portal. One of these uses also overlaps with another link, as "About the project" could also refer to the About Wikipedia link. While the Community portal does accomplish all three of these tasks, I personally believe that it may be confusing to give this broad of a tooltip, especially one that says "what you can do", because there are hundreds of ways to help out on Wikipedia. I do not have a suggested new tooltip for this case; I just believe that this should be changed to something more concise, while also being a good definition of the Community portal.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Recent changes tooltip

edit
There is consensus for "A list of recent changes to Wikipedia". Barkeep49 (talk) 02:17, 4 June 2020 (UTC), --DannyS712 (talk) 03:03, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip "A list of recent changes in the wiki [alt-shirt-r]" introduces whole new terminology by including "wiki" (all other tooltips reference Wikipedia specifically). Also "recent changes" seem very ambiguous -- recent management changes? recent policy changes? Therefore suggest to changing to "A list of recent changes made by editors [alt-shirt-r]"

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Contact page tooltip

edit
There is no consensus for this proposal. Barkeep49 (talk) 02:18, 4 June 2020 (UTC), --DannyS712 (talk) 03:04, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip says "How to contact Wikipedia". Well, there is no "Wikipedia" to contact. Therefore, suggest "Contact Wikipedia editors and report issues"

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Upload file tooltip

edit
There is consensus for "Add images or other media for use on Wikipedia". Barkeep49 (talk) 02:19, 4 June 2020 (UTC), --DannyS712 (talk) 03:04, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip "Upload files [alt-shift-u]" is completely redundant with no greater explanation. Suggest changing to "Upload copyright-compatible files to be used on Wikipedia [alt-shift-u]" "Add images or other media for use on Wikipedia [Alt-Shift-u]" It highlights both copyright issues and purpose of the files upfront. It explains what a "file" is and what is the intended purpose of these files.

  • Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)[reply]
  • Oppose I think this gets into too much detail for a tooltip. All a tooltip should do is give someone enough information for them to figure out whether or not they want to click. If they do, then explain things like copyright at the landing page. I think the more useful thing to do here would be to explain what we mean by "files", since that may not be obvious. To that end, I propose Add images or other media for use on Wikipedia [alt-shift-u]. {{u|Sdkb}} talk 09:37, 21 April 2020 (UTC)[reply]
  • Oppose Renata's tooltip, as not everybody is familiar with copyright rules, you can technically upload non-copyright compatible files. It's like telling people that the edit tab's function is to create high quality edits; it would be preferred, but not always recognized. Support Sdkb's tooltip. Utopes (talk / cont) 15:59, 21 April 2020 (UTC)[reply]
  • Support "Add images or other media for use on Wikipedia [Alt-Shift-u]". —⁠烏⁠Γ (kaw) │ 21:27, 21 April 2020 (UTC)[reply]
  • Comment, ok, I see the point. Changed the proposal to "Add images or other media for use on Wikipedia [Alt-Shift-u]". 17:17, 22 April 2020 (UTC)
  • Support the ammended proposal per nominator.
    5225C (talk • contributions) 00:42, 27 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Special pages tooltip

edit
There is no consensus for this proposal. Barkeep49 (talk) 02:20, 4 June 2020 (UTC), --DannyS712 (talk) 03:04, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip is not very helpful "A list of all special pages [alt-shift-q]". Is there a concise way to describe "special pages" and give a clue to a user what to expect?

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
edit
There is consensus for "Permanent link to this revision of this page". Barkeep49 (talk) 02:21, 4 June 2020 (UTC), --DannyS712 (talk) 03:05, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Change "Permanent link to this revision of the page" to "Permanent link to this revision of this page". All other tooltips refer to "this" page or "this" user. It's minor, but consistency also OCD.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Page information tooltip

edit
There is no consensus for this proposal. Barkeep49 (talk) 02:22, 4 June 2020 (UTC), --DannyS712 (talk) 03:05, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip is not very helpful "More information about this page". Suggest a bit more helpful "Statistical information about this page".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikidata item tooltip

edit
There is consensus for "Structured data on this page hosted by Wikidata". Barkeep49 (talk) 02:23, 4 June 2020 (UTC), --DannyS712 (talk) 03:05, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip is a combination of the obvious and of the techno-mumbo-jumbo "Link to connected data repository item [shift-alt-g]". It's a link - duh, but the rest is a big huh?? I know about Wikidata and still have issues parsing the meaning of this. Any suggestions how to make this more user-friendly and less intimidating (particularly since clicking on the link and actually visiting Wikidata will only confuse people more)? Renata (talk) 08:48, 21 April 2020 (UTC)[reply]

Agreed that the current tooltip isn't great, but I'm not sure what to replace it with. Perhaps "link to structured data item"? That's still pretty technical, but might be a bit better. {{u|Sdkb}} talk 09:49, 21 April 2020 (UTC)[reply]
Tbh, I'm not sure sounding overly technical is a bad thing for this particular link. Agree that "link to" isn't helpful, though. --Yair rand (talk) 21:27, 21 April 2020 (UTC)[reply]

How about "Structured data on this subject hosted by Wikidata"? Renata (talk) 17:06, 22 April 2020 (UTC)[reply]

I like that! Does "this subject" cover all the use cases, or are there some namespaces where it wouldn't fit (in which case, maybe use "this page")? Overall, support. {{u|Sdkb}} talk 18:01, 22 April 2020 (UTC)[reply]
Even in the main namespace, "this subject" doesn't really work for disambiguation pages. --Yair rand (talk) 18:49, 22 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Logs tooltip

edit
There is consensus for "A list of logged actions by this user". Barkeep49 (talk) 02:23, 4 June 2020 (UTC), --DannyS712 (talk) 03:05, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current tooltip "View the list of actions by this user". Suggest "A list of logged actions by this user" for consistency with "A list of contributions by this user". Also "actions" is very vague. At least "logged actions" calls back to the page name which is "logs".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

View user groups tooltip

edit
There is no consensus. Barkeep49 (talk) 02:24, 4 June 2020 (UTC), --DannyS712 (talk) 03:06, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is currently no tooltip. Drawing a blank on how it could be described. Any suggestions? Renata (talk) 08:21, 21 April 2020 (UTC)[reply]

As with above, this depends on the outcome of the renaming discussion. But maybe something along the lines of "view the permissions of this user" would be good. For administrators, it could change to "manage the permissions of this user" if that's technically feasible, as it seems to be for the link name itself. {{u|Sdkb}} talk 09:58, 21 April 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Mute preferences tooltip

edit
There is consensus for "Mute emails or notifications from this use". Barkeep49 (talk) 02:26, 4 June 2020 (UTC), --DannyS712 (talk) 03:06, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is currently no tooltip. Suggest "Mute emails and or notifications from this user".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Download as PDF tooltip

edit
There is consensus for "Download this page as a PDF file". Barkeep49 (talk) 02:27, 4 June 2020 (UTC), --DannyS712 (talk) 03:06, 4 June 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is currently no tooltip. Suggest "Download this page as a PDF file".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A Customizable Sidebar (or an Advanced Mode)

edit

While reading the discussions here, I found some comments expressing this sort of sentiment: ‘’I often use feature "X" and would be nice to have it just one click away but, because I want to make the sidebar less intimidating for readers and beginners, I vote for removing it’’. Since the sidebar is basically a list of shortcuts and tools, why not let users choose the ones that they want and need? A sidebar that could be personalized according to each user’s preferences. This would solve a lot of ‘’problems’’. Alternatively, there could be an ‘’advanced mode’’ (similar to what we have now in the mobile version) that would display tools and shortcuts that are normally used only by advanced editors. What do you guys think? Daveout (talk) 02:38, 21 April 2020 (UTC)[reply]

I know that this may seem like a radical proposal, but I thought it was worth a shot. If you think that this doesn’t belong here let me know and I’ll remove it Daveout (talk) 02:38, 21 April 2020 (UTC)[reply]
@Daveout: I've refactored a bit to make this a discussion rather than a survey; hope you don't mind. The reason is that I think there's probably general agreement that some degree of customizability or adaptability for the sidebar is desirable; the stumbling block isn't community consensus so much as technical capability. So I hope this thread can be a place to discuss how we might want to take steps to address that. Two initial thoughts: First, this is a complex enough task, and requires deep enough access to the code, that I think it's probably best handled by the developers at the WMF. The folks at the Desktop Improvements Project might have thoughts. Second, I think we probably do want to limit to some degree that customizability, since the more customizable it is, the more complex and harder to maintain it is. Two modes, one for readers/beginning editors and one for advanced editors, seems enough. Any other modifications are likely to be extremely niche and better accomplished with a gadget. {{u|Sdkb}} talk 04:25, 21 April 2020 (UTC)[reply]
I think this could work on the various "tools". How I imagine this could work: in Special:Preferences you would be given a menu of links that can be included/excluded in your tools section (similar to the shopping list for gadgets). That obviously needs lots of coding. Renata (talk) 08:30, 21 April 2020 (UTC)[reply]
It's a great idea. Many websites have this functionality. The question is: who's going to code it? Levivich [dubious – discuss] 17:32, 21 April 2020 (UTC)[reply]
  • Every regular user cares only about some of the links, but it's different for each of us. . We need a standard set for the many users who do not wish to modify preferences , bu we also need the ability to choose what we individually need. DGG ( talk ) 05:08, 22 April 2020 (UTC)[reply]

A note on power users, usability, and systemic bias

edit

In these discussions let's keep in mind that hundreds of millions of people use en.wiki every month, and the vast majority of these people are far less tech savvy than the average Wikipedia editor commenting on this page. Functions and links that we rarely if ever use may be heavily used by the gen pop. Windows 8 was a case in point. Microsoft tracked how its users interacted with the Windows OS, and then decided to get rid of the start menu on the basis that hardly anyone used it. Well, it turned out that most people did use it, and power users who use keyboard shortcuts for everything were massively overrepresented in the pool of users who opted into the data collection.

Lots of less tech savvy people don't have the same mental models of the Internet that we do. For many, the computer is a magic box that can't be understood, and the way to get comfortable using it is to follow the same routines and workflows over and over and over again. Lots of people keep post-its on their monitor listing specific steps to access email, check bank account, etc. If one step in the instructions is no longer possible, the user gets confused and can't complete the task. Even among those who are pretty competent with tech, lots of them still have a limited grasp of the features the browser provides. I can't count how many people who were pretty comfortable using computers who had no idea that the Ctrl F/"find in page" browser functionality existed, until I showed them.

The relevance of this is that we need to think about this through the eyes of the average user, not the power user with keyboard shortcuts and custom scripts and custom CSS at their disposal. If the "print" or "permanent link" button annoys an editor, that editor can hide it with a line in their personal CSS or JS file, or through a Preferences checkbox if available. Conversely, if a less tech savvy user wants to print or cite a page, they may not realize that you can print through browser functionality hidden inside a menu that's not usually visible, or via Ctrl P. Even if they understand that you can get to a permanent link by clicking "view history", they're very likely to get confused by the literally hundreds of links on that page, with confusing and opaque linktext.

TL;DR: what seems obvious to power users is not obvious to the gen pop. Don't just think about your workflow, think about how your 70 year old grandparents would use Wikipedia. CJK09 (talk) 18:24, 22 April 2020 (UTC)[reply]

Agree. Improving the sidebar is at some level necessarily going to require making changes that users will just have to deal with adjusting to, but we should be keeping WP:READER at top of mind throughout this process. {{u|Sdkb}} talk 06:05, 23 April 2020 (UTC)[reply]

I agree decisions on sidebar links should be made with readers in mind. In fact, this is the crux of my argument for removing the "permanent link" button; it is likely to be used by only a few readers (for the vast majority, a link to a current, updated version is suitable). The bulk of its usage comes from experienced editors reporting issues. Most of the readers who want a permanent link will likely be looking to complete a citation, a function duplicated by the link to "cite this page". If we read through the ensuing discussion, many opposers are motivated by disruption to the experienced editor's, rather than the reader's, experience. – Teratix ₵ 04:32, 29 April 2020 (UTC)[reply]

Technical underpinnings

edit

Sidebar settings page

edit

Display strings

edit

Thanks for pointing out MediaWiki:Sidebar in the intro to this RFC. Entries on the right of the pipe like "mainpage-description" look like they would cause a lookup based on the user's interface language preference. Could someone say where these are stored? Is it the same for headings like "interaction"? Pelagic (talk) 22:07, 23 April 2020 (UTC)[reply]

The right hand entries are message keys. "mainpage-description" means fetch the message with that key. The fetched message will defend on the user/or site language. For instance, for French it will return MediaWiki:Mainpage-description/fr. – Ammarpad (talk)
Thanks, Ammarpad! (no ping, but Echo thanks sent from diff page) Pelagic (talk) 20:56, 24 April 2020 (UTC)[reply]
edit

Some entries in MediaWiki:Sidebar on the left of the pipe look like regular wikilinks, e.g. "Wikipedia:About", but others seem to have a level of indirection, e.g. "sitesupport-url". Where are the name-to-link mappings stored? Pelagic (talk) 22:07, 23 April 2020 (UTC)[reply]

The entries with a level of indirection are stored in the corresponding page in the MediaWiki namespace. Ex, the URL for the donate button is at MediaWiki:Sitesupport-url. * Pppery * it has begun... 01:35, 24 April 2020 (UTC)[reply]
Thanks, Pppery! (no ping, but thanked from diff page) Pelagic (talk) 20:56, 24 April 2020 (UTC)[reply]

Tools

edit

I understand that this RFC is about what we want, and that how to implement the consensus is a separate step. But I'm curious what would be involved. Tools, languages, etc. appear to come from somewhere different to the Navigation and Interaction sections. Will modifying the tools (sensu lato) require forking the Vector skin? Is there a separate file that simply specifies the sidebar tools, or will it mean diving into the HTML and PHP? Pelagic (talk) 22:07, 23 April 2020 (UTC)[reply]

The text and tooltips of the Tools links, as well as the section names, are simple Mediawiki messages that can be edited. For overall Tools content, I suspect the outcome of this will be that long-term the devs set up a system for editing Tools, and short-term we just add duplicates of the Tools links where they should go and hide the originals with CSS. (Each item has its own ID.) Changing the ordering of the sections like "In other projects" will probably need to be done on the PHP side. --Yair rand (talk) 19:02, 27 April 2020 (UTC)[reply]

Comparison to other projects and languages

edit

Moving this to a sub-page so that it doesn't swamp this one: /Comparison. Pelagic (talk) 14:13, 25 April 2020 (UTC)[reply]

@Pelagic: Thanks for putting together that comparison! Do you see any ideas from other projects/languages that we might want to adopt here, or any trends we might want to take into consideration? {{u|Sdkb}} talk 01:14, 26 April 2020 (UTC)[reply]
Good question, Sdkb. I have another table which is more informative. I'll add it later today when I get to a decent desktop PC where copying large blocks of text is more comfortable than on a tablet.
A couple of things come to mind, which will make more sense once that info is in place...
  1. Some wikis have significantly fewer sidebar links than we do at en-wp, but a lot do have similar numbers (11–14 above the tools).
    • I feel that what makes the difference between approachable and confusing is having them in logical groups, and keeping those groups small (4–5 items max). So the discussions we're having above about moving item A from group X to group Y are worthwhile, in my view. I'd also like us to seriously consider ways that we can split larger groups.
  2. Zh has a sidebar item for "Five Pillars", and a few languages (e.g. fr) have some kind of "getting started".
    • How effective is it to do single entry points for (each of) Help and About? Do people find it overwhelming when they click/tap through to those pages? Are there certain types of instruction that we want to highlight more prominently by giving them separate entries in the sidebar?
    • If you have a look at the Teahouse and Helpdesk, a lot of questions are like "how do I get my Wikipedia page?" or "how do I promote my company on wiki for the SEO?" or other fundamental misunderstandings about what Wikipedia is and isn't. Would an FAQ help? (Or is there a fundamental disjoint between the type of people (like me) who read FAQs, and the type who really should read them?) It would be useful to know how people arrive at those venues: is it via Help / About / Community Portal (and did they start from the sidebar?), or is it from welcome templates, or comments/messages from volunteers doing AFC/NPP?
I'd better leave off at this point, I've written too much already. Pelagic (talk) – (06:41 Mon 04, AEST) 20:41, 3 May 2020 (UTC) Fixed formatting. Pelagic (talk) – (06:49 Mon 04, AEST) 20:49, 3 May 2020 (UTC)[reply]
@Pelagic: I think the Wikipedias with fewer links are on the right path. Logical groupings help a bit, but the main approach I wish we would take would be autocollapsing. Unfortunately, my proposal above looks unlikely to pass (I think a lot of the opposition is a mix of not having read CJK09's excellent note above, not understanding how important reducing clutter is for good design, and not noticing that the proposal is basically only for logged out users at this point). The WMF is working on it anyways, and perhaps they'll have better luck.
Re question 2, see the proposal above to add an introduction to contributing link. I think Help:Contents is useful. WP:About is a mess that badly needs to be re-written, but there is a clear use for an introduction page for readers and it's definitely appropriate to have such a page in the sidebar. Cheers, {{u|Sdkb}} talk 21:44, 3 May 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Follow-up

edit
  Moved from Wikipedia:Village pump (proposals) § Left sidebar update follow-up

{{u|Sdkb}} talk 02:31, 7 October 2020 (UTC) [reply]

Read each section for more detailed close information:
  • Introduction page: weak consensus for Help:Introduction
  • Label and tooltip: consensus for Learn to edit as the text and Learn how to edit wikipedia as the tooltip
  • Positioning: consensus for below Help
  • Current events tooltip: consensus for Articles related to current events
  • Community portal tooltip: weak consensus The hub for editors
  • Miscellaneous proposals: no consensus
There was additional discussion below that also did not resolve into any additional consensuses. signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Requests for comment/2020 left sidebar update was recently closed by Barkeep49 and DannyS712, and most of the results have been implemented. A huge thank-you to everyone who participated! Per the close, several items require follow-up due to low participation or lack of consensus. I am opening this discussion as a space for those discussions to take place. It is being transcluded to the WP:SIDEBAR20 page and will be moved there when it concludes. {{u|Sdkb}} talk 06:47, 12 June 2020 (UTC)[reply]

Introduction page

edit
Help:Introduction narrowly has the most support, followed by WP:The Wikipedia Adventure and WP:Contributing to Wikipedia, with a few editors opining that all of the present options are bad. Specific arguments in favor of H:Introduction were that it's easy to use, looks good, and is supported by WMF. Arguments against H:Introduction were that it's too long and that it's suppported by the WMF. Supporters of The Wikipedia Adventure argued that it's more engaging and gets people actually editing quicker (one argument that it's particularly well-suited for children seems ill-considered, as there's no reason to assume that this link will primarily be used by children). Editors opposed to The Wikipedia Adventure argue that its gamified format may be offputting to some prospective editors. Supporters of WP:Contributing to Wikipedia felt that it was a better, one-page version of the information that H:Introduction tries to communicate. Editors opposed to present options suggested that we can do better, and that we should prioritize introductions that more briefly explain what Wikipedia is. In the absence of a status quo to fall back on, the outcome of this discussion is to adopt the frontrunner, although editors can continue to workshop better solutions. signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The RfC found consensus to add an introductory page for new editors, but asked for further discussion on the details.

edit

Previously discussed options: Help:Introduction (5 !votes), Wikipedia:Contributing to Wikipedia (1 !vote), and Wikipedia:The Wikipedia Adventure (1 !vote)

  • Support Help:Introduction. To put it simply, this is our best introduction. It's where the deprecated Wikipedia:Introduction now redirects and was made the primary link in the standard welcome template. It covers all the basics without going into unnecessary detail. It is mobile-friendly and accessibility-compliant. It follows the usability best practice of splitting information into easily digestible bite-sized chunks, rather than a single overwhelming page (although it has an option to be viewed as such if one wants). It's the preferred choice of the WMF Growth Team's product manager. It's being actively maintained and is overall ready for inclusion on the sidebar. {{u|Sdkb}} talk 06:47, 12 June 2020 (UTC)[reply]
Support any page that is not Help:Introduction a huge 66 page tutorial that is not user friendly. Stats show us that almost no-one is clicking the non-action action buttons to learn more so why send even more there??? . The fact someone from the WMF with less then 350 edits and zero edits in the help namespace likes the page should be a big red flag...last thing we need is another non experienced WMF member telling us what is best.--Moxy 🍁 11:14, 12 June 2020 (UTC)[reply]
The WMF Growth Team is literally the team in charge of new user retention. They're not trying to force anything on us (I was the one who sought out their opinion), but I trust that they know what they're talking about when they say We think that help pages are better when they have a fewer number of links and options -- too many can be overwhelming. In that vein, I think that WP:Contributing to Wikipedia would likely overwhelm, and Help:Introduction would be better. As for the traffic stats, most people come to the page looking for help doing a specific thing and then click on the page relevant to that. Since there are 13 pages linked, of course none individually will be getting as much traffic as the portal. There's also the general 1% rule of the internet to consider. Even the custom-designed newcomer tasks feature only results in 9% of newcomers coming back after 3 days (compared to a baseline 4-5%), so keeping them around is a huge challenge. The stats for the Wikipedia Adventure are similar, and while we don't know how many people who visit WP:Contributing to Wikipedia actually read to the bottom of the page, my guess is that it's shockingly low. {{u|Sdkb}} talk 15:25, 12 June 2020 (UTC)[reply]
Yup same team that brought us VE.--Moxy 🍁 15:32, 12 June 2020 (UTC)[reply]
The team was formed in 2018, so no. {{u|Sdkb}} talk 15:58, 12 June 2020 (UTC)[reply]
I guess I should have been more specific..old timers will understand--Moxy 🍁 17:35, 12 June 2020 (UTC)[reply]
  • Support Help:Introduction. Although I don't disagree it is quite voluminous, it covers all the necessities in a fairly well-structured manner and I used it myself for getting started.
    5225C (talk • contributions) 13:02, 12 June 2020 (UTC)[reply]
  • Support Wikipedia:The Wikipedia Adventure as I did in the previous discussion. I'm aware of accessibility criticisms and I'm even aware of data that suggests TWA doesn't improve editor retention (though I can't find the place where I read that a few years ago). However, the purpose of the link should be to get people thinking about becoming an editor—it's before the retention period, the part where we need to show them something just interesting enough to get them to make an account. I don't want another dry link with 400 subpages, none of which actually give me something to start editing or give me enough information to have my first edit not be immediately reverted. Barring TWA, I don't believe we have a page suitable for purpose but I would support Help:Introduction as a second and support any other page as better than nothing. — Bilorv (Black Lives Matter) 13:21, 12 June 2020 (UTC)[reply]
  • Support Wikipedia:Contributing to Wikipedia Its a one page, one stop wonder. Already well trafficked, lots of videos (which new users are always asking for), and long enough to be actually useful. I would also support Help:Introduction to Wikipedia, but would strongly oppose just Help:Introduction, as it is full of ...meaningless links for newbies, and already confuses folks with the VE/source distinction, and there are plenty more useful pages. CaptainEek Edits Ho Cap'n!⚓ 14:39, 12 June 2020 (UTC)[reply]

— Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diff)

I informed all that were in prior discussions even the ones that like your page. If I missed any fell free to inform..--Moxy 🍁 17:35, 12 June 2020 (UTC)[reply]
With 50 views a day its clear most do not send people there. The Wikipedia:Adventure has more then a 50 percent drop in views by the second page....with a loss of 90 percent by page 3. Not as bad as Help:Introduction but close.--Moxy 🍁 17:42, 12 June 2020 (UTC)[reply]
  • Support Wikipedia Adventure as I think Bilorv makes the best case. As the most prominent link for readers, we want to convert them to editors as fast as possible. For all the problems of TWA, it's best feature is that it gets readers editing quickly without having to read an entire manual. We can fix the other problems as we go along, and with added urgency given its prominent placement. Support the others as better than nothing. — Wug·a·po·des​ 19:18, 12 June 2020 (UTC)[reply]
  • Support Wikipedia:TWA. It's where I'd send new editors, without a doubt; it's clear, concise, to-the-point, and engaging as a tutorial of how the site works technically as well as in policy, working with both in a hands-on environment. This approach is well-tested on other sites - indeed, it's what the onboarding experience looks like on many popular social media platforms - and it works in keeping people engaged throughout, making people less likely to skip the "boring policy bits" because they're actively doing something. Naypta ☺ | ✉ talk page | 19:43, 12 June 2020 (UTC)[reply]
    @Naypta, Wugapodes, Interstellarity, and Bilorv: I tried TWA recently and had high hopes for it, since the graphics are definitely nice and the interactivity is a plus. But I came away from it concluding that there are just too many problems, and those problems are too hard to address given how rigidly it's built. To list them out:
    • The JavaScript that keeps track of where you are is very buggy; several times it lost my place and I had to go back to the start of the module. Every time that happens, it's a potential exit point for someone to decide to give up.
    • It displays terribly on mobile, which loses us half of all potential editors right off the bat (and probably more in developing areas).
    • It's not accessibility-compliant, which introduces further issues of discrimination.
    • It's longer than Help:Introduction without really covering anything important that H:I doesn't, and it doesn't touch on all the most important things right off the bat the way H:I does. I don't think most newer editors will have that much patience.
    • There's no instruction on VisualEditor, and while that may not be what we all use, for newer editors it's a very important transition aid.
    • The juvenile tone seems to be okay with some people but very off-putting to others. We can be friendly without being juvenile, and I think H:I strikes a better balance.
    Putting all those together, they add up to a dealbreaker for generalized use, and they would require a ton of work to solve. By comparison, expanding the sandbox elements for H:I into something more fully interactive would not be hard (I might work on it later today). {{u|Sdkb}} talk 20:34, 12 June 2020 (UTC)[reply]
    As I said in my original comment, I'm aware of its problems. These are all things that can (and should) be fixed. Despite that, the most important function of this link is getting readers to make an edit, not teaching them rules. For its problems, TWA's really good at that. — Wug·a·po·des​ 20:47, 12 June 2020 (UTC)[reply]
    @Wugapodes: I agree on that point. I think the very best thing is to present newcomers with easy edits to make on Wikipedia itself, since it's infinitely more satisfying to make a live edit than one to a sandbox. That's what the Newcomer Tasks feature the WMF is developing will hopefully do extremely well, and we'll want to integrate it once it goes live. For some things, though, a quiz/sandbox environment is best. I've opened up a discussion at H:I and we'll work on adding more of those features; help is welcome from anyone who wants to contribute. Cheers, {{u|Sdkb}} talk 21:25, 12 June 2020 (UTC)refactored 22:42, 12 June 2020 (UTC) to link to discussion[reply]
    @Sdkb: I think the points you raise here are definitely important ones. It ought to be possible for an interface admin to add code to MediaWiki:Guidedtour-tour-twa1.js that would automatically redirect mobile users from TWA to H:I, and for accessibility, it might be a good idea to add markup to the top of the page offering H:I as a more accessible alternative. One other option might be to have a choice - something like the below:Welcome to Wikipedia! Would you like to read a short, accessible introduction to editing Wikipedia, or learn interactively how to edit Wikipedia by taking a tour of the site?
    That could then redirect mobile users automatically to H:I as described above. Naypta ☺ | ✉ talk page | 21:22, 12 June 2020 (UTC)[reply]
    Closer's note: I had to remove a template from the above comment because it was interfering with archive templates. The code of the original comment was {{Quote frame|{{fake heading|sub=1|Welcome to Wikipedia!}}Would you like to '''read a short, accessible introduction to editing Wikipedia''', or '''learn interactively how to edit Wikipedia by taking a tour of the site'''?}} signed, Rosguill talk 22:22, 21 September 2020 (UTC)[reply]
  • Support Help:Introduction - TWA's format makes it difficult for a new editor to jump to exactly the information they need. Plus, the whole concept of an interactive "adventure" would be offputing and distracting for many newcomers. While Help:Introduction is far from perfect, it is clearly the better option, and it's a lot easier to iterate on and improve. - Axisixa T C 22:00, 12 June 2020 (UTC)[reply]
  • The proposals are dreadful—design-by-committee with every second word linked and pointless decorations. • Help:Introduction might be ok if each button led to a single page of information. However, few people want to dive into a labyrinth where you never know if you've missed vital points, and later you can never find anything you vaguely recall seeing. • WP:TWA would be suitable for, umm, certain levels of potential editors but a sidebar link should be for useful information you might want to see more than once. • Wikipedia:Contributing to Wikipedia is the best but has too much waffle. There should be a short page with core facts and many fewer links (something that can be searched after a first read), with links to the proposals here. Johnuniq (talk) 01:52, 13 June 2020 (UTC)[reply]
H:E is shorter then WP:CTW and just about additions ...not sure why so many think new editors will read over 50plus pages to learn anything considering the data we have about them ...odd very odd to me.-Moxy 🍁 12:23, 13 June 2020 (UTC)[reply]
  • Only support something that makes it clear in the first few sentences that Wikipedia is an encyclopedia based upon what reliable sources say about a subject and that editors' opinions and knowledge/expertise are not to be used. This could be followed by something short about reliable sources, being a mainstream encyclopedia and about original research. Doug Weller talk 11:15, 14 June 2020 (UTC)[reply]
  • Support Quickstart – not sure about anybody else, but I just try out my new phone, program, tv remote, without reading the manual, or only after briefly scanning it. Maybe later, after I can't turn the phone off, or find Netflix, will I go to the manual (and then, slightly annoyed that the user interface is so poorly designed, that it isn't self-evident). I support an introduction that can fit on 3/4 of a laptop page and takes about a minute to scan. As a new Wikipedia editor, I just want to edit something, anything, to see how it works, and then learn by doing; not spend time reading endless explanations, and trying to remember what I read forty pages ago, and whether that was more important. I'll get to reading all that later, after I've got some experience. Remember learning to ride a bike? The manual is for explaining how to adjust your seat height, attach a lamp, or change a tire; it's not about teaching you how to ride on two wheels. Mathglot (talk) 09:35, 16 June 2020 (UTC)[reply]
    @Mathglot: The first content page of Help:Introduction, Help:Introduction to Wikipedia, is basically what you're describing. {{u|Sdkb}} talk 10:22, 16 June 2020 (UTC)[reply]
  • Support Wikipedia Adventure great for younger editors. — 104.249.229.201 (talk) has made no other edits. The preceding unsigned comment from a Canadian IP address was added at 05:50, 17 June 2020 (UTC).[reply]
  • Support Help:Introduction it is easy to use and looks good. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)[reply]
  • Update: Following up for those here who haven't clicked through to the Help:Introduction discussion, we've added a slew of interactive components, including custom sandboxes, quizzes, and invitations to make easy live edits to articles through tools like Citation Hunt. We're planning on adding a few more quizzes, and as mentioned above the interactivity will get a further boost once the new Growth Team features are implemented, but I hope the present efforts will be enough to satisfy the concerns of some of those who opted for TWA above and perhaps resolve the deadlock we seem to currently be at. {{u|Sdkb}} talk 06:11, 1 July 2020 (UTC)[reply]
  • Support Help:Introduction, other pages have too many paragraphs, poor structure, and are too daunting. It keeps annoying me how we have dozens of introduction/"read this" pages, which are all so long, and then we try to create simplified versions of these but they're also so long, but also not comprehensive enough so you end up needing to read the even longer one anyway. Help:Introduction pretty much gets the point across and looks less scary. And as a sidenote, would like to say thanks to Sdkb's for their broad and important work to make Wikipedia easier to access for new editors. ProcrastinatingReader (talk) 13:04, 6 July 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Label and tooltip

edit
The result of this discussion was broad support for Learn to edit as the text and Learn how to edit wikipedia as the tooltip signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Previously discussed label options: "Tutorial" and "Editing tutorial". Previously discussed tooltip option: "Learn how to edit Wikipedia".

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Positioning

edit
Consensus for placement below "help" with 5 suppporting and 1 editor for above help. signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Previously discussed option: Contribute section, just below Help.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Current events tooltip

edit
"Articles related to current events" received unanimous approval from four editors this time around signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Previously discussed options: "Find background information on current events" (status quo, 0 !votes), "Articles related to current events" (2 !votes), and "Articles on current events" (1 !vote).

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Community portal tooltip

edit
"The hub for editors" has weak support, despite editors having mixed feelings about that tooltip in the prior discussion. No alternatives have been suggested. Given that this has already been raised for discussion twice, I think that the current weak consensus will serve for the time being, pending someone objecting strongly. signed, Rosguill talk 22:09, 21 September 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Previously discussed options: "About the project, what you can do, where to find things" (status quo, 0 !votes) and "The hub for editors" (2 !votes)

  • Support "The hub for editors". This concisely sums up the portal's role. {{u|Sdkb}} talk 06:47, 12 June 2020 (UTC)[reply]
  • Weak support for "The hub for editors", since I have no viable alternative.
    5225C (talk • contributions) 13:02, 12 June 2020 (UTC)[reply]
  • Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:15, 15 June 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Miscellaneous discussion

edit
No consensus for proposals made in this section. Editors were roughly evenly divided on the suggested proposals

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

See also: Wikipedia talk:Requests for comment/2020 left sidebar update
  • There were several other proposed tooltip changes that got very little discussion and closed as no consensus. I don't want to overwhelm this discussion by creating a section to follow up on each of them, but I'll just throw them out here, and if they turn out to be uncontroversial, perhaps we can find consensus to implement them. They are:
  • For Special pages, change from "A list of all special pages" to "List of automatically generated pages for specialist purposes"
  • For Page information, change from "More information about this page" to "Technical information about this page"
  • For View user groups, change from nothing to "view the permissions of this user" (for non-admins) and "manage the permissions of this user" (for admins)
How do those sound? {{u|Sdkb}} talk 06:47, 12 June 2020 (UTC)[reply]
  • The suggested extra wording for special pages and page information does not help, the original wording is good. For user groups, I don't see why different text for admin/non-admin users is needed, just "Permissions of this user" would be fine (that's all that is needed for a hint about what groups do). Johnuniq (talk) 07:27, 12 June 2020 (UTC)[reply]
  • I concur with Johnuniq regarding special pages. Although the current tooltip is pretty useless, the proposal seems far too long. I would instead propose "List of pages for specialised purposes" to cut out some unnecessary elaboration and to clarify that special pages are for particular uses, not particular users.
    I support the proposed changes for page information and user groups, they seem to clarify their respective purposes quite well.
    5225C (talk • contributions) 13:02, 12 June 2020 (UTC)[reply]
  • I'd like "List of system pages" for "Special pages", because that's effectively what it is. Support the other suggestions. Naypta ☺ | ✉ talk page | 19:46, 12 June 2020 (UTC)[reply]
"List of system pages" sounds good to me. {{u|Sdkb}} talk 06:31, 22 June 2020 (UTC)[reply]
  • Support all three: "A list of automatically generated pages for specialist purposes" ,"technical information about this page", and "view the permissions of this user." All three proposals make it more clear and are more accurate about what the targets do. In the past I have been confused by the titles and I think these tooltips would have helped. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
edit

@Sdkb: All of the discussion on the sidebar has been about the sidebar in desktop view. I think we should also discuss how we can improve the sidebar in mobile view. Do you have any opinions on how we can do that? Interstellarity (talk) 20:49, 12 June 2020 (UTC)[reply]

Interstellarity, I think we could certainly have a discussion analogous to WP:SIDEBAR20 for mobile. My sense is that the WMF has been more heavily involved with that than they have been with the desktop view, so it might be good to start at the idea lab and research the background. There are also other discrepancies such as the fact that mobile makes it very easy to see a user's edit count whereas desktop mostly hides it; we could talk more about those at WP:Usability. {{u|Sdkb}} talk 21:32, 12 June 2020 (UTC)[reply]

Tidying up the sidebar

edit

I recently had an edit request declined at MediaWiki_talk:Sidebar#Protected_edit_request_on_12_June_2020 that should tidy up the sidebar a little bit. I think it is best that we seek consensus for this change. Pinging @MSGJ: if he would like to comment. Interstellarity (talk) 11:08, 19 June 2020 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/2020_left_sidebar_update&oldid=1197940482"