Jump to content

Template talk:WikiProject banner shell/Archive 9

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 7Archive 8Archive 9Archive 10Archive 11

Debold taskforces in collapsed view

Let's remove the bold typeface from task force names when in collapsed view. In the example above, Linguistics is the important name and "Etymology / Applied Linguistics / Philosophy of language" could be in normal weight. — Martin (MSGJ · talk) 17:06, 19 July 2023 (UTC)

I agree to this. One more thing I was thinking about is to change the separator between Project name and first taskforce name. But that might no longer be necessary if we do the debolding thing. —CX Zoom[he/him] (let's talk • {C•X}) 17:52, 19 July 2023 (UTC)
I suggest changing task force separators from slashes to parentheses & commas as well as debolding them. Example:
Linguistics (Etymology, Applied Linguistics, Philosophy of language)
It will also help with clarity if the proposal to group all WikiProjects with a given importance on the same line is ever implemented. SilverTiger12 (talk) 21:12, 22 July 2023 (UTC)
Agree on removing bold; parentheses are a good idea and should be tried in sandbox. DFlhb (talk) 22:26, 23 July 2023 (UTC)
How's that looking? — Martin (MSGJ · talk) 08:04, 24 July 2023 (UTC)
Tried with both unbolded (thru Dev Tools). Parentheses make it look busier, so I slightly prefer slashes. DFlhb (talk) 10:24, 24 July 2023 (UTC)
No problem. Will leave the commas for a bit longer to give others a chance to comment — Martin (MSGJ · talk) 12:14, 24 July 2023 (UTC)
I don't mind parentheticals or slashes but I definitely agree with de-bolding all except the base project name. — Bilorv (talk) 08:48, 24 July 2023 (UTC)


Linguistics: Etymology / Applied Linguistics / Philosophy of language

would be much better. Especially since some task forces can have commas in them. Headbomb {t · c · p · b} 13:21, 24 July 2023 (UTC)

Headbomb raised a good point. I agree that taskforces may have commas, so this one looks better. —CX Zoom[he/him] (let's talk • {C•X}) 13:33, 24 July 2023 (UTC)
Sandbox updated — Martin (MSGJ · talk) 13:42, 24 July 2023 (UTC)
 Done — Martin (MSGJ · talk) 23:30, 25 July 2023 (UTC)

Removing container=yes from members of Category:Articles by quality

It looks like this template now adds articles to a non-project specific quality class (so one of the direct subcats of Category:Articles by quality). Those are currently marked as container categories and are now popping up in maintenance reports such as Wikipedia:Database reports/Polluted categories (3). Since the changes look intentional, is there any reason not to remove the container category template from those categories? Taavi (talk!) 17:47, 27 July 2023 (UTC)

Please do, thanks. The other alternative is that we create other category like Category:Stub-Class articles without a topic for these — Martin (MSGJ · talk) 18:34, 27 July 2023 (UTC)
Is it only those articles that are not assigned any WikiProjects there? —CX Zoom[he/him] (let's talk • {C•X}) 18:37, 27 July 2023 (UTC)
That is right — Martin (MSGJ · talk) 18:43, 27 July 2023 (UTC)
Alright, then there should be a separate category for these. I can suggest Category:Stub-Class articles not assigned to any WikiProject, but that is a long category name. I support your proposal too. —CX Zoom[he/him] (let's talk • {C•X}) 18:49, 27 July 2023 (UTC)

Tense

Which tense is best?

Present Perfect
This article is rated C-class
This article is not yet rated
This article is automatically rated 		This article has been rated C-class
This article has not yet been rated
This article has been automatically rated

— Martin (MSGJ · talk) 11:15, 29 July 2023 (UTC)

Present for the first two; perfect for the third one. Nurg (talk) 00:39, 2 August 2023 (UTC)
Agreed. — Bilorv (talk) 12:26, 2 August 2023 (UTC)
Present for the first two; consider past for the third one ("This article was rated automatically.") —Carter (Tcr25) (talk) 13:25, 2 August 2023 (UTC)
Yes, that would be good. Nurg (talk) 06:19, 3 August 2023 (UTC)
Thanks everyone. The "automatic" part of this has been reworded as discussed in #Redirect-class invisible when banners inside WPBS so I thnik everything is in present tense now — Martin (MSGJ · talk) 14:36, 3 August 2023 (UTC)

Unbold shell text when class not provided

When a class is not provided to the shell, the following text appears: This article is of interest to the following WikiProjects:. I think this should be unbolded, similar to when a class is provided. —CX Zoom[he/him] (let's talk • {C•X}) 19:52, 30 July 2023 (UTC)

I think the word "not" is missing somewhere? — Martin (MSGJ · talk) 21:12, 30 July 2023 (UTC)
@MSGJ: Yup, thanks. Fixed now. —CX Zoom[he/him] (let's talk • {C•X}) 21:20, 30 July 2023 (UTC)
I think that would require a change to Template:Banner holder or Template:Banner holder/styles.css — Martin (MSGJ · talk) 21:32, 30 July 2023 (UTC)
Could you mock this up in the sandbox? — Martin (MSGJ · talk) 14:37, 3 August 2023 (UTC)

Taskforces of 'opted-out' WikiProjects not showing up when collapsed

Two WikiProjects that do not use the common class rating off top of my mind in the above example, each with tasforces that do not show up in their collapsed banners. –Vipz (talk) 02:16, 28 July 2023 (UTC)

For the video games template you would need to add the |TF_n_NESTED= parameters for this to work — Martin (MSGJ · talk) 07:41, 28 July 2023 (UTC)
I have added them for you. To clarify, this is nothing to do with opting out — Martin (MSGJ · talk) 20:13, 28 July 2023 (UTC)
@MSGJ: why does it appear to me that only WikiProjects which opted out of the common class rating have been affected with this issue? –Vipz (talk) 00:50, 30 July 2023 (UTC)
Project banners don't show taskforces in the collapsed banner by default, unless configured to do so; always been this way. DFlhb (talk) 16:17, 6 August 2023 (UTC)

Edit: commented Military history example out because |category=no does not apparently disable categories, but Video games example should suffice to demonstrate the issue. –Vipz (talk) 02:21, 28 July 2023 (UTC)

Icon for attention needed

While we've got everyone here, what would people think about having a small icon in the collapsed header for an article which has been marked as needing attention? Example in third banner below. — Martin (MSGJ · talk) 06:29, 15 July 2023 (UTC)

Good idea; I like everything except the icon. The lack of flatness clashes with all the other icons, which are flat or have only subtle bumps. Suggest using File:OOjs UI icon alert-yellow.svg ( ) instead. Edward-Woodrow :) [talk] 21:35, 6 August 2023 (UTC)
I like it. But since these aren't particularly project-specific, I suggest moving that parameter to the shell and adding a line at the bottom, below the projects, with both the icon and some text. DFlhb (talk) 08:14, 15 July 2023 (UTC)
Logic is sound but not sure I'm keen on adding an extra row to the shell template — Martin (MSGJ · talk) 17:09, 19 July 2023 (UTC)
Would be nice if this can be handle the various attention-related parameters as generally a "needs attention" is not really helpful (unlike "needs infobox", or "needs-response" and others used in Template:WikiProject Television which give a specific need that needs addressed). Gonnym (talk) 19:07, 16 July 2023 (UTC)
We could of course explore other alert icons. I was just starting with a small proposal ... — Martin (MSGJ · talk) 17:14, 19 July 2023 (UTC)
I'm not familiar with the "needs attention" system, which makes me think it's likely another relic system that isn't actually used much. If so, I'd be hesitant to build out more template infrastructure for it rather than pushing to retire it. {{u|Sdkb}} talk 21:23, 16 July 2023 (UTC)
It's mainly of interest to subject-area experts, and is not used by all WikiProject banners. When supported by a banner, and set to yes, it normally produces a line in the banner like "This article has been marked as needing immediate attention." and also populates a wikiproject-specific subcategory of Category:Articles needing attention. --Redrose64 🌹 (talk) 23:50, 16 July 2023 (UTC)
There are 220+ projects using it so it's one of the more well used features in the banner. This proposal is about enhancing an existing feature and perhaps make it used more effectively. — Martin (MSGJ · talk) 17:12, 19 July 2023 (UTC)
It took me a minute to notice in this example, so maybe left-aligning would be better. But perhaps the "needs attention" system isn't the most effective or widely used system anyway. — Bilorv (talk) 09:24, 18 July 2023 (UTC)
Then it would be in the jumble of task forces and assessment bubbles. Does it not stand out more on the right side (now that you know where to look)? — Martin (MSGJ · talk) 17:13, 19 July 2023 (UTC)
Still not—despite having seen it before, when I scrolled through this discussion again I once again missed the icon. My eyes are drawn to the left-hand side as this is where I expect information; even if clicking on "show/hide" I know where the buttons are so would only look at them peripherally in order to click and may still miss the icon. — Bilorv (talk) 08:47, 24 July 2023 (UTC)
Better now? — Martin (MSGJ · talk) 09:11, 24 July 2023 (UTC)
Yep, in my opinion this is much better. — Bilorv (talk) 12:24, 2 August 2023 (UTC)

WPBS class parameter

I want some clarification on three points:

1) If I add a class= parameter to the WPBS in, say, Talk:Typhoon Khanun (2023), can I remove the class parameters from the individual WikiProject templates? I am asking this because
2) when I removed |class=start from a certain article and added that to the WPBS, an editor re-added this to the WikiProject Yorkshire template. Apparently, he used a tool that failed to identify the class parameter in the WPBS.
3) Would removing the parameters from individual templates affect the results of the tools that produce WikiProject assessments? E.g., would Paris no longer be represented by the tools that produce Wikipedia:WikiProject Cities/Assessment if the class parameter is removed from the WikiProject Cities template?

—Nythar (💬-🍀) 22:03, 8 August 2023 (UTC)

1) Yes.
2) Unfortunately, most tools haven't yet been updated to reflect the changes. Plus, very often I come across editors who assume that removal of quality from individual banners is vandalism, as they are unaware of the changes being made here. In this case, I'd suggest that it would be best to talk to the editor. And if it is due to a tool, add it to Template talk:WPBannerMeta/to do#Scripts needing update so that we can follow up on it when the templates are finally fully ready.
3) In vast majority of the cases, it won't affect any automated processes because these (generally) rely upon the categories on the talk page, for example, Category:GA-Class WikiProject Cities articles. The updates have been made in such manner that no categories should be affected. But, if some process relies on capturing the class parameter of a template for its processes, then it may break. As this is a very inefficient way of doing things, I do not think any process makes use of it. —CX Zoom[he/him] (let's talk • {C•X}) 23:42, 8 August 2023 (UTC)

Class act

Can someone tell me why in Talk:Siege of Maastricht (1794) WikiProject France displays as C-Class although the Class card says B? Hawkeye7 (discuss) 05:30, 18 August 2023 (UTC)

Someone added the b-class checklist parameters to the custom mask even though the project doesn't use this. Should be fixed now. — Martin (MSGJ · talk) 07:18, 18 August 2023 (UTC)

August 2023 - Popular pages Bot not updating 20+ WikiProjects

Greetings @MSGJ - Today at User:Community Tech bot/Popular pages I clicked on the "Updated" wikitable column and see many WPs not timestamped for 2023-08 August monthly update. From what I recall, all those U.S.Roads entries had a problem before WPBS changes, so skip past those on the list. Wondering if all those WPs that did not update need some Template update to fix? I'm only guessing as this is far beyond my knowledge. Thanks for investigating, hoping you or another expert has a solution, as September 2023 processing is about to begin. Regards, JoeNMLC (talk) 20:45, 31 August 2023 (UTC)

@MSGJ - SORRY - Please ignore above as those WikiProjects are Inactive, my error (slap-myself-on-side-of-head). JoeNMLC (talk) 20:50, 31 August 2023 (UTC)

