Sharing a request for feedback made by @MMiller (WMF): of the WMF Growth team, who is working on features to increase new editor retention:
Screenshot of suggested edits module in Czech Wikipedia
Over the last year or so, the Growth team has been piloting features in small Wikipedias meant to increase productive edits from newcomers (such as the "suggested edits module" shown here). As our features become more developed, we're planning on expanding to larger wikis, and so I created this project page on English Wikipedia, looking to gather thoughts from English Wikipedians who think about new editors. I hope some of you can check out that page and leave any of your thoughts on the talk page, so that as we think about deploying features to bigger wikis, we'll take your ideas and concerns into account.
The latest idea we're thinking about is called "structured tasks". The idea builds on our previous work of task recommendations for newcomers, but is geared toward breaking down simple editing workflows (like copyediting or adding wikilinks) into steps that are easy for newcomers to accomplish, potentially assisted by algorithms. We are asking for thoughts and opinions on the project here on the talk page. I hope to see some of you in the conversation! -- MMiller (WMF) (talk) 01:18, 19 May 2020 (UTC)"
One of the least user-friendly areas of Wikipedia is the page histories. I assume that this is controlled to a large extent by more global interface stuff. Does anyone know where we might be able to go to discuss improving it? {{u|Sdkb}}talk22:48, 19 May 2020 (UTC)[reply]
SD0001, it really needs a top-to-bottom overhaul. The whole using the circular buttons to find revisions to compare thing is not intuitive at all, nor is "prev" and "cur". {{u|Sdkb}}talk02:21, 11 September 2020 (UTC)[reply]
SD0001, hmm, that's interesting; thanks for the link! Thinking about this, it's really something that'd probably best be handled by the WMF, so maybe the route to go is asking for it from them. {{u|Sdkb}}talk21:51, 27 November 2020 (UTC)[reply]
Does anyone else feel constrained by the limited number of skin choices available here? I just counted five, six if you count both Vector and Legacy Vector. All of them are traditional black text on white background. I'm a fan of Mediawikiwiki:Skin:DarkVector and have helped develop it a little. Is there some reason we can't have access to ten or fifteen skins? What would it hurt? Flounder ceo (talk) 16:44, 4 December 2020 (UTC)[reply]
The more skins there are, the more complexity there is and the more work it is to maintain everything. What I'd like to see is not more skins but just better skins—the old ones imo are truly awful and it'd be much nicer to see options like Dark Vector or others based around Vector with some minor style or color tweaks. {{u|Sdkb}}talk18:48, 4 December 2020 (UTC)[reply]
I wouldn't miss Modern if it went away but I've met some people who like it. Except for Vector and MinervaNeue, I think most skins are maintained by volunteers. Flounder ceo (talk) 19:07, 4 December 2020 (UTC)[reply]
You can also start your new article at Special:Mypage/WikiProject Usability. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready.
I proposed a visual change, which was briefly implemented and then undone when an editor objected, so I am seeking further community input. Should we change the notice to look like this? (The color and icon are modified, but the text is not.)
You can also start your new article at Special:Mypage/WikiProject Usability. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready.
Support as nom. This notice is quite important and something we very much want editors to read, but its current plain white format doesn't draw any attention to it. Both the color change and restoring the icon will help make it more noticeable. I chose green because, to the extent Wikipedia has a style system, it seems to be the color used for friendly information and instructions, as at {{doc}} or {{instruction editnotice}}. {{u|Sdkb}}talk20:44, 22 December 2020 (UTC)[reply]
opppose changing the color per my previous comments at the talk page. It's incredibly distracting, particularly for experienced editors who don't need a glaring reminder and perhaps it's the cynic in me but I don't think that most people will pay attention just because of the color, considering they don't pay attention to most of the bright red notices. It's almost unfriendly (I know, ironic I am saying that). I would not be opposed to this if we could basically automatically opt-out extended confirmed+ editors since this isn't targeted toward anyone but newbies. PS: If it ain't broke don't fix it. GRINCHIDICAE🎄20:49, 22 December 2020 (UTC)[reply]
Praxidicae, I'd be fine with limiting the more noticeable coloring/icon to non-extended confirmed editors. To do that, we'd need to add a bit of code to a back-end CSS page, which would allow us to hide wikitext from non-EC editors. That missing bit of code actually came up a week ago in an entirely different circumstance, and a request to interface admins to add it is pending here. {{u|Sdkb}}talk23:13, 22 December 2020 (UTC)[reply]
Hmm Personally, I didn't notice it had changed. Agree with Sdkb that we want newbs to see it, read it and take note; agree with Grinchy-Prax that changes like that can be jarring for experienced editors. Would keeping the icon but ditching the background colour be a reasonable compromise? (FWIW, I find the spelling 'color' more jarring than the actual change in colour we're talking about :P) GirthSummit (blether)20:57, 22 December 2020 (UTC)[reply]
Weak support. It looks like a small improvement to me, but I'm not sure how effective would it be. Anbyway, Sdkb: you may want to announce this RfC at the village pump. It wouldn't be the first time that the outcome of an RfC is fully dismissed by other editors because it was done at a WikiProject. --MarioGom (talk) 09:10, 4 January 2021 (UTC)[reply]
If we were to use ambox colors (not necessarily design), I'd say that this is actually a Blue Notice rather than a green (which isn't implemented in that system, so that's one point against green). --Izno (talk) 06:30, 8 January 2021 (UTC)[reply]
Some comments, mostly about accessibility. Is there anything that demonstrates that many new editors aren't paying attention to the original version? Possibly this is a solution for a problem which doesn't exist (I don't mean this as a criticism, I'm simply well aware that brains absolutely love to make solutions). Next thing, I checked these two on web version, the original is very hard to distinguish from any surrounding text, so the border present in the green version is preferable there.Also, I checked this on a couple colourblind simulators, and it seems good to go (although I'm not certain if the green bg and blue links is an issue for dyslexia). Although I also have ADHD, I personally don't have the same issues with disruptive colours that Praxidicae has; however, given the wide range of experiences w/ ADHD, that's not super surprising. Regardless, it has been raised as an ADHD accessibility barrier, which should be taken seriously. I want to note as well that some people with autism may also be thrown off by strong colours I'm not sure how each of these would get read out by a screen reader, but if one is less long/has less irrelevant things that will be read out, then that would be preferable. I would support if the above idea where more experienced editors aren't shown the colour is used. --Xurizuri (talk) 09:58, 12 January 2021 (UTC)[reply]
Xurizuri, regarding evidence that editors aren't paying enough attention to the existing notice, that's a good question to have in pose; to answer it, I'd point you to literally all of WP:AfC, which should make it pretty clear.
Regarding accessibility, Wikipedia has a lot of trouble with consistent color scheming. The shade here is the same as at {{Documentation}}, so if there's an accessibility problem with it, that should be addressed at a higher level; I'm just trying to follow the existing norm to the extent it exists. {{u|Sdkb}}talk12:44, 12 January 2021 (UTC)[reply]
I anticipate that, seeing this RfC, some editors may have other ideas about changes to make to the notice. These are welcome, but I'd prefer that they not get in the way of the discussion above, so I am carving out a space for them here.
As a basic usability best practices reminder, it is vital that we keep this notice as short and concise as possible. Yes, there are lots of things we'd like people to have in mind when creating a new page, but every line we add to this notice makes it less likely people will actually read it and thus less likely they'll click through to Help:Your first article. {{u|Sdkb}}talk20:44, 22 December 2020 (UTC)[reply]
Not that anyone ever reads that far..but would be best to link a personal sand box instead of a sandbox title that is associated with this dead project that has not reviewed an article in 8 years.--Moxy🍁13:18, 23 December 2020 (UTC)[reply]
Well, part of that might make sense: infixing "Draft:", so the entire prefix would be "Special:Mypage/Draft:...". That would make moving the page into Draft namespace a little more intuitive later. — SMcCandlish☏¢ 😼 21:54, 31 December 2020 (UTC)[reply]
If the proposed change doesn't get made, or applies only to new editors, I would suggest that the border is still valuable, to make it easier to distinguish from surrounding text in the web version for all editors. --Xurizuri (talk) 09:58, 12 January 2021 (UTC)[reply]
Where to report a Wikipedia page that violates usability guidelines?
Let's say that you find an article on Wikipedia and all of the following are true:
Some part of it breaks the usability guidelines, e.g. WP:COLLAPSE.
It is protected, semi-protected, or some other sort of "has a lock icon and you can't edit it yourself".
Posting a request on the article's own talk page for an editor who can edit the article to address the usability problem has proved fruitless, as the "local" editors just don't seem to care.
You could try posting at WT:Accessibility, but edit requests normally do attract editors from outside the local talk page, so if they don't seem to care, it might be for a reason. {{u|Sdkb}}talk02:39, 17 January 2021 (UTC)[reply]
There can be no legitimate reason for leaving an article in that state. Per Wikipedia:Manual_of_Style/Accessibility#Users_with_limited_CSS_or_JavaScript_support we have: "features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used."
Is there anywhere where one can go "over Accessibility's head", so to speak? The people there seem equally unwilling to fix the article and seem to think it's somehow within my ability to do it myself, even after I've repeatedly pointed out that it's not. The ridiculous thing is that the very day that someone's edit to the article put it into noncompliance I requested on its talk page that someone revert that edit, but instead of someone taking 20 seconds out of their time to do so it's just escalated and escalated and escalated with everyone arguing about why if I don't like it I should revert it myself. I'm pretty sure that's not the correct procedure for responding to an edit request on a semi-protected article's talk page, and it's certainly not correct for people to act like they're perfectly happy with the article the way it is when it is in flagrant violation of a long-established site-wide policy. I'm starting to wonder if it's going to require getting the actual site admins involved to get everyone back on the straight and narrow. One crack of the whip from someone with the power to hand out things like lifetime bans would surely suffice to get that policy taken seriously again ...
I'm not sure if this is to specific but it has absolutely to do with usability.
As I do graphic work I always try as hard as possible to pick colors so they work for many people with color deficiency. So to be able to mark the "images" information pages I have created a template Color_deficiency_ok to show this and to add the images to Category:Color_deficiency_ok. I hope this can be useful. --always ping me-- Goran tek-en (talk) 14:30, 20 July 2021 (UTC)[reply]
Hi, I am going through some of the talk pages for a usability case study and I am noticing some difficulty in navigation and understanding of the pages. I was wondering if editors can share your thoughts and flows as they go through the talk pages? Just looking to understand some of the pain points for people who are both new and experienced when it comes to Wikipedia talk pages/editing. If this is not the right place to ask, do let me know where I can look towards! Thanks! — Preceding unsigned comment added by Jncwtopac (talk • contribs)
Hi Jncwtopac! When I go to a talk page, I'm normally looking either to see what past discussions have been held there or to start a new discussion (sometimes after I've been reverted). There are a whole bunch of pain points. For newcomers, WP:NOTFORUM is commonly not known. For everyone, indenting is a pain, as is the lack of automatic signatures (you should sign your posts with ~~~~) and the inability to subscribe to individual sections. The Talk pages project currently being undertaken by the Wikimedia Foundation aims to address many of these issues and has released beta features; I would definitely check that out. {{u|Sdkb}}talk07:28, 12 November 2021 (UTC)[reply]
Thanks Sdkb for your comment and the links! I will definitely check out Talk pages project. Hope you don't mind a few questions! Was it difficult when you first started going through talk pages? And how has it been from when you first started to now? Also, aside from the issues, are there things you enjoy about the talk pages as you use it? Jncwtopac (talk) 08:11, 12 November 2021 (UTC)[reply]
I don't clearly remember my earliest talk page interactions. The main thing I enjoy about talk pages is just seeing the Wikipedia community at work—some talk page posts are junk, but many reflect a remarkable level of care about even minute aspects of the topic. {{u|Sdkb}}talk08:19, 12 November 2021 (UTC)[reply]
You are invited to join the discussion at Template talk:Title notice#Proposed revision to make this notice less disruptive. {{u|Sdkb}} talk 01:27, 26 April 2020 (UTC)
You are invited to join the discussion at Help talk:Contents § Small addition. {{u|Sdkb}} talk 18:47, 16 September 2020 (UTC)
GRINCHIDICAE🎄 20:49, 22 December 2020 (UTC)