RFC on WikiProject Banner shell redesign

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.
The WikiProject banner shell, which is a template widely used on talk pages, has been redesigned. In this RfC, the community considers the redesign. The community isn't of one mind about this, but despite reasoned and well-argued opposition to the new version, the community does broadly support the redesign in most respects. The community doesn't love the coloured bubbles, and I give additional weight to the concern that the colours must be more accessible to colour-blind people. The new version should remain in use but should be de-coloured for the time being, unless and until we reach consensus on fully accessible colour choices. I hope this helps; any queries or concerns about this close should be directed to my talk page in the first instance.—S Marshall T/C 17:00, 1 September 2023 (UTC)

The WikiProject Banner shell has been redesigned. It now incorporates a visual identifier of the project, a shortened version of the WikiProject name, and a colour coded representation of the article class and article importance rating. The same information is presented, though with a different appearance.

This RFC is to gain feedback on the new design. Are people happy with the new design overall? Are there improvements that could be made? Are there aspects which are felt to be unnecessary? Should the Project logos/images be shown, or just the project name? Should the class and/or importance ratings be coloured? If so, are the colours suitable? To make assessing the feedback easier, people may respond by saying Support all - Support all apart from images/logos - Support all apart from colour scheme - Support apart from images/logos and colour scheme - Oppose all, except for name abbreviation - Oppose all, or any other variation. Suggestions for improvement are most welcome. SilkTork (talk) 17:56, 9 July 2023 (UTC)

Previous appearance
New appearance
Bubble color spectrum
Note that these bubbles have class="wpb-header-bubbles" set, so if you have disabled it in your user stylesheet, you will not be able to see this. If you would like to view the spectrum, feel free to copy this table, then use find&replace tool to replace class="wpb-header-bubbles" with a whitespace. —CX Zoom[he/him] (let's talk • {C•X}) 14:17, 10 July 2023 (UTC)
FA-class FL-class FM-class A-class AL-class GA-class B-class BL-class C-class CL-class Start-class Stub-class SL-class List-class Future-class NA-class
Top-importance High-importance Mid-importance Low-importance
These are inherited from the default class color that appear on expansion of banners: Disambig-class Current-class Merge-class Redirect-class Needed-class Draft-class Project-class Portal-class Template-class Category-class File-class User-class // Help-class & Mention-class (what!?, only 12 pages in entire WP) are both transparent
Discussion about RfC description
@SilkTork: I changed some of the banners in the example because they were wrongly populating WikiProject categories. WP1.0 & Vital articles do not support |category=no, so I removed them, instead I put in place WP Germany. —CX Zoom[he/him] (let's talk • {C•X}) 18:09, 9 July 2023 (UTC)
That's cool. I like the new examples as it shows a greater range of colours. SilkTork (talk) 18:11, 9 July 2023 (UTC)
I've matched both banners to make it an equal comparison; except replacing WikiProject Anarchism with Germany since the former no longer supports importance parameters. DFlhb (talk) 18:16, 9 July 2023 (UTC)
I tweaked to provide a more direct comparison (and more realistic example) for the classes. We're never going to have something rated FA/A/B/Future-class all at once. {{u|Sdkb}} talk 19:55, 9 July 2023 (UTC)
I tweaked again to show the colours on offer, and also how the banner is currently being projected across Wikipedia with the class colours being displayed. SilkTork (talk) 01:51, 10 July 2023 (UTC)
I agree with Sdkb's realism, but SilkTork is right that we need to see everything we're discussing. But I tweaked it again because one of my concerns (and presumably an increasingly common case) is when there is no project-specific class. DMacks (talk) 02:08, 10 July 2023 (UTC)
A major goal of the redesign was to reduce visual clutter. Introducing to the new appearance mockup only an unrealistic fictional scenario in which there are tons of different colors re-adds part of that clutter and prevents a like-to-like comparison between the old and new, making it an WP:RFCNEUTRAL violation. I understand the impetus, but I object to it. If people really want to see all the colors, we could link out to or add another mockup that showcases them. {{u|Sdkb}} talk 03:50, 10 July 2023 (UTC)
No objection to going back prior to SilkTork's change. DMacks (talk) 03:54, 10 July 2023 (UTC)
Agree; it should be equal-to-equal. Note that to finish implementing the February RfC, a bot run was always planned (and will be submitted to the appropriate consensus processes and central discussion beforehand, soon-ish), to transition every talk page to article class, to reduce the assessment maintenance burden on WikiProjects. At that point, the class bubbles will be hidden in almost all cases.
The individual colours for each class and importance are visible to everyone at Template:WPBannerMeta/testcases. DFlhb (talk) 06:10, 10 July 2023 (UTC)
Repetitive quality was to be eliminated since the beginning per global quality RfC. Having too many quality bubbles in the banners do not reflect the upcoming scene. Instead there could be a table with cream background, with bubbles of all quality/importance level on it for people to be able to make a choice about coloring. It must be clearly noted that such quality bubbles will only be visible on like 5%(?) of banners they see, though the importance bubbles will be more widespread and be seen on like 95%(?) banners. —CX Zoom[he/him] (let's talk • {C•X}) 06:41, 10 July 2023 (UTC)
Shouldn't we subst: the template? Just transcluding it will probably annoy future readers, who might wonder what the shell looked like when this RfC was made (assuming we make any changes to it after this is done). – MaterialWorks 21:34, 10 July 2023 (UTC)

Survey (redesign RfC)

  • Oppose all, except for name abbreviation. The abbreviation of the Wikiproject name makes sense. The small image/logo is too small to make much sense, and creates clutter. People can click to open up the fuller banner where the image/logo can be clearly seen. The colour scheme is distracting, and creates too much focus on that aspect. SilkTork (talk) 18:00, 9 July 2023 (UTC)
  • Oppose all, except for name abbreviation The name abbreviation seems good, but the rest of the design change was unnecessary and pointless. Even without considering the eye gouging aspects. The logos seem arbitrary and not useful as a signifier at a glance, which is ostensibly the purpose. SilverserenC 18:04, 9 July 2023 (UTC)
  • Support all. The previous shell had significant accessibility issues (excepting one user) which went unaddressed for years, and didn't comply with established WCAG accessibility guidelines. "If it aint broke don't fix it" mindset is harmful in this case.
The two major changes are the project icons and background colour. Both were implemented to follow WCAG guidelines. Icons are part of WCAG recommendations for cognitive accessibility. The previous background colour failed WCAG's minimum contrast for links, even though uncollapsed project banners have plenty of links; the new colour, taken from {{BLP}} (right above the banner shell on all BLPs), has good contrast. The banner used to be 100% bolded text; most of the bold was removed, and so were the unnecessary WikiProject... prefixes. The new banner lowers banner blindness and is more accessible. None of these are subjective aesthetic concerns. DFlhb (talk) 18:10, 9 July 2023 (UTC)
Wikipedia guidance on the use of icons is given at Wikipedia:Manual of Style/Icons. There are a number of accessibility issues with regards to inappropriate use of icons.
Guidance on use of colours is given at MOS:COLOR. There are accessibility issues with inappropriate use of colour.
Generally, if the information can be conveyed adequately without use of either icons or colours, that is to be preferred. Where is the argument that using text to convey information in the WikiProject banner has been a problem? SilkTork (talk) 02:18, 10 July 2023 (UTC)
SilkTork, it sounds like you are arguing against any use of icons or colours. If so, I disagree. where is the guideline against using icons or colours in addition to the text itself, so that those who can see color clearly can benefit from those added visual cues? MOS:COLOR says "Ensure that color is not the only method used to communicate important information"; it does not say "not a method", and as such it clearly does bless use of it at times. DMacks (talk) 03:03, 10 July 2023 (UTC)
  • Oppose abbreviation, left-alignment, icon and much prefer and rectangular boxes. The only way I could support left-alignment would be if class/importance were right-aligned. Otherwise the previous centered scheme is hugely better. I don't mind the lighter beige. Icons should go too. They're too tiny to be meaningful, and duplicate the bigger icon once expanded. Headbomb {t · c · p · b} 18:13, 9 July 2023 (UTC)
  • Support all, except images/logos for the reasons I gave in the section above. I'm neutral on the color scheme for the bubbles, I think it's fine as is but I won't mind if it gets reverted. The beige background feels better than the old one for me (yes, I know WP:ILIKEIT exists). EDIT (21:03, 10 July 2023 (UTC)): Oppose left-alignment too, I tried out right-alignment with some custom CSS and it looks way cleaner. – MaterialWorks 18:28, 9 July 2023 (UTC)
  • Oppose While I thank the designers for solving my particular issue, and I appreciate them agreeing to an RFC, I must oppose. This change could create harmful consequences for for people with sensory vertigo or other light/color sensitivities. Far too many small images and colors, which create a sense of everything on the page swimming, leading to dizziness, nausea, head ache, etc. If this gains support from the community at large, there must be an opt out created. For the record, I came here because I was notified of this discussion. SusunW (talk) 18:38, 9 July 2023 (UTC)
    After learning of your issues, they switched the background from white to cream, and bubble colors from bright to pastel, which should no longer cause an adverse reaction on you. —CX Zoom[he/him] (let's talk • {C•X}) 18:42, 9 July 2023 (UTC)
  • Because y'all reverted my view to the former I have no idea whether the changes would trigger me, but I do trust what you say about making changes to the color scheme. I still think it is unwise to launch without an opt out. SusunW (talk) 18:56, 9 July 2023 (UTC)
  • Oppose importance/class colors, neutral on alignment and WikiProject icons, support abbreviation and new top bar - I strongly dislike the importance/class colors (it makes the banner look extremely busy). The WikiProject iconography (as presented) is simply indistinguishably small to me beyond the flag, but I suppose that is something the WikiProjects can then handle down the line. The alignment I don't really care about either way. The new top bar (i.e. the area with "This template is rated..." and the large "C" class icon are an improvement in terms of readability, as is the abbreviation of the WikiProject title. The background color change also looks fine. -Ljleppan (talk) 18:38, 9 July 2023 (UTC)
    As an addendum, the proposed importance colors are indistinguishable from each other to me. Admittedly, I have non-normal color vision, but I just can't see the difference between the low and the medium importance, and the mid-high difference is something I can just barely make out. Ljleppan (talk) 18:46, 9 July 2023 (UTC)
    Indeed, I proposed somewhere that projects should be able to set a small picture of their choice for the summary part, which will override the large picture, if they want. —CX Zoom[he/him] (let's talk • {C•X}) 18:51, 9 July 2023 (UTC)
    Is the intent to have both icons visible when the blocks are opened? I just noticed that it looks extremely busy then, with multiple duplicates of the same image in a very small space. The Germany block, for example, has three flags, all of a different size, in a miniscule space once opened. Ljleppan (talk) 19:00, 9 July 2023 (UTC)
  • Mostly support except for importance colours Disclaimer: this is personal opinion. I mostly like the use of icons (though look a bit odd when a project is expanded). I like the reduced wording. I felt everything starting "WikiProject" didn't add value on the old appearance. I like the background colour of the projects (I would have objected to white).
I don't like the left-align or the importance colours, no colours might have been better, to reduce the total amount of colours beyond the logos. I liked the old right-align project names and left-align ratings around the centre of the old appearance. -Kj cheetham (talk) 18:41, 9 July 2023 (UTC)
P.S. Regarding alignment, I'd be happy with centre-aligned icon and project name, right-aligned ratings. Or even left-aligned icon, centre name, right ratings. Just not everything left. -Kj cheetham (talk) 19:13, 9 July 2023 (UTC)
  • Support all. The Wikiproject name abbreviations are a welcome change. The new design is less flat than the original, and now that the glaring white from the first iteration of the new design is gone, I'm happy to support it. However, there are probably some accessibility issues with the importance colors that should be addressed. ULPS (talk) 18:46, 9 July 2023 (UTC)
  • Support: I was a participant of the discussion on redesigning from the beginning till now. And I generally support all of it. I also supported a right-alignment of class & importance from the beginning, but that isn't a deal-breaker for me. —CX Zoom[he/him] (let's talk • {C•X}) 18:53, 9 July 2023 (UTC)
  • Support all, neutral on alignment/color scheme of importance ratings. Abbreviation is a no-brainer, repeating "WikiProject" six times represents more unnecessary "clutter" than anything, Maybe re-applying boldface to the work "WikiProjects" in the shell will help? Also, though the thumbnail images may not all be easily recognizable at this size, they are clearly distinguishable from each other, which has been a great help to me in recent efforts to remove/consolidate duplicate banner templates within the same shell, of which there are thousands. The comments that the old scheme is "better" and the change is "unnecessary" without specific reasons why, beyond aesthetic preference, seem to come from editors who see banners all the time but don't actually use them as part off their editing process. The message I'm getting from the "oppose all" comments here and in the previous discussion is, "We like the 20-year-old version and no one asked us before you changed it." We should be getting, "this aspect is helpful and this aspect is not."— TAnthonyTalk 18:56, 9 July 2023 (UTC)
  • Oppose left alignment as it hurts readability (move the content assessment to the right and center the header). I strongly support the new beige background color as the previous white color was very jarring and an all around terrible choice-- I do still wish the color contrast for the backgrounds be toned down more. Support the additions of logos for accessibility reasons per @DFlhb: Support abbreviation as an obvious anti-clutter decision. And ofc please let individual WikiProjects override the icon image. :3 F4U (they/it) 19:02, 9 July 2023 (UTC)
  • Oppose all. Even with the subtler colors, I find the new design distracting and a bit glaring. —David Eppstein (talk) 19:10, 9 July 2023 (UTC)
  • Oppose all except name abbreviations per SilkTork and Silver seren. The graphics do not add to comprehension of the WikiProject subject, the colors add nothing to the words which convey class (there's no natural correspondence between colors and class), and the shading differentiation for importance is not distinguishable enough to be helpful either. I think this was a case of something not being broken, and not requiring fixing. I do think the abbreviation, eliminating multiple "WikiProject"s reduces clutter. Beyond My Ken (talk) 19:12, 9 July 2023 (UTC)
  • Comment Regarding color and graphics, this level of emphasis would be appropriate if wikiproject classification and quality scores below GA were well-maintained across the board so as to be useful to the reader and not just a springboard for editors possibly interested in a topic. But very few Wikiprojects are up to that standard of organization today. signed, Rosguill talk 19:31, 9 July 2023 (UTC)
  • Support abbreviation, Oppose colour and graphics (keep the whole template as text on a single colour background), neutral on the rest, largely per Beyond My Ken. Clutter is reduced by removing the repetition of "WikiProject" but other than that the changes to something that wasn't broken are either pointless or, in the case of the graphics and colour both unnecessary and actively worse than the old design by giving undue prominence and creating distraction. Thryduulf (talk) 19:38, 9 July 2023 (UTC)
  • Support abbreviation, Oppose label design I liked the previous examples on this talk page more, where the labels had a colored outline to them rather than having the entire label be a flat color. The colors themselves are way too saturated and I'd like for it to be toned down a notch. Everything else is a welcome change as the clutter generated by repeating WikiProject forty thousand times was annoying. Deauthorized. (talk) 19:47, 9 July 2023 (UTC)
  • Keep all elements of the new design, per DFlhb. We're seeing here the unfortunate but expected resistance to any design change by editors accustomed to the old version. {{u|Sdkb}} talk 19:59, 9 July 2023 (UTC)
This argument of "expected resistance to any design change" tends to annoy as it used as a mantra by those looking to impose pointless or negative changes. I've not yet encountered people resisting clearly positive change. It is generally welcomed. So: "We are going to decease your pay and increase your workload", will encounter resistance, while "We are going to increase your pay and decrease your workload", will encounter no resistance. I am more encouraged when those who are looking to make changes listen carefully to objections, rather than brush them off in an arrogant and insulting manner with: "We're seeing here the unfortunate but expected resistance to any design change...". Consider the viewpoint reflected in the comment: "I will listen to you, especially when we disagree", as a more collegiate and responsive way of moving forward. SilkTork (talk) 02:37, 10 July 2023 (UTC)
What are you talking about? This is Wikipedia and people are nearly always opposed to large scale changes (e.g. Main Page redesign, RFA reform, unbundling tools, Pending changes, Media Viewer, Vector skin rollout, VisualEditor, Recent changes, and the list goes on). We even have a dedicated page for this. OhanaUnitedTalk page 13:22, 11 July 2023 (UTC)
  • Support all, assessment was recently changed from a project-specific valuation to an overall valuation. This template reflects that change. It's clear at a glance how the page was rated. In Wikipedia's early days when the encyclopedia needed to be populated with articles, wikiprojects were hugely active and influential. Now that's only true in certain topic areas like military history, medicine, and video games. On that note, I think the images could go, but I don't have an issue with them staying. Overall this is an improvement. Rjjiii (talk) 20:16, 9 July 2023 (UTC)
  • Support all, new design is easier to parse and quicker to reader. Aesthetic-wise it is less flat and stale as well. I don't get the "takes too much attention" argument—there is literally nothing from the original that takes any attention, and as a result these banners are completely glossed over and ignored. When there was a proposal to auto-collapse the banner, it was opposed, so the opposers have created something of a loose-loose situation here. Aza24 (talk) 20:34, 9 July 2023 (UTC)
  • Support all apart from colour scheme, very nice improvements overall. Icons, left-alignment, and removal of redundant "WikiProject" prefixes all improve indication. Importance colors should differ more greatly from each other and from the background color, for my taste. I do believe something can be done about redundancy of icons when expanded as well, and maybe give more breathing space between all the stuff on the left. –Vipz (talk) 21:12, 9 July 2023 (UTC)
  • Support all. Removing "WikiProject" obviuously reduces clutter (as others note) that is the same for every entry, which helps the eye see what the actual projects are. I have no personal feel for the icons (and generally gloss over them) but if others find an accessibility value that's a good enough basis for me to support. I find left-aligned text more efficient to read in a list. Although centering is the {{cot}} standard for titles of collapsed chunks, I see this more as a parallel list of topics than the title or one-off use for a block of material. Finally, the use of a list of highlighted words with semantic color meaning (such as gradation or traffic-light) is on par with what I see as a trend on other sites' UI, where a text field appears a list of badges or token terms. However, suggestion:
    I would propose that 'class' goes after 'importance', on the assumption that all/most entries will have an 'importance' but few will have a project-specific 'class'. That would make better visual alignment of the 'importance' and easier to distinguish the special cases of 'class'.
    DMacks (talk) 22:00, 9 July 2023 (UTC)
    Good suggestion! {{u|Sdkb}} talk 23:23, 9 July 2023 (UTC)
    I would've preferred that as well. Putting class to the left of importance was proposed because I wanted them right-aligned, so the importance will align in one column, and the initial mockup was also right-aligned but the implementation was left-alignment, so the position of quality bubble went under the radar. —CX Zoom[he/him] (let's talk • {C•X}) 07:17, 10 July 2023 (UTC)
  • Oppose all Is there a way we can just keep using the old ones, like the "switch to old look"? I'm having a lot of trouble processing any of the new boxes for information, especially with the colours. SportingFlyer T·C 22:31, 9 July 2023 (UTC)
  • Support all a step forward for improving clarity and reducing clutter. The opposition seems reflexive. – Teratix ₵ 22:35, 9 July 2023 (UTC)
  • Suppport in general, but wouldn't be sad to see the colored ovals for importance going away (either using the open ovals with color only on the surrounding rule or just go with plain text). —Carter (Tcr25) (talk) 23:44, 9 July 2023 (UTC)
  • Support all as a must better visual improvement to the old design as now you see the colour associated with the quality and importance easily. Lightoil (talk) 00:46, 10 July 2023 (UTC)
  • Support all - none of the arguments in opposition are convincing and I think the new design looks better and is more appealing. Agreed with Sdkb. —Ganesha811 (talk) 00:57, 10 July 2023 (UTC)
  • Support, I think this is an improvement, especially the removal of the Wikiproject repetition but also the removal of most of the bold. Like others I find the image duplication aesthetically odd, but that oddness seems acceptable given the stated accessibility improvement. CMD (talk) 01:28, 10 July 2023 (UTC)
  • Support abbreviation, oppose alignment, neutral on everything else, though I don't get why this RfC couldn't have ran before implementing the changes. Largely because of the old layout, I am used to seeing the names of the WikiProjects in the center of each banner, and the left-alignment irks me, especially with short names like the example given. For longer names... I'll use, as an example, Talk:Toy Story, which is attached to our article on the film Toy Story. Compare these Wayback Machine archives: before (2023-03-29) and after (2023-07-10). Under default settings and the same skin, the old version had a few WikiProjects which required multiple lines to display everything, so abbreviation is a plus. Unfortunately, the alignment is uglier in the new version, since now, I can't just quickly look up and down to see what each project's assessment of a given page is. The banner color replacement is fine, as is the switching to colored buttons for assessment (though I will say that the "Low-importance" button blends in too much with the rest of the banner). I guess I could also update the WikiProject banner for Toy Story to use the new "class" parameter... but then the Good Article status will be displayed twice in a row, with {{Article milestones}} also displaying this. -BRAINULATOR9 (TALK) 03:17, 10 July 2023 (UTC)
    I agree with the concern about visual alignment/scanning by eye of the assessment, but (as I said in my comment up-thread) the trade-off is being able to scan the list of project-names without ragged-left and I don't think seeing and comparing the specific importances is a main thing most readers do at first (based on oft discussions about value of those tags). What if the proejcts were left-aligned but the assessments were themselves aligned in a column instead of a fixed amount of whitespace after the project-name? DMacks (talk) 03:32, 10 July 2023 (UTC)
  • Support Clear improvement for readability at a glance. —pythoncoder (talk | contribs) 03:35, 10 July 2023 (UTC)
  • Oppose all, except for name abbreviation -- yikes! So much visual clutter. Renata•3 03:58, 10 July 2023 (UTC)
  • Oppose all, except for name abbreviation such a lot of excess clutter, the images and colours make it harder and not easier to read, and both are just purely decorative, rather than being to help readers. The name abbreviation is sensible, as they are all WikiProjects, and so WikiProject is superfluous. Joseph2302 (talk) 07:58, 10 July 2023 (UTC)
  • Support all/most of the new design features. Happy to discuss any of the details further, e.g. alignment can certainly be adjusted. I agree that differentiated colours for class/importance are not required so would like to explore that further too. — Martin (MSGJ · talk) 10:06, 10 July 2023 (UTC)
  • Support all apart from colour scheme. It improves readability and eliminates any unnecessary repetition. The use of logos enhances identification of different Wikiprojects, making navigation faster and more efficient. The purpose-driven redesign is commendable; however, I believe there is room for further improvement, specifically in the color scheme. By optimizing the colors for both aesthetic appeal and efficient identification, the redesigned shell can serve its purpose even more effectively. It is crucial to embrace improvements rather than hinder progress based on familiarity with the previous system.JETH888 (message) 13:00, 10 July 2023 (UTC)
  • Support all I think this looks quite nice, including the image and colors. Reywas92Talk 14:20, 10 July 2023 (UTC)
  • Support all I think this looks better than before. The person who loves reading (talk) 14:43, 10 July 2023 (UTC)
  • Oppose images/logos, neutral on left-alignment, support all else. My concern with the introduction of images/logos here is that, at this small size, some images may be too indistinct to be of much value for the reader. For example, the image on Template:WikiProject Hip hop features a drawing of a breakdancer, and if the image were shrunk to the proposed extent then I fear it wouldn't be recognizable at all. Outside of that concern, though, I think the new design is an improvement that makes it easier to identify a page's ratings at a glance. ModernDayTrilobite (talk • contribs) 15:59, 10 July 2023 (UTC)
  • Support all. A lot of work has been done with this banner and any potential tweaks can be done later while dissecting this now will just halt this indefinitely. That said, I do agree that the icons are too small and that when open the larger one duplicates the smaller one. And in the case of the Germany example, the portal one adds the same image yet again. However, that might be also a problem with the single banner designs and not with banner shell template. But as I said above, those issues can be fixed later on. Regarding the importance colors, those can also be tweaked so color blind people can actually see the difference. --Gonnym (talk) 16:40, 10 July 2023 (UTC)
  • Oppose - especially the bubble colors - this addition appears to be unnecessary visual clutter that could impair readability generally by increasing cognitive load, and specifically by increasing visual triggers for readers with sensory issues; a presumption that the use of multiple "pastels" solves this issue does not appear supported by evidence. I also think Wikiprojects can be an important part of editor recruitment and retention, so there seem to be benefits from specifically identifying 'Wikiproject' next to a Wikiproject name in the banner, which might otherwise be lost from only saying 'Wikiproject' once at the top (i.e. 'banner blindness' that could occur from a quick skim over the one time 'Wikiproject' is mentioned). I am trying to consider these changes in terms of the banner purposes and whether these changes improve various functions; at this point, I am concerned that functions related to readability and promoting Wikiprojects are impaired by the changes I have identified in my comment. I also agree with the concerns expressed about the small logos. Beccaynr (talk) 16:43, 10 July 2023 (UTC)
  • Support all – color and images are useful as an additional way to identify different groupings. As long as the colors don't interfere with readability of the text, I think this makes the template more accessible and user-friendly. RunningTiger123 (talk) 17:54, 10 July 2023 (UTC)
  • Support all - the new shell design and layout is a vast improvement on the old version. Happy editing, SilverTiger12 (talk) 20:02, 10 July 2023 (UTC)
  • Support. I like the change, particularly that there's less redundancy. Thebiguglyalien (talk) 20:37, 10 July 2023 (UTC)
  • Support all apart from colour scheme -- Cl3phact0 (talk) 20:59, 10 July 2023 (UTC)
  • I oppose the icons/logos, as they don't seem to add any useful information, don't provide an easy identifier of projects, and add visual clutter. I support the abbreviations, as it removes excess repetition. I don't feel particularly strongly either way on the rest. Tol (talk | contribs) @ 00:20, 11 July 2023 (UTC)
  • Support all, neutral on alignment. When I landed on this page, I was planning to oppose all. But after hearing DFlhb's reasoning (to address accessibility issues), I changed my position to support. Logo makes it quick to identify the theme even if the box is collapsed, which is an improvement over the old version. It will take some time getting used to the new design, but that's a small price to pay for improved accessibility. OhanaUnitedTalk page 13:28, 11 July 2023 (UTC)
  • Support all - I love how it is redesigned now. Much more clear. Coldbolt (talk) 18:29, 11 July 2023 (UTC)
  • Oppose logos, many of them are not very helpful at this size. Opening the Germany project banner reveals the absurdity of three German flags. No strong opinion on the rest; overall, but a design update is long overdue, so probably weak support. —Kusma (talk) 21:09, 11 July 2023 (UTC)
    Even at a very small size, logos can improve the accessibility for people of varying visual ability and neurotypes. Some folks have found ways to opt out below via CSS, and there may be similar ways to increase the zoom level via CSS. —siroχo 10:19, 14 July 2023 (UTC)
  • Support all, neutral on logos and importance colours - I don't know if the logos particularly add any value, but I am not feeling strongly enough to outright oppose their inclusion. I concur with a concern above regarding the importance colours, as giving them more prominence could enhance if they are misleading, when for many wikiprojects, there is insufficient scrutiny in their allocation and accuracy. That said, I only hold that view tenuously and would not mind particularly even if this remained as-is. Bungle (talk • contribs) 21:38, 11 July 2023 (UTC)
  • Support all - the new version looks like an improvement. And "design by committee" has a bad reputation for a reason. Walt Yoder (talk) 21:57, 11 July 2023 (UTC)
    ^this. {{u|Sdkb}} talk 23:27, 11 July 2023 (UTC)
  • Support. This is back-office stuff and I don't need to cite actual policies -- so here we go -- WP:ILIKEIT YEPTHATSTHEONLYREASON ITLOOKSGOOD. The goldenrod talk page templates (the design being named "ClockworkSoul's Coffee Roll", for those interested) are good, but I don't think they were originally meant to nest more of them inside each other. Having the inner ones be white (or light gray, or whatever the hell that is) provides some nice contrast. The little bubbles for importances and classes are good as well. The only question I have is: where do the colors come from? There seem to be a lot of different color schemes for stuff on Wikipedia, it would be nice if they were all canonically established somewhere. Anyway, this has nothing to do with anything. Let's redesign the shells. jp×g 09:48, 12 July 2023 (UTC)
It would be nice if the importance and class bubbles were all aligned off the same vertical (i.e. in the example, currently the start of the "High-importance" for Linguistics is way to the right of the start of the "Mid-importance" for Germany). The thing with the three German flags is kind of dumb as well. Maybe we can find a better way to do it. However, even with these minor annoying things, it would still be clearly better than the one we have now. jp×g 09:53, 12 July 2023 (UTC)
With regards to accessibility issues, which a few people have brought up: I am an officially certified autist and I do not give a hoot if I have to scroll past a few colored bubbles on a talk page. jp×g 21:55, 12 July 2023 (UTC)
The class colors are defined at Module:Class/definition.json, and importance at Template:Importance/colour. For commonly used classes and importances, a lighter pastel equivalent has been chosen for the bubbles, because it looks better and (probably) avoids causing sensory issues to those who have it. —CX Zoom[he/him] (let's talk • {C•X}) 13:58, 12 July 2023 (UTC)
  • Support except for the current bubble colors. I am not opposed to keeping the colored bubbles, as long as it can be done reasonably. The switch from the brighter colors that were initially deployed to the pastels was positive change, but I think the contrast could be improved on some of the bubbles. The "common" category/importance ones are mostly fine, although the readability on some of the darker ones like List- and Future-class could still be improved. As far as I can tell, the ones that are marked as "inherited" (Disambig, Current, ...) aren't actually shown as bubbles anywhere, but if they are, I think that those colors need a serious redesign. PlanetJuice (talk • contribs) 12:52, 12 July 2023 (UTC)
    I cant help but giggle at the fact that this is mentioned by someone having a blue on blue colored bubble as their signature —TheDJ (talk • contribs) 06:18, 14 July 2023 (UTC)
    Yeah... that's an unfortunate oversight on my part. Clearly, I have grown quite oblivious to it – I guess I don't consciously read my signature, unlike the article assessments. (It also has the darker "followed link" color for me, so I rarely realized how the blue on blue looks.) For what it's worth though, my comments above still stand. —PlanetJuice (talk • contribs) 01:54, 15 July 2023 (UTC)
  • Support except for the current bubble colors like above due to poor contrast between the text and the bubble. See also: Wikipedia:Manual_of_Style/Accessibility#Color CactiStaccingCrane (talk) 17:27, 12 July 2023 (UTC)
    A lot of people are saying this, but what is the answer - are you suggesting no colors or different colors? — Martin (MSGJ · talk) 17:31, 12 July 2023 (UTC)
    Both rows of bubbles get the best rating, AAA, on WCAG (by a lot; AAA is 7:1, and most of these are 15:1 to 20:1 on contrast). The second row's colours haven't been overridden yet, unlike the first row, so despite being WCAG AAA they might look harsher. Should they be lightened up too? That could increase the contrast, but would make them look more similar to each other. Interested in people's thoughts. Note that the second row bubbles will almost never be displayed in the banner shell. DFlhb (talk) 22:20, 12 July 2023 (UTC) updated 22:32, 12 July 2023 (UTC)
    I would be in favor of lightening the second row. Just out of curiosity, under what conditions would those bubbles be displayed? I poked around the module code and saw that they just use the default colors from Template:Class/colour, but I don't see the bubbles on any pages where they would belong. If they show up very infrequently, I doubt that the lightened colors being less distinguishable would be a big concern. Perhaps it may even be worth it to consider standardizing all those less frequently used bubbles to one or two colors instead of having a different color for each one that hardly means anything when they hardly show up. PlanetJuice (talk • contribs) 20:16, 13 July 2023 (UTC)
    Right now they're only displayed in the shell for these 14 WikiProjects that opted out of article-class, since it's easier to figure out how to implement. It's being discussed up above. DFlhb (talk) 07:57, 15 July 2023 (UTC)
  • Support all changes noting that the colour scheme needs revision to comply with accessibility standards. A contrasting border on the bubbles would be nice but I don't know if that's even possible. Wikipedia needs to let go of its mentality that all cosmetic changes are bad. We don't need to have an approved-by-committee reason and process for everything, sometimes it's nice to just have a refresh of things. But also: the assessment system is broken; I would've been happy to see every assessment level other than stub, Gx, and Fx binned. They're meaningless subjective evaluations that aren't broadly consistent at all, and most are never reevaluated unless an article gets to GAN. But that's a whole separate discussion. Ivanvector (Talk/Edits) 17:57, 12 July 2023 (UTC)
  • Support all Love the new design, especially the inclusion of icons. Clearly a positive change with unconvincing opposition arguments. – SD0001 (talk) 18:38, 12 July 2023 (UTC)
Support all I think the changes makes it more clear what the purpose of the banner shell is and cleans up the overall look of this very commonly used template. I would personally prefer the alignment of the class/importance elements to be consistent, with the proposed "Design 1" in the above sections being practically appealing to me Cakelot1 ☞️ talk 22:20, 12 July 2023 (UTC)

This article is of interest to multiple WikiProjects.

The Galaxy banner had 4 lines naming projects before an editor set "collapsed=yes". Adding icons and giving the ratings bright colors will only encourage editors who worry about talk page bloat to collapse banners. The template sample at the top of this page may be misleading. There seems to be a consensus that it is fine to collapse banners once they reach 4 to 6 lines. See this discussion.
As an alternative it would help to modify the collapsed state to simply list the names of projects, or let a few names be specified to be displayed in the collapsed state. The science projects such as Astronomy and Physics are active and a visible mention of the projects on article talk pages helps recruit knowledgeable editors. StarryGrandma (talk) 04:09, 14 July 2023 (UTC)
https://wiki.riteme.site/wiki/Wikipedia:Templates_for_discussion/Log/2021_January_8#Template:WikiProject_banner_shell was only a consensus to not automatically collapse, it was not a consensus to manually collapse at 4-6 banners, only a comment about that. -Kj cheetham (talk) 11:18, 14 July 2023 (UTC)
P.S. I do not support collapsing the banner shell in general (though it should remain a manual option), as I fully agree the project names should be immediately visible. -Kj cheetham (talk) 11:20, 14 July 2023 (UTC)
  • Support all, Adding logos and colors gives alternate presentation of information, which improves accessibility for all editors. Main feedback would be to ensure text is a good contrast with background generally. —siroχo 10:16, 14 July 2023 (UTC)
  • Comment: Since this banner is intended to be used in cases where an article falls under the scope of multiple WikiProjects, it seem a bit strange for the |class= to be part of the banner template's syntax. Perhaps this has been already resolved, but not all WikiProjects assessment end up being the same since assessments are often done at different times by different people, right? Moreover, assessments tend to be rather subjective in the sense that they largely depend on who's doing the assessing. Personally, I've never worried too much about individual articles assessment for reasons such as these and tend feel that only more formal assessments such as FA or GA are worth mentioning on an articles talk page outside of individual WikiProject banners, but it does seem that the new (or maybe it's always been this way) parameter in the banner heading gives the implication that the article has been formally assessed by some Wikipedia quality control committee and the standard for assessment is thus codified and more importantly consistent across all of Wikipedia. -- Marchjuly (talk) 22:31, 14 July 2023 (UTC)
    @Marchjuly, your comment relates to the project-independent quality assessments, which were adopted in March and aren't really what's under consideration here. But to speak to your thoughts, theoretically editors from different projects might have different thoughts on an article's quality, but in practical terms, we don't have enough editorial capacity to regularly assess all 6 million articles even once, let alone multiple times for each of the different projects an article belongs to. Project-based assessments were basically a massive fork that multiplied the effort needed for assessment and introduced a lot of complexity (and banner bloat to display that complexity) for very little benefit. It's a good thing we're moving toward phasing them out. {{u|Sdkb}} talk 03:45, 15 July 2023 (UTC)
    That's fine since, as I posted above, I don't really consider individual project-based assessments to be formal assessments like FA and GA. It's for the reasons you mention above, though, that I don't think the |class= parameter should be part of the banner template's syntax (at least not yet perhaps) until the assessment process can be sorted out so that it's somewhat standardized project-wide. If, however, that ship has already sailed, then perhaps it would a good idea to set the template up to make it possible to indicate at least when the article was last assessed and even perhaps who assessed it. Just my opinion on the matter. -- Marchjuly (talk) 09:13, 15 July 2023 (UTC)
    "when the article was last assessed" is recorded by WikiProject India, and I previously proposed to make it global here, but that discussion went nowhere. —CX Zoom[he/him] (let's talk • {C•X}) 10:45, 15 July 2023 (UTC)
    @Marchjuly, there is a general standard for assessment, at Wikipedia:Content assessment. — Qwerfjkltalk 14:41, 16 July 2023 (UTC)
    I'm aware of that. As long as that's the standard that's being followed, then I guess there should be no issues. My concern is that not everyone may be assessing articles according to said standard, but perhaps based on individual WikiProject standards that appear (used to appear?) in the project-specific banners. I've seen article talk pages in which different projects have assessed articles differently. So, if there's going to be one overall assessment for an article, I thought it would be helpful to do something like is done for FAs and GAs in which the dates are included as part of the assessment. Perhaps instead of added a "class" parameter to the banner shell template, it might be better to add it to {{Article history}} and treat the assessment as a WP:PR. Maybe the "Article history" template could be modified to cover all of the WP:ASSESS classes. -- Marchjuly (talk) 10:25, 17 July 2023 (UTC)
    @Marchjuly, this has been discussed previously, but it was found that most WikiProjects have the same general standards for assessing articles, with a few notable exceptions. — Qwerfjkltalk 10:47, 17 July 2023 (UTC)
    I appreciate everything you're saying Qwerfjkl, but my concerns is about things like what's happened at Talk:Cultural impact and legacy of Johnny Depp. That's a new article that went through AfC, but most likely hasn't really been assessed by any WikiProjects because the creator of the article has self-assessed everything and assigned it to be "high-importance". Now, perhaps that's more of an exception to the rule than the rule itself, but the creator seems to have listed the article as a GA article until someone else assessed it as "Class C". Such a thing could of course have just as easily happened with the old banner, but the prominenance of the class rating in the new banner shell makes it seem as an official rating being given by Wikipedia and not a subjective rating being given by one particular editor. -- Marchjuly (talk) 05:41, 19 July 2023 (UTC)
    @Marchjuly, the solution here is to assess it correctly; this doesn't seem a huge issue to me, and to me isn't justification enough to undo this.
    That being said, this isn't the correct place to discuss this. I would ask some editors who are more familiar with the project, because I haven't been participating that much here. — Qwerfjkltalk 10:45, 19 July 2023 (UTC)
  • Support all with appreciation for the color scheme reinforcing the textual information BluePenguin18 🐧 ( 💬 ) 20:44, 16 July 2023 (UTC)
  • Support abbreviation and better contrast of text and background colours. Strongly Oppose colouring of class and importance, which add visual clutter to the talk page, highlighting aspects which change infrequently and have little significance to most editors, not just those who regard them as unreliable. Left-alignment makes those bubbles even noisier as they jump left and right. Overall this displays wikiprojects as being the most important element of the talk page, with no regard for a project's relevance to the article or talk page, or even whether the project is active and might be helpful to editors who would be otherwise unaware of it. NebY (talk) 21:20, 16 July 2023 (UTC)
  • Support colours per DFlhb, support abbreviations, Neutral on alignment and icons. (I assume editors who !vote oppose all are not in fact opposed to abbreviation, because that seems to have near -unanimous support and no specific objections, with the sole exception to that being Beccaynr's !vote. — Qwerfjkltalk 10:52, 17 July 2023 (UTC)
  • Support all: much easier to scan without taking up much space. Visual cues are simple and improve readability. Looks cleaner and more modern. — Bilorv (talk) 09:22, 18 July 2023 (UTC)
  • No comment on color scheme, otherwise support all – I really like how this looks to me, but I'm on dark mode which changes colors and switching to light mode for one RFC is going to make it hard to judge whether I like it in that form or not. I think if the logos go, center-alignment is probably better (I don't think the logos fit in the center of the screen), but I actually like them even with the repetitiveness upon opening a banner. Skarmory (talk • contribs) 20:47, 18 July 2023 (UTC)
  • Support all, even as a self-confessed Hater of Layout Changes. The first iteration was a little wonky, but the current version is a significant improvement on both the old one and the prototype -- it's far easier to tell at a glance the things that actually matter (rating, what a given wikiproject probably covers). Unrelatedly, I like trying to imagine what would be covered by all of "Linguistics", "Germany", "Theology", and "Highways". Vaticidalprophet 01:04, 19 July 2023 (UTC)
  • Support all and keep iterating. Overall I find the change refreshing and a good start to improving how this information is shown to users. I think it'll take a while to get used to and improvements can come gradually rather than all at once. Legoktm (talk) 02:59, 19 July 2023 (UTC)
  • Support most, reduces repetition and improves scannability. Neutral on icons though. I appreciate that some people find them helpful for identification, but I wonder if many users might try clicking them to get to the project and be confused by the image opening instead. Obviously that's an issue for the images within the collapsed part as well (for both the new and old designs) but this change does make it more prominent. the wub "?!" 23:32, 23 July 2023 (UTC)
    • @The wub, I assume this could be fixed by adding link=, e.g. — Qwerfjkltalk 09:31, 25 July 2023 (UTC)
      I think that's only supposed to be done for public domain images. So couldn't be done for WikiProject Highways in the example above. the wub "?!" 12:11, 25 July 2023 (UTC)
      No, it has nothing to do with public domain or copyright status of image. The link= is used so that, on clicking the image, you're directed to an article/page of your choice. For example, [[File:Wikipedia.svg|16px|link=Wikipedia]] produces this: If you click the image, you're taken to Wikipedia article. link= prohibits the image from opening in media viewer. If no page is provided to link=, for example, [[File:Wikipedia.svg|16px|link=]] produces this: . So, the image doesn't open in media viewer because link= exists, but at the same time there is no article to go to, so it just remains unclickable. —CX Zoom[he/him] (let's talk • {C•X}) 17:05, 25 July 2023 (UTC)
      My understanding matches wub's, and this discussion. DFlhb (talk) 17:22, 25 July 2023 (UTC)
      Okay, now I have the context. I've never come across a policy or discussion saying this, so it actually did not come across my mind as to why would link= would be limited to public domain images. —CX Zoom[he/him] (let's talk • {C•X}) 17:55, 25 July 2023 (UTC)
      That statement is unsupported by policy so far as I'm aware. I know a lot of people advance the position, however. Izno (talk) 17:26, 25 July 2023 (UTC)
  • Support all apart from small images/logos, new look is easier to read and less cluttered. I think the look could be cleaner without the small icons on the side. The image gets lost, on some, when it's that small anyways, no issue with the collapsed larger icons. Eucalyptusmint (talk) 19:11, 26 July 2023 (UTC)
  • Support all - Really nice job! Schierbecker (talk) 18:14, 30 July 2023 (UTC)
  • Support all: Looks better, and the colouring/logo makes it easier to read and understand. ARandomName123 (talk) 00:27, 31 July 2023 (UTC)
  • Support all except left-alignment of title. It should be center-aligned to cotnrast with the "body" of the template. Everything else looks nice. JuxtaposedJacob (talk)
  • Support all I was skeptical at first, but now that I've been seeing the templates over the past several days, I think it looks much better! Excellent work. Curbon7 (talk) 06:14, 1 August 2023 (UTC)
  • Support all, with possible suggestion I would have preferred something that looks like the following example, similar to Design 4. I don't like the contrast between text and background changing depending on what kind of bubble it is. It seems fine though.
    Example:    FA-class Closhund/talk/ 09:47, 7 August 2023 (UTC)
  • Broad support It looks good. I was happy that someone's made it better after all these years. Per the law of triviality, I'm happy with people ironing out the details through discussion and am pretty much fine with any tweaks that come through this RfC while supporting the broad direction as a positive change. —Tom Morris (talk) 13:24, 18 August 2023 (UTC)

Discussion (redesign RfC)

  • This is the sort of discussion, I wish we had a ranked choice voting voting system here whcih allowed us to ask specific questions. Apart from the "support all" and "reject all" opinions above, which are few in number, there are lots of comments that point to issues of particular types, for example: regarding bubbles, some think that they are cool, some think that cool but right-aligned would be better, some say the colored-border would be better and some think that it shouldn't be colored at all. None of them make 50%. —CX Zoom[he/him] (let's talk • {C•X}) 19:50, 9 July 2023 (UTC)
    Maybe a quick straw poll on each separate question? — Martin (MSGJ · talk) 10:07, 10 July 2023 (UTC)
    Probably not applicable to this discussion but there's no reason a straw poll can't be ranked choice. We often see straw poll comments like "Support option B, option A second choice, oppose option C" which is practically a ranked ballot. Straw polls aren't usually formally counted anyway. Ivanvector (Talk/Edits) 12:09, 13 July 2023 (UTC)
  • DFlhb noted above that the top bar was not part of this recent redesign, and is separate from what we're discussing. If so, the previous appearance image at the top of the RFC question is extremely badly chosen to the point of being misleading and I'm no longer completely clear what "oppose" actually means in terms of the banner looking like. Could someone replace the images at the top with ones that actually reflect the question being asked? -Ljleppan (talk) 20:32, 9 July 2023 (UTC)
    The current top bar design dates back to the "article class" implementation in March, though it was subsequently refined through discussion here. People are very welcome to give feedback on it here, I just wanted to clarify that it wasn't changed this week. DFlhb (talk) 22:48, 9 July 2023 (UTC)
  • The redesigned example has some differential wording in the individual project entries vs in the top bar/wrapper. Is that something to discuss here (since it's about the redesign) or wait until "the design" is settled before discussing that sort of tweak? DMacks (talk) 22:03, 9 July 2023 (UTC)
    If you mean the wording this template in the shell, versus this article in the project banners: that text is controlled by each banner; right now, some implement automatic namespace detection, some don't. The banner wording is a result of the article-class implementation, which dates back to March. Harmonization in either direction, if people support it, merits a separate discussion. Though it's a good observation. DFlhb (talk) 22:30, 9 July 2023 (UTC)
    I'll write my thought here now so I don't forget it, but certainly no problem to defer to later/elsewhere. The wrapper/top is:
    This [whatever] is rated C-class on Wikipedia's [[Wikipedia:Content assessment|content assessment]] scale.
    and the (for example) WPHighways expanded entry is:
    This article has been rated as Future-class on the project's [[Assessment#Quality scale|quality scale]].
    The same thing ("class") is alternately called ""content assessment" vs "quality". DMacks (talk) 00:31, 10 July 2023 (UTC)
    "Quality scale" would be my preferred phrase for FA, (A), GA,..., Stub classes, but for others like Future, Template, Redirect, etc. "quality scale" will not fit well. "Content assessment" will, imo, be an all-inclusive phrase, and may be preferred. —CX Zoom[he/him] (let's talk • {C•X}) 07:32, 10 July 2023 (UTC)
  • A question for those who are opposed to left-alignment. Is the preference for the prior centered alignment or for the layout proposed earlier with the project name aligned left and class/importance aligned right? I was strongly in favor of the left alignment because to my eye the class/importance were too disconnected from the project in most cases when viewed on a standard monitor. On a smaller screen it was less of an issue, but it wasn't a change that was just for mobile viewers. —Carter (Tcr25) (talk) 21:11, 10 July 2023 (UTC)
  • Two different suggestions seem to entail having a collapsable box whose title-line disappears when the box is expanded. That's not the current behavior, and none of the collapse templates seem to have that feature. I asked Template talk:Collapse top to see if I'm overlooking something, or else if it can be done at all. Will head to VPT in a few days if needed. DMacks (talk) 23:19, 18 July 2023 (UTC)
    @DMacks: Assuming you want to just hide the logo upon expansion, the following css will work. You can try it by applying thais to your css stylesheet. 
    .wpb:not(.mw-collapsed) .wpb-header-icon {
	width: 0.5em;
} /* to align project name to left side, do not apply if moving around of elements is not desired */
.wpb:not(.mw-collapsed) .wpb-header-icon a {
	display: none;
} /* to hide the header icon */
    —CX Zoom[he/him] (let's talk • {C•X}) 06:05, 19 July 2023 (UTC)
    @Ljleppan, @Gonnym: Does this css trick appear to solve the three German flag problem? Personally I prefer this one over current design, but I think this is a new feature supported in current browsers and not on older browsers, so the solution might not be visible to everyone. —CX Zoom[he/him] (let's talk • {C•X}) 06:21, 19 July 2023 (UTC)
    I oppose doing this (or hiding the icon when expanded) because interface elements shouldn't move around; it's too confusing. We can't do usability testing, so we have to rely on established UX principles, and it's considered bad. If a collapsed table row looks a certain way, it should look the same way when uncollapsed; only element that should change is whatever controls the collapse, here the [show]/[hide] button. The fact that it's not done on any other template is another reason to avoid, since we'd be breaking people's expectations of how the UI will react to their input, which is another established UX principle. The motion would also be distracting. DFlhb (talk) 06:38, 19 July 2023 (UTC)
    If we keep just the later css rule, and remove the first one, then the interface elements would not move around, while repetitive header icon will not be visible on expansion. What is your opinion on that? —CX Zoom[he/him] (let's talk • {C•X}) 06:56, 19 July 2023 (UTC)
    Nice idea and it looks pretty good. I assume older browsers will just ignore it and display the icon as per current display? I agree the first rule is not a good idea. — Martin (MSGJ · talk) 07:19, 19 July 2023 (UTC)
    Neutral on it, but it looks nice. DFlhb (talk) 07:52, 19 July 2023 (UTC)
    What stylesheet should this be added to, so that everyone can benefit? — Martin (MSGJ · talk) 22:05, 23 July 2023 (UTC)
    Module:WikiProject banner/styles.css or Template:WikiProject banner shell/styles.css? My preference is the latter, because banners are collapsed only when inside WPBS, not otherwise. One templatestyles call will affect the whole page. WPBS.css will run the rule only once, WPB.css will run it many times unnecessarily. Although, I'm not aware if multiple runs has any impact on performance or not. —CX Zoom[he/him] (let's talk • {C•X}) 08:28, 24 July 2023 (UTC)
    Tested working on Template:WikiProject banner shell/sandbox/styles.css — Martin (MSGJ · talk) 13:50, 24 July 2023 (UTC)
    Looks good to me. Examples at User:MSGJ/Sandbox/3. —CX Zoom[he/him] (let's talk • {C•X}) 14:18, 24 July 2023 (UTC)
    This is a misunderstanding of TemplateStyles. Second and later uses of a TemplateStyles tag are deduplicated into a non-<style> tag (in this case a <link> tag, but that's unimportant). You receive only one batch of CSS.
    It is usually best to put TemplateStyles where the classes are defined. In this case, you could make the argument for either location because on one hand .wpb and .wpb-header-icon go with the banner styles, while the use of mw-collapsible is only due to use in the banner shell. I would personally put this in the shell because there is an inferred .wpbs in the front of the two selecting lines here (that should consider being added just to make clear this should only occur when .wpb is in the shell). Izno (talk) 16:04, 24 July 2023 (UTC)
    Thanks for correcting me, I was unaware of that. Also, I like the idea to add .wpbs for proper explanation. —CX Zoom[he/him] (let's talk • {C•X}) 16:32, 24 July 2023 (UTC)
    If you want to add that to the sandbox then I will deploy it — Martin (MSGJ · talk) 19:08, 24 July 2023 (UTC)

Opt-out

Thinking about the Rfc question; but in the meantime: I sympathize with opt-out comments above, which I presume would involve css classes added to whatever elements might need opting out. If implemented with classes, presumably that would also allow me to change colors or fonts I found obtrusive, disappear any images I didn't like with display:none, and so on. To the designers of the new version: are there already classes available for these, or do you foresee any technical issues precluding adding them? Or is there a better way to deal with opt-out? Mathglot (talk) 19:10, 9 July 2023 (UTC)

An opt-out was presented in the previous discussion, half an hour after one was requested by SusunW. Available here; icons are still visible, though hiding them is possible too. DFlhb (talk) 19:40, 9 July 2023 (UTC)
Thanks for that. It helps. And how does one hide the icons? SilkTork (talk) 02:45, 10 July 2023 (UTC)
The <td> element which holds the image does not have a html class, so it is not possible, I assume. @DFlhb: Can you add one? —CX Zoom[he/him] (let's talk • {C•X}) 12:28, 10 July 2023 (UTC)
Done, named wbp-header-icon wpb-header-icon DFlhb (talk) 12:47, 10 July 2023 (UTC)
@DFlhb: I'm sorry, not the <td> but the image within <td>. "display: none;" to the td has unintended behaviour. —CX Zoom[he/him] (let's talk • {C•X}) 13:19, 10 July 2023 (UTC)
@DFlhb: Nevermind, this also works: 
.wpb-header-icon {
	width: 0.5em;
}
.wpb-header-icon a {
	display: none;
}
Sorry, for the trouble. —CX Zoom[he/him] (let's talk • {C•X}) 13:28, 10 July 2023 (UTC)
@DFlhb: That class name is misspelled. It should be .wpb, not .wbp. – MaterialWorks 13:34, 21 July 2023 (UTC)
True; but seems a bit too late to fix. DFlhb (talk) 20:40, 21 July 2023 (UTC)
You could add ".wpb" class to the template alongside ".wbp" for now. After a day or so, when the template changes gets applied to all pages, get an willing intadmin to change it for some of the only 6 editors who have it on their css file: myself, MSGJ, MaterialWorks, DilipSpatel, DSP2092, Joseph2302. And then remove ".wbp" from source code. Currently some use .wpb (e.g., .wpb-header-bubbles) and some use .wbp (e.g., .wbp-header-icon) which is confusing. —CX Zoom[he/him] (let's talk • {C•X}) 07:50, 23 July 2023 (UTC)
Now added. DFlhb (talk) 09:50, 23 July 2023 (UTC)
@Izno: Can you please change "wbp" to "wpb" in the following stylesheets: 1, 2, 3, 4? Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 13:26, 24 July 2023 (UTC)
I've done mine — Martin (MSGJ · talk) 13:38, 24 July 2023 (UTC)
 Done Izno (talk) 16:05, 24 July 2023 (UTC)
Thanks Izno. So, now the "wbp" class might be removed from code because all of its uses are changed. —CX Zoom[he/him] (let's talk • {C•X}) 16:21, 24 July 2023 (UTC)
Done. DFlhb (talk) 16:39, 24 July 2023 (UTC)
Just a suggestion: we don't need to overload the job queue for minor and non-urgent changes like this. Just leave them in the sandbox and we can deploy with a more substantive edit in due course? — Martin (MSGJ · talk) 16:44, 24 July 2023 (UTC)
Good thinking; I was wondering why you deployed changes in batches like that. Will follow that from now on. DFlhb (talk) 16:50, 24 July 2023 (UTC)
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.

Redirect-class invisible when banners inside WPBS

See Talk:List of statues and sculptures in New York City. Here WP Lists and WP NYC, auto-detect redirect-class and apply it, they populate their respective Redirect-Class categories, but the collapsed summary does not show "Redirect-Class", and even on expansion the "Redirect-Class" is not seen. Now, at Special:Permalink/1163791934, after removing WPBS, we can see Redirect-Class properly as expected. With WPBS also, they should be visible in the summary and on expansion. (Note that this issue is not related to today's redesigning. I had seen this at least 5 days ago.) —CX Zoom[he/him] (let's talk • {C•X}) 13:38, 6 July 2023 (UTC)

Yep, this is all working as expected with the project-independent quality assessments. The only things which would make it display are a contradictory class rating in the banner shell or the |QUALITY_CRITERIA=custom setting — Martin (MSGJ · talk) 19:26, 6 July 2023 (UTC)
Isn't this contradictory? WP Lists & WP NYC want to specifically know if it is a redirect or not. Others might not care, but these two do, so we should show this rating. (Also note that I proposed redirect-class be a standard class, with fallback to NA only when a project doesn't support redirect-class). —CX Zoom[he/him] (let's talk • {C•X}) 21:34, 6 July 2023 (UTC)
It isn't contradictory because NA covers all the non-article pages. There were discussions about this, perhaps you missed them. Anyway I have already proposed that Redirect be a standard extended class, so I'm with you there. — Martin (MSGJ · talk) 21:51, 6 July 2023 (UTC)
I might've. I wasn't very active until early June due to college. —CX Zoom[he/him] (let's talk • {C•X}) 22:03, 6 July 2023 (UTC)
I'm convinced that the bubble should show the class if it populates a category different from the banner. At File talk:Siegestor München abends.jpg, WPVA populates the redirect-class category, but it isn't reflected in the banner summary, which is bad. The populated category and quality bubble should be the same. —CX Zoom[he/him] (let's talk • {C•X}) 08:07, 10 July 2023 (UTC)
Did you link the wrong page because I can't see any Redirect categories on that one?
Okay so there is an issue we have been struggling with since introducing these project-wide quality assessments. The basic cause is that File-Class, Redirect-Class, etc. are not quality assessments, but are used as a convenient way of keeping track of types of pages. It has been that way for a long time, but it would be great if we could separate them.
Options of things we could do:
  1. Use File-class as the quality assessment. Due to reasons above, I would resent this, but the main problem is that not every project uses File-Class, so we would be advertising a class which does not apply to every project.
  2. Keep NA-class in the shell but use File-class in the bubble (your suggestion above). This is certainly possible, but ... currently the class bubble is only used if there is no project-independent quality assessment, or if the quality assessment conflicts, neither of which apply in this situation. We would effectively be introducing a conflict which could never be resolved. I suppose we could use the bubble, but not actually track it as a conflict. But don't forget that our end game here is that all quality assessments are harmonised and no class bubbles will be needed.
  3. Keep NA-class in the shell, but find another way to represent the type of the page. We already have "file" or "redirect" in the text, but what else could we do to make it clearer? Do you want a colourful icon, or the word "Redirect" on a coloured background as we are familiar with?
A couple of other relevant notes.
  • I have an open proposal to rename all the categories from Redirect-Class PROJECT articles to something like WikiProject PROJECT redirect pages, which I think would help a lot.
  • And since recently, projects can selectively opt-in to certain classes in the extended scale, simply by creating the relevant category. This will eventually mean that all projects can use the standard scale, and custom masks will not be needed to do most of the things they are currently used for.
— Martin (MSGJ · talk) 12:05, 10 July 2023 (UTC)
Ahhh sorry, I meant that the banner gives "NA class", but WP Visual arts actually populates "File-class" but, there are no bubbles to indicate this. —CX Zoom[he/him] (let's talk • {C•X}) 12:08, 10 July 2023 (UTC)
I'd support #2 proposal until we sort out everything. I find it frustrating that the banner appears to be in agreement with the global NA class, and then when I open the NA-class category of WP Visual arts, it is absent there. I then have to come back to check the categories, then I realise that it is actually "redirect"/"file"/etc. class. —CX Zoom[he/him] (let's talk • {C•X}) 12:13, 10 July 2023 (UTC)
What if ... we put the page in Category:NA-Class visual arts articles (so there would be no conflict at all) and then in addition it was placed in a category like Category:WikiProject Visual arts file pages? That would seem to fit all requirements and we are tracking quality and type separately. — Martin (MSGJ · talk) 12:17, 10 July 2023 (UTC)
Considering that they created a "file-class" category separate from "NA-class", I do not think they would like files polluting what the WikiProject considers "NA-class category". —CX Zoom[he/him] (let's talk • {C•X}) 12:32, 10 July 2023 (UTC)
So what is your suggestion to do this without creating a unresolvable conflict between the assessment ratings? Please consider the long term goals that we would like to be able to assess the quality of files, lists, and other non-article pages — Martin (MSGJ · talk) 14:24, 10 July 2023 (UTC)
I'm just saying that, for now (emphasize), the bubble on a banner and the category it populates must be same, except when the global category and local category are of same class. We can change it at a later time as we figure out what can be done best with these sorts of ratings. —CX Zoom[he/him] (let's talk • {C•X}) 17:14, 10 July 2023 (UTC)
Shouldn't the real rating at least be visible inside the collapseduncollapsed WikiProject banner? DFlhb (talk) 04:27, 19 July 2023 (UTC)
Do you mean in a bubble? Yes that is what we are talking about here. It would also display in the uncollapsed banner. This will negate a lot of the benefits that we gained with WP:PIQA but people seem to want it ... — Martin (MSGJ · talk) 07:39, 19 July 2023 (UTC)
No; read "collapsed" as "uncollapsed" if you prefer, I use them interchangeably. I don't support the bubble, because the article type is already in the banner (This template has..., This redirect has... and bubbles would clutter the shell.
Bubbles are also pointless because whether projects classify a page as "NA" or a more specific "class" is an idiosyncracy with no informational value, and only value internal to the project. That's why I support showing it in the uncollapsed banner (so the "true" project rating appears somewhere) but not in a bubble. 'Don't make useless information prominent'. DFlhb (talk) 11:33, 19 July 2023 (UTC)
While I do support showing it in uncollapsed banner, I also support showing it on the bubble. "...more specific "class" is ... only value internal to the project.": You can say the same about MILHIST's A-class, which is always a GA in global rating, but we still show it. —CX Zoom[he/him] (let's talk • {C•X}) 11:39, 19 July 2023 (UTC)
Not at all, because that's a disagreement over quality, and the point of these banners is to show quality ratings. Disagreement over whether a redirect is "Redirect-class" or "NA-class" is meaningless, likely even to the project (Redirect-class is opt-in, but a lot of the template editors who created WikiProject banners just added it based on personal preference, and it was added, in drive-by way, to most of the remaining banners for uniformity). Regardless, it's trivial back-end classification, unlike article quality assessment. DFlhb (talk) 12:15, 19 July 2023 (UTC)
I like your reasoning (especially now you have clarified what you meant by collapsed/uncollapsed!). It will produce a slight inconsistency in that the collapsed display is not a exact reflection of the uncollapsed display, but I think this is the right step. — Martin (MSGJ · talk) 13:55, 19 July 2023 (UTC)
I would also support hiding the class if the custom rating matches the global rating. So if MILHIST rate C-class and the global rating is also C-class, why not just hide it? We just need to display the assessment if it is different. — Martin (MSGJ · talk) 17:18, 19 July 2023 (UTC)
I'm cool with it. —CX Zoom[he/him] (let's talk • {C•X}) 07:55, 23 July 2023 (UTC)
This seems like a good idea. -Kj cheetham (talk) 10:34, 23 July 2023 (UTC)

Any updates on possibly trying to implement this? Just trying to follow up on the comments (mine included) above in #About non-standard content grades that then directed down to this discussion. - Favre1fan93 (talk) 23:08, 18 July 2023 (UTC)

Okay let's do it. (I can't help feeling this is a step in the wrong direction, but I appear to be alone in that.) Just to clarify though, do we want to track these at Category:Articles with conflicting quality ratings - I would guess not, because they are not actually articles? — Martin (MSGJ · talk) 07:34, 19 July 2023 (UTC)
@MSGJ: Great. I don't know if this is what you are trying to discuss above, but at least for me, all I was hoping could be changed is when I visit drafts I work on regularly (like Draft talk:Thunderbolts (film)), the shell will show the Draft-class assigned color and state This page is rated Draft-class on Wikipedia's content assessment scale. rather than the current This page is rated NA-class on Wikipedia's content assessment scale.. - Favre1fan93 (talk) 20:10, 22 July 2023 (UTC)
I support this proposal too, since forever. I think we should discuss this topic seriously. —CX Zoom[he/him] (let's talk • {C•X}) 07:59, 23 July 2023 (UTC)
This seems like a good idea. -Kj cheetham (talk) 10:34, 23 July 2023 (UTC)
The main problem I have with this @Favre1fan93 is that we don't actually "rate" the page as Draft-class because it just is a draft because it's in the Draft namespace. I think the word "rate" or "assess" should be reserved for quality ratings, and this gets to the heart of the whole issue of separating quality ratings from page types. — Martin (MSGJ · talk) 06:55, 27 July 2023 (UTC)
I believe this is not yet implemented, right? —CX Zoom[he/him] (let's talk • {C•X}) 07:57, 23 July 2023 (UTC)
Nothing has changed yet, because there is not consensus on what particular changes are desired. Even in this discussion there are now three different subproposals which makes things complication. I will try and set out the separate ideas clearly and then people can vote/discuss. — Martin (MSGJ · talk) 17:06, 23 July 2023 (UTC)
That sounds great. - Favre1fan93 (talk) 14:26, 24 July 2023 (UTC)

I totally support having a visual representation of Draft, Redirect, Template, File, etc. when applicable in the shell instead of the generic NA. I didn't realize that the presence of the shell was hiding classes like "file" and "redirect" in the enclosed banners. I also never thought about the fact that Class includes both fixed values like "file" and "template" as well as changing quality ratings (draft, stub, start, C...) A WikiProject may choose not to recognize redirects or files but from a Wikipedia-wide classification standpoint, we should be making these designations. It's like a Project deciding that Lists are the same as Articles. That's fine for them, but globally these are two different things. Files and templates and redirects may all be non-articles, but they are incontrovertibly different from each other.— TAnthonyTalk 17:05, 23 July 2023 (UTC)

Couple of points.
  1. Up to now the rating in the banner shell has just been for rating the quality of the article. The type of the page is reflected in the text (This redirect has been ...) Project banners have traditionally mixed up quality and type but it would be great to find a way not to conflate the two.
  2. As the banner shell is attempting to represent the quality of the article for all projects, we are using the lowest common denominator which is the standard scale shown at Wikipedia:Content assessment. This is because all projects which assess articles use these. If we start using the extended classes, then we are advising that the page has been rated with a class that some projects don't even recognise/support.
That said I do agree that a visual representation of the type of page would be nice. — Martin (MSGJ · talk) 07:05, 27 July 2023 (UTC)

Proposal

On reading all of the above, I have a formal proposal. On a non-article page, the banner shell could do the following:

  1. Use the relevant icon from Template:Class/icon, e.g. for templates.
  2. Change the wording to one of the following:
    1. "This redirect/template/file does not require a rating on Wikipedia's content assessment scale." (Do we even need to link to that scale as it would be irrelevant for that page?)
    2. "This redirect/template/file has been automatically rated as NA-class on Wikipedia's content assessment scale."
  3. No class bubbles unless there is a contradictory class (like a custom class or something weird like B-class for a redirect)
  4. The assessment row in the uncollapsed banner shows the namespace related class if the project is using it. (NA-class would be hidden as it is now.)
  5. The page will not be tracked at Category:Articles with conflicting quality ratings unless there is actually a conflicting rating.

Your feedback please — Martin (MSGJ · talk) 07:31, 27 July 2023 (UTC)

Regarding #2.1, we do assess Wikipedia:Featured pictures in the case of files. It is just weird why we do not have it on the Assessment scale. I would say the same thing about Wikipedia:Featured lists (not supported by all banners afaik). These are project-wide quality categorisations and they deserve the same prominence in talk pages as WP:FAs. —CX Zoom[he/him] (let's talk • {C•X}) 07:41, 27 July 2023 (UTC)
Since 2011 we have the FM-class for featured media but it never really took off. Quite a few projectrs use it but it never made it to the standard scale. Perhaps it was proposed and rejected or perhaps no one ever got round to proposing it. — Martin (MSGJ · talk) 12:49, 27 July 2023 (UTC)
@MSGJ and CX Zoom: is someone able to mock up a visual representation of what these proposals would look like? That would help me at least I feel. But on the onset, 1, 2.1, and 5 I am in support of, and uncertain on 3 and 4 without further knowledge of what is actually relates to visually. - Favre1fan93 (talk) 14:13, 27 July 2023 (UTC)
I support 2.2 and all others. Happy editing, SilverTiger12 (talk) 15:12, 27 July 2023 (UTC)
Support all, though CX is right that we should figure something out for FM, FL, etc. DFlhb (talk) 09:42, 29 July 2023 (UTC)
Any preference for 2.1 or 2.2? — Martin (MSGJ · talk) 09:58, 29 July 2023 (UTC)
2.1 (agree with Favrefan) but with the page type bolded DFlhb (talk) 08:36, 30 July 2023 (UTC)
Changed to 2.1. Are you sure it would look okay saying "This article has been rated C-class"? — Martin (MSGJ · talk) 11:34, 30 July 2023 (UTC)
No; only change the bolded word for non-articles. Only the most essential info should be bolded; for articles, it’s their class, and for non-articles, it’s their type. DFlhb (talk) 11:45, 30 July 2023 (UTC)
Yes, I agree with the bolding suggestion from DFlhb. Was about to come suggest the exact same thing for non-articles. - Favre1fan93 (talk) 19:25, 30 July 2023 (UTC)

I have coded 1 and 2.2 in the sandbox. To test it you can paste {{WikiProject banner shell/sandbox}} on pages in various namespaces and press preview. A couple of things to note:

  • We are missing icons for user pages, modules, help pages and interface page. So the NA icon will be used for these (unless anyone can find suitable icons).
  • Automatic detection works for all non-article classes except Disambig. I requested this at Template talk:Pagetype#Use Module:Disambiguation but it has not been coded there yet.

— Martin (MSGJ · talk) 11:22, 29 July 2023 (UTC)

Thank you for the mock up, it was helpful. Maybe I'm confused with the terminology, but I'm still getting hung up with the sandbox showing "This [x] is rated NA-class on Wikipedia's content assessment scale." To me, that is still visually confusing for say a draft talk page, because I know that is is rated "Draft-class" (which I'm stating given the existence of Category:Draft-Class articles). Am I looking at this the wrong way? As I said, does "class" mean multiple things for content assessment? That's why I think 2.1 wording should be used with Wikipedia:Content assessment#Non-mainspace content so there isn't that disconnect with the verbiage. - Favre1fan93 (talk) 15:15, 29 July 2023 (UTC)
At the risk of repeating myself, I will try and explain. Some projects use Draft-class and some do not. Suppose you have a banner shell with banners for projects A, B, C and D inside. Suppose projects A and C use Draft-class but B and D do not. We should not say that the article is Draft-class in the shell because this is supposed to represent all projects and this would not be true for projects B and D. — Martin (MSGJ · talk) 21:24, 30 July 2023 (UTC)
Got it, thank you for the explainer. As I've said elsewhere here, I'm in support of the 2.1 wording (plus bolding as suggested by DFlhb), so that would hopefully alleviate some of the confusion I originally had with 2.2's wording. - Favre1fan93 (talk) 21:06, 1 August 2023 (UTC)

Deployed

I've deployed 1 and 2.1 accordingly. 3 and 5 do not require any changes to the status quo. I think 4 should be discussed further at Template talk:WPBannerMeta because it relates to the uncollapsed view. It will also be harder to code because we will be separating the logic for the assessment row and the class bubble. — Martin (MSGJ · talk) 14:26, 3 August 2023 (UTC)

@MSGJ: I believe I'm still seeing 2.2 wording in the live template for drafts, files, projects, and users. Categories, featured media, portal, and templates all have the 2.1 wording (and all have their icons). Also, thoughts on adding the bolding as suggested by DFlhb above (and seconded by myself)? - Favre1fan93 (talk) 15:23, 3 August 2023 (UTC)
2.1 should be shown on all non-article pages. You may need to purge the page to update. If you still see something wrong, please can you give me an example? On the sandbox I have bolded the page type for non-articles. Please check how it looks. — Martin (MSGJ · talk) 14:54, 4 August 2023 (UTC)
Draft example: Draft talk:Thunderbolts (film); File example: File talk:Flag of Australia; Project example: Wikipedia talk:WikiProject Film/Marvel Cinematic Universe task force; User example: my talk page (for the file, project and user, all did not currently have the banner shell, but I made edits to show what I'm seeing). Those all have the 2.2 wording.
The sandbox bolding looks good. - Favre1fan93 (talk) 19:19, 4 August 2023 (UTC)
Okay I see what you mean. I need to take a look at the logic. Currently a blank class parameter is treated differently to non-blank even if they should resolve to the same thing — Martin (MSGJ · talk) 19:29, 4 August 2023 (UTC)
Ah got it. Other then that logic maybe needing to be worked out for if non-articles use |class=, it all looks good in my eyes! And adding in the sandbox code for the bolding. Thanks for all the work on this! - Favre1fan93 (talk) 19:57, 4 August 2023 (UTC)

I've been thinking about the logic needed here. How does the table below look? The only change is in the bottom left case. For example if |class=B on a redirect or template then that would be ignored and the type of page would be used instead. — Martin (MSGJ · talk) 20:39, 5 August 2023 (UTC)

class is defined class is not defined (or defined blank)
articles use class as global quality assessment if no project banners define class: use unassessed as global assessment
if one or more project banners define class: article has no global assessment
non-articles use namespace (and ignore class) use namespace
That seems correct to me and what I've been gathering about the template through this discussion. - Favre1fan93 (talk) 14:40, 6 August 2023 (UTC)
Sounds good. DFlhb (talk) 16:04, 6 August 2023 (UTC)
Just bumping on any progress finishing this up and implementing the logic changes needed. - Favre1fan93 (talk) 18:11, 18 August 2023 (UTC)
Thanks for the reminder. This code is now in the sandbox. I've just realised the logic will need to change again if we start to accommodate FM-class (being discussed elsewhere) because that is in the File namespace but we will need the wording "This file has been assesssed as ... " — Martin (MSGJ · talk) 05:15, 19 August 2023 (UTC)
I believe the sandbox looks good currently, if that's worthwhile to implement before the FM class parts are determined. - Favre1fan93 (talk) 23:04, 20 August 2023 (UTC)
I have implemented the sandbox so please let me know if you find anything unexpected — Martin (MSGJ · talk) 18:46, 23 August 2023 (UTC)

This is a bit random, but would it be possible to have a bot go through Category:Articles with conflicting quality ratings and remove the class= parameter from all redirects? Because currently, from what I can tell, the majority of pages in that category are redirects that are classed as stub or start-class. Happy editing, SilverTiger12 (talk) 12:52, 23 August 2023 (UTC)

@Qwerfjkl is currently working on this very task — Martin (MSGJ · talk) 18:10, 23 August 2023 (UTC)
@MSGJ, @SilverTiger12, BRFA filed. Sorry about the delay on this. — Qwerfjkltalk 11:37, 24 August 2023 (UTC)
Finally got this running, it should be finished soon. — Qwerfjkltalk 15:09, 3 September 2023 (UTC)
And  Done. @MSGJ. — Qwerfjkltalk 09:56, 4 September 2023 (UTC)

Icons

We have icons for most of the standard page types/classes defined. There are a few missing with suggestions below:

  • disambiguation pages - now in sandbox
  • user pages - now in sandbox
  • modules - suggested
  • help pages - what about
  • interface page - no suggestions yet

If you want to make suggestions, you could look in commons:Category:Norro style 1 icons and its subcategories — Martin (MSGJ · talk) 05:45, 19 August 2023 (UTC)

Interface: ? That's the only icon I could find that fits those pages.
For help pages, could also work, though I'm more in favor of your proposal. Turns out this icon is already being used for unassessed pages, oops. – MaterialWorks 16:47, 19 August 2023 (UTC)
I've used the W icon for now, but perhaps an icon with the pliers theme would be better per Gonnym? I don't think there is one in the Norro style 1 available yet — Martin (MSGJ · talk) 18:45, 23 August 2023 (UTC)
I think eventually a pliers theme would fit, given the administrator logo. - Favre1fan93 (talk) 14:05, 24 August 2023 (UTC)
I agree. —CX Zoom[he/him] (let's talk • {C•X}) 16:47, 31 August 2023 (UTC)
If it helps, is the image used for interface administrators. Gonnym (talk) 10:14, 21 August 2023 (UTC)
This didn't turn out nearly how I wanted, but here's something kind-of resembling pliers that someone might find useful to build off of: Closhund/talk/ 22:28, 1 September 2023 (UTC)
Could you "zoom out" the pilers so you see the whole tool in the circle? Or at least more of the tool? That might help. - Favre1fan93 (talk) 19:32, 3 September 2023 (UTC)
Yes, I just added the first version I tried that is zoomed out. I can make the tips of the pliers shorter too, but it just gets harder and harder to see. Closhund/talk/ 19:58, 3 September 2023 (UTC)
I think the zoomed-in version was actually clearer — Martin (MSGJ · talk) 10:08, 5 September 2023 (UTC)
I have temporarily reverted to the zoomed-in version, which seems to represent the object more clearly. Is everyone happy if we implement this? — Martin (MSGJ · talk) 11:20, 7 September 2023 (UTC)
I feel that both are good. —CX Zoom[he/him] (let's talk • {C•X}) 05:09, 10 September 2023 (UTC)
I've added the pliers icon. Thanks for making that Closhund! — Martin (MSGJ · talk) 15:09, 10 September 2023 (UTC)
Thanks. It's at least a stopgap until someone with an artistic bone in their body (unlike me) makes something better. Closhund/talk/ 03:05, 11 September 2023 (UTC)

Suggestion

See also: Template talk:WikiProject banner shell/Archive 9 § Icon for attention needed

When WikiProjects are displayed within the banner shell, each WikiProject now displays the class and importance in small colorful ovals. Could we do the same for other common parameters, such as |needs-photo= and |needs-infobox=. Hopefully making these needs more visible inline would inspire editors to add the needed content, and remove the parameters when the needs have been met. Thanks! GoingBatty (talk) 19:39, 2 October 2023 (UTC)

I did suggest something like this, and there was even a mockup of what it could look like. But it didn't seem to generate much interest. — Martin (MSGJ · talk) 21:58, 2 October 2023 (UTC)

Unassessed milhist articles

Hi, can I confirm that Category:Unassessed military history articles correctly recognises when the banner shell is tagged with a rating? As picking out Talk:Alan D. Gaff which is rated as a stub, it's appearing in the unassessed category. Thanks. -Kj cheetham (talk) 11:42, 25 September 2023 (UTC)

No, not currently. Milhist has opted out of PIQA by using the |QUALITY_CRITERIA=custom setting and so does not inherit its rating from the shell. However I think it would be safer to allow the banner to inherit when there isn't a conflicting class already defined. — Martin (MSGJ · talk) 13:30, 25 September 2023 (UTC)
I'd agree with that, though I'd imagine would need buy-in from that WikiProject too? -Kj cheetham (talk) 14:11, 25 September 2023 (UTC)
I can't see it being controversial. We'd only be supplying a rating if they didn't have their own. — Martin (MSGJ · talk) 16:21, 25 September 2023 (UTC)
True. -Kj cheetham (talk) 16:52, 25 September 2023 (UTC)
Only thing that worries me, is what happens if the inherited class is not one which the project uses? For example Template:WikiProject Video games uses a custom mask without A-class. If we put {{WikiProject Video games}} inside {{WPBS}} with |class=A then the rating should remain unassessed. — Martin (MSGJ · talk) 21:32, 25 September 2023 (UTC)
Milhist absolutely intends to buy in to the common assessment. We have moved to using the common WikiProject banner module. Our only requirement is that A-class continues to be supported. -- lead coordinator Hawkeye7 (discuss) 20:42, 4 October 2023 (UTC)
Great. A-class will continue to be supported as standard. The only barrier to Milhist joining is the rather bespoke B-class checklist rules. For example, if someone changes the rating to B but doesn't update the checklist then we have a rating conflict. — Martin (MSGJ · talk) 20:56, 4 October 2023 (UTC)

Thinking further on this, the best method would be to push the shell rating through the project's own class mask, which will ensure it is a valid rating for that project. However this will have other consequences, a main one being that projects using B-class checklists will not be able to inherit B-class unless the checklist is completely filled in. So I think the discussion at WT:COUNCIL needs to be resolved before we can do this. — Martin (MSGJ · talk) 13:42, 26 September 2023 (UTC)

Are the checklists only used for B-class? -Kj cheetham (talk) 18:30, 26 September 2023 (UTC)
B-class, C-class and occasionally on Start-class — Martin (MSGJ · talk) 12:11, 27 September 2023 (UTC)
@Kj cheetham: Although, technically, they'rte always called B-Class checklists - passing all six (or five in some cases) permits B-Class; failing one or more will downgrade the class. There is no corresponding "if it passes all of these, it's C-class" type checklist. --Redrose64 🌹 (talk) 19:21, 27 September 2023 (UTC)

Alignment

I have a suggestion for the template. Using Talk:Wikipedia as an example, I like how the WikiProject icons and the "[show]" columns are nice and straight. I don't like how the class and importance "bubbles" are staggered because their location is dependent on the length of the WikiProject name. I think the template would look cleaner if the class and importance bubbles were displayed in straight columns, too.

I understand the WikiProject names will always vary in length, but if the class and important bubbles had designated columns next to "[show]", aligned right, then there would be less staggering of colored bubbles.

Thoughts on moving the bubbles over next to "[show]" (right-aligned), so that their location is not dependent on the WikiProject name? Perhaps others are not bothered by the staggered bubbles. Sorry if this has already been discussed, I've not followed the discussions about recent changes to the template. Thanks! ---Another Believer (Talk) 03:39, 7 October 2023 (UTC)

I tend to agree with you. The current version was arrived at by consensus, but the preference for left-aligned was very weak. I'm not sure a columns layout would work because we need to consider mobile devices with small screens, but it may be worth mocking up an example for consideration — Martin (MSGJ · talk) 19:28, 7 October 2023 (UTC)
Treating names, class ratings, and importance ratings as columns with dynamic width would be an improvement, though I'm not sure how it would be implemented DFlhb (talk) 12:28, 9 October 2023 (UTC)

Collapsing

Hi all, I must have missed all this while not particularly active, but why don't we have a working collapse option and what are the implications of collapsing for the operation of these changes? I'm currently using a talk page which has a stupid number of banners, and I spend far long scrolling down to the actual talk page past stuff that few people ever maintain. Thanks for any advice. Peacemaker67 (click to talk to me) 05:18, 11 October 2023 (UTC)

collapsed=yes is documented, and hasn’t changed — Martin (MSGJ · talk) 05:33, 11 October 2023 (UTC)
Thanks. What have I done wrong here? Talk:Foibe massacres? Peacemaker67 (click to talk to me) 05:46, 11 October 2023 (UTC)
Nothing wrong at all - that looks collapsed on my browser — Martin (MSGJ · talk) 06:46, 11 October 2023 (UTC)
OK, thanks, must be because I'm on my iPad. Cheers, Peacemaker67 (click to talk to me) 06:57, 11 October 2023 (UTC)

WikiProject Lists not inheriting "list" class

I understand why WikiProject Lists doesn't inherit other classes, but is there a reason why it doesn't inherit "List class" when that's the project-independent rating? Thebiguglyalien (talk) 18:42, 15 October 2023 (UTC)

Yes the current behaviour is that projects with a custom quality scale need to opt out of project-independent quality assessments and will not inherit any classes. — Martin (MSGJ · talk) 19:17, 15 October 2023 (UTC)

Nomination for deletion of Template:WikiProject banner shell/redirect

Template:WikiProject banner shell/redirect has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. 65.92.244.127 (talk) 06:03, 21 October 2023 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:WikiProject_banner_shell/Archive_9&oldid=1263480696"