Template talk:WikiProject banner shell

How project banners should look

If anyone wants to code a working version, have at it. {{u|Sdkb}} ^talk 20:57, 29 May 2023 (UTC)

Expanding on my design rationale a bit, the first thing I did was to remove "WikiProject" in front of each project name. Users already know from the shell header that we're talking about projects, so it's redundant clutter. The next thing I did was grouping by priority. Currently, we have no standardized way to order WikiProject banners, and the importance ratings are just written out as text, which makes them hard to parse. The grouping addresses both of these issues by helping make it clearer which projects an article is most important to and further reducing the amount of text. {{u|Sdkb}} ^talk 21:05, 29 May 2023 (UTC)

Nice ideas. An intermediate step would be to list projects separately on each line with the importance on the left as you have suggested. — Martin (MSGJ · talk) 21:59, 29 May 2023 (UTC)

Whatever happened to "if it ain't broke, don't fix it"? LilianaUwU ^{(talk / contributions)} 13:43, 6 July 2023 (UTC)

The fact that the old design was cluttered and poorly organized, contributing to banner blindness, was the "broke" aspect. {{u|Sdkb}} ^talk 20:04, 6 July 2023 (UTC)

Looks like we're slowly inching ever closer to the French design; but I still have no idea how to reach a similar design while still supporting task forces. DFlhb (talk) 05:12, 2 June 2023 (UTC)

Task forces could be in parentheticals, e.g. Medicine (Ivermectin). But from a broad angle, wrangling the projects into this format would necessitate some amount of standardization, which would almost certainly tick off some projects that have particular banner customizations they like. {{u|Sdkb}} ^talk 06:07, 2 June 2023 (UTC)

Also, some WikiProjects have long names - for example Altered States of Consciousness; Correction and Detention Facilities; Hitchhiker's Guide to the Galaxy; Indigenous peoples of North America; National Register of Historic Places; Occupational Safety and Health; Orders, decorations, and medals; Politics of the United Kingdom; Social Housing in the United Kingdom; University of Southern California, to name but ten. Whilst some of these may be inactive or even defunct, their banners still exist and may be in use somewhere. --Redrose64 🌹 (talk) 10:13, 2 June 2023 (UTC)

Yeah, either we'd have to try to shorten those or we'd just deal with them as is. {{u|Sdkb}} ^talk 14:57, 2 June 2023 (UTC)

I think we should invite projects with long names to either devise their own short names, which we'd store in a data template someplace to retrieve the values, or we'd define them, and then we'd be able to derive them here: Altered States of Consciousness ⟶ Altered States; Correction and Detention Facilities ⟶ Correction/Detention; Hitchhiker's Guide to the Galaxy ⟶ Hitchhiker's Guide; Indigenous peoples of North America ⟶ Indigenous peoples (N.Am.); and so on. Mathglot (talk) 00:41, 21 June 2023 (UTC)

Made a mockup. We should avoid losing functionality at all cost, so it should also list custom quality ratings in the collapsed header for projects that opted out. And would be very nice if the banner shell could display project banners sorted by importance; would that be possible? DFlhb (talk) 16:59, 2 June 2023 (UTC)

I agree the mockup looks nice. I can see some potential confusion with NA (meaning non-article) vs N/A (neaning not applicable). It would be nice if the columns lined up when expanding the templates, but this is a small matter. — Martin (MSGJ · talk) 11:18, 5 June 2023 (UTC)

I added another mockup that solves the first problem and eliminates the second. Also enabled me to get rid of my new "Imp, WikiProject" header that took up precious vertical space.

I used a uniform shade of pink for all importance levels because all current importance colors have poor contrast at 14pt font size. The text is enough to differentiate them. I have a good reason not to worry about inconsistency with the WP1.0 tables that use the old colors, but that's beyond the scope of this discussion. DFlhb (talk) 15:58, 5 June 2023 (UTC)

Maybe simplest just to leave it blank if no importance is used? — Martin (MSGJ · talk) 18:25, 5 June 2023 (UTC)

Yes, much better edit: done, mockup changed DFlhb (talk) 18:40, 5 June 2023 (UTC)

I don't think I like the idea to depart from the default talk banner background colour to white in the lower exhibit. Further, the idea to show the importance level only a space apart from project name is not ideal. Let's say an article is Mid-importance for WP India, but High-importance for Delhi taskforce-- it'll show up as Wikiproject India / Delhi Mid-importance which, in my opinion, is not ideal. In the first exhibit, I do not like the addition of the "Imp. Wikiproject" row. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:56, 6 June 2023 (UTC)

And in both the cases there also needs to be the space for WPs opting for independent quality assessments. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:59, 6 June 2023 (UTC)

Great feedback.

1. Hmm. Hope I can convince you otherwise, I really prefer the white background! (Though I won't badger you beyond this, I promise.)
   1. Gives useful depth and hierarchy, to visually hint at a "shell" that transcludes separate elements rather than being a single element, and make it clearer that the project banners can be interacted with.
   2. Gives much better visual separation and hierarchy than the 4px padding and dotted border around the project-banner area, and IMO looks much better than that padding + dotted line.
   3. Prevents the long text inside each project banner from all being black/blue on yellow, which is unnecessary and less readable.
   4. I believe it's more coherent, more meaningful, and more visually appealing to have only the outer shell be colored, and all inner elements be white, across all TP templates (though I believe very few, maybe none, have "inner elements" like this one).
   5. WikiProjects having a different background color gives them higher prominence without increasing visual overwhelm, which makes up for the inherently lower prominence caused by collapsing them to just their header; that's pretty neat. The project banners would still be yellow when outside a banner shell, of course.
2. Very true. Added "margin-left:0.5em" before each importance bubble
3. Wholeheartedly agree, removed "Imp. WikiProjects".
4. Yup. Added a class mockup. It also neatly addresses my earlier criticism.

Will keep later replies short, sorry for this one's length. Permalink to previous mockup is here for future reference. DFlhb (talk) 19:50, 6 June 2023 (UTC)

@DFlhb, I really like the second mock-up. I agree with you that white looks better, and I also really like the rounded corners, which seems more modern and less harsh. {{u|Sdkb}} ^talk 20:37, 6 June 2023 (UTC)

I'm also coming round to mockup 2 as a clear and attractive design. The curved corners look nice, but would look odd with all the other banners which do not have curved corners. Better take that idea to a village pump and then we can change this template, tmbox, article history, ... in one go. — Martin (MSGJ · talk) 11:50, 7 June 2023 (UTC)

Beyond rounded corners, I want to propose a number of changes to talk page & article cleanup templates, to improve accessibility, readability & recognizability (sneak peek of just one, here). For these redesigns to have credibility, we'd need all of us (and hopefully others) to hash them out and refine them before ever bringing them to the understandably-conservative WP:VPR; just like we'll need to do for the "article type-article quality split". We can drop the roundness until then. Redrose64 mentions a harmonisation drive 15 years ago; we're overdue for a new one. DFlhb (talk) 12:19, 7 June 2023 (UTC)

I suppose the place to hash out these ideas would be Wikipedia talk:Talk page templates but drop a note here because that page is barely used — Martin (MSGJ · talk) 12:56, 7 June 2023 (UTC)

A harmonization drive is absolutely overdue. Just please ensure that the resulting standards are documented as thoroughly as possible, with pointers from tons of relevant pages to make sure they're easily findable. Otherwise there's no way they'll stick, and we'll just get standard proliferation. {{u|Sdkb}} ^talk 16:00, 7 June 2023 (UTC)

Thanks for making the relevant changes. I actually like the second style. However, can we see a mockup that right-aligns the importance and custom-class data, with the custom-class to the left of importance. And one mockup that uses a taskforce banner with a separate importance rating than its parent? Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:20, 7 June 2023 (UTC)

First one now done on mockup 3. I don't understand the second one; the current shell doesn't show TF importance in the header, even when it conflicts with project importance; are you saying both should be shown? DFlhb (talk) 22:49, 7 June 2023 (UTC)

Personally, I don't like having some of the information thrown to the right (Design 3). My laptop screen isn't that big, but it just looks too far away from the rest of the information when it's over there. —Carter (Tcr25) (talk) 22:53, 7 June 2023 (UTC)

No, that would be too much for the header. I just want to see how the new design gets along with taskforce shown. Basically, the issue I already said above, I just want to see it in practice. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:57, 8 June 2023 (UTC)

Done here. I reverted it because the medicine icon isn't spaced out correctly. Nothing is changing about banner contents except background color; the removal of the pink boxes is just a carry-over from mockup 1. DFlhb (talk) 20:11, 8 June 2023 (UTC)

Thanks for the mockup. I'm afraid that "High-importance" right beside "Pulmonology" doesn't look good. I think that right-alignment of importance would look better in these cases. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:30, 13 June 2023 (UTC)

They are effectively next to each other in the current design anyway:

WikiProject Medicine / Pulmonology   (Rated B-class, High-importance) — Martin (MSGJ · talk) 15:38, 13 June 2023 (UTC)

Can't say that I like the current version, but even that has all the importance ratings hanging from the same line which, like mockup 3, makes it look somewhat different from mockup 2 where rating sticks with the last taskforce. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:50, 13 June 2023 (UTC)

We may allow projects to optionally choose a header picture which will override the default picture if projects choose. So, they can keep a large picture as default, and a small different picture in header. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:56, 13 June 2023 (UTC)

I really like these mockups, but I have a complaint about designs 2 and 3: the background colors for the importance and class data are too close to the background white. There's not a lot of contrast in there, and that could be against accessibility guidelines. – MaterialWorks 12:56, 9 June 2023 (UTC)

The contrast guidelines are about the contrast between text and background, so I don't see any issue there. We could try a slightly brighter background though. — Martin (MSGJ · talk) 13:01, 9 June 2023 (UTC)

I see. I think using the colors used in design 1 (or a slightly lighter version of them, if they're too dark) would make the information clearer and easier to understand at a glance. – MaterialWorks 13:13, 9 June 2023 (UTC)

Is that better? What about the quality? — Martin (MSGJ · talk) 13:54, 9 June 2023 (UTC)

Yeah, that's way better. For the quality, I thought about using the colors used inside the class symbols (i.e. the lighter blue on the A-class symbol, as an example). So, the colors would be #d7eef4 for A-class, #c8fb7c for B-class, etc. – MaterialWorks 14:02, 9 June 2023 (UTC)

New one has insufficient contrast for both blue links & purple (clicked) links; the lighter pink is accessible against both. DFlhb (talk) 14:34, 9 June 2023 (UTC)

Okay I see what you mean about the clicked links. Please revert then. But if there is a slightly darker version of the pink which would still be accessible then let's try it. — Martin (MSGJ · talk) 14:39, 9 June 2023 (UTC)

Found #FFE6FF, accessible and slightly darker than before. Tested a few class colors, those aren't great for contrast either — DFlhb (talk) 14:49, 9 June 2023 (UTC)

Good compromise. I'm been struggling to find class colors that both:

• Fit with their icons;
• Conform to level AA of WCAG's color requirements. (AAA would be preferable, but Vector 2022's link colors can't pass that, even on an #FFFFFF background).

If you prioritize the first point, you get bad contrast; if you go for the second point, FA, C, Start and Stub all get roughly the same color. – MaterialWorks 15:48, 9 June 2023 (UTC)

I'd like to point out that MediaWiki:Gadget-metadata.css defines some colours which are used if you have "Display an assessment of an article's quality in its page header (documentation)" enabled at Preferences → Gadgets. --Redrose64 🌹 (talk) 23:00, 9 June 2023 (UTC)

RE quality, are we talking about the icon colour, or the blue background on the class in each banner? Bear in mind that most banners will no longer display the class inside the banner, so I don't think this is worth worrying about. — Martin (MSGJ · talk) 14:49, 20 June 2023 (UTC)

Design 4

@DFlhb: Thanks for the mockup — that's looking very nice! I do think that being able to list multiple projects per line will be an important step in reducing the vertical height, particularly for the highly active pages most at risk of banner bloat. I wonder if there is any way to retain the show/hide functionality while doing that — any ideas?

And yeah, sorting by importance level is definitely a key part of it (and something that we could potentially implement even without the fuller overhaul). {{u|Sdkb}} ^talk 19:41, 2 June 2023 (UTC)

Sidebar on sorting

Split off into subsection; some initial discussion above. {{u|Sdkb}} ^talk 20:12, 6 June 2023 (UTC)

N/A importance should be last, not at the top. SilverTiger12 (talk) 19:22, 5 June 2023 (UTC)

WP:TALKORDER says WPBio should be at the top ... — Martin (MSGJ · talk) 19:33, 5 June 2023 (UTC)

Okay, so to lay out the preferred order, we have this sorting:

1. WP Biography
2. Importance: Top -> High -> Mid -> Low -> Bottom -> N/A
3. Alphabetical

If that looks good, anyone who knows how can mock it up and implement. {{u|Sdkb}} ^talk 20:16, 6 June 2023 (UTC)

I supported this above, but only because my first mockup made the importance the most prominent part of WikiProject banner headers, and it was jarring for them not to be sorted. But with the second mockup, importance is no more prominent than the current template, so there's less need to sort. I'd now oppose it, since it would make projects like MILHIST or Film always go to the bottom, yet on many of their articles it makes sense for them to be towards the top (they're the most active, after all, and for many of these pages, they're also the most relevant). Probably best to keep letting people control the order manually. DFlhb (talk) 20:43, 6 June 2023 (UTC)

Icon for importance rating?

Just a suggestion: Can we use arrow icons for importance ratings? I couldn't find any, so here's one that conveys what I'm thinking of. We can have icons with progressively darker colors for higher importances as is current practice, with number of stripes denoting importance level. 1 for low, 2 for mid, 3 for high, 4 for top. All arrows would be pointed upwards. Bottom importance also exists, never seen it beyond WP:DOF pages, but it exists, so it would have one arrow oriented downwards. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:21, 16 June 2023 (UTC)

Might be worth doing a mock-up if you think this would be good. It would not be as clear as just writing "top-importance" though. — Martin (MSGJ · talk) 14:46, 20 June 2023 (UTC)

Yes, I like the idea, too. I'm thinking something more like something stacked, like a Tower of Hanoi (File:Hanoi 10Ring 3D Small.jpg), or a stepped pyramid like File:INES pyramid.jpg, for which we'd request six new image variant based on it from the Graphics Lab folks, one (lowest importance) would just show the bottom step, and then one each showing different numbers of stacked cross sections, up to "top" which would show the whole pyramid, up to and including the point at the top. (I'd probably change the colors either to match Template:Importance scheme, or use some other hue with increasing saturation

for each step up, and I'd make it 2-D, so a stepped triangle, not a pyramid). A simpler, and perhaps more natural image would be a two dimensional Tower of Hanoi cross section, so, basically just stacked horizontal bars which get narrower towards the top (somewhat like figure #1 at the left of File:Hanoi1.png but without the spindle); in this scheme, a color gradient might not be necessary, and they could all be stacked, horizontal black rectangles. For more ideas, try searching 7-level Likert scale icons. If you use chevrons, keep in mind that you may need to distinguish 7 levels. Mathglot (talk) 01:25, 21 June 2023 (UTC)

Moving ahead?

Do we have consensus to move ahead with any parts of the designs above? In particular it would be helpful if you could show your support for the following features:

1. Include a small image in collapsed version - Clear support
2. Change the background to white in collapsed banners - Rough consensus, let's trial it
3. Adjust alignment of quality and importance assessments to left (or right) - Yes, slight preference for left-aligned
4. Include a pale background colour on quality and importance assessments - Yes but exact colours need further discussion
5. Remove word "WikiProject" from each banner - Support implied/assumed

— Martin (MSGJ · talk) 09:09, 29 June 2023 (UTC)

Suggest we hold off on the curved corners until a more general discussion on message box harmonization takes place — Martin (MSGJ · talk) 09:11, 29 June 2023 (UTC)

Agreed! But I think we could use curved corners as a fairly small/easy change as a test case to start establishing a strong system for message box standardization (see my comment above re "standard proliferation"). {{u|Sdkb}} ^talk 14:18, 29 June 2023 (UTC)

Thanks to everyone for comments so far. I have updated list above with my summary of where editors stand. I have also added #5 which I forgot but I believe to be uncontroversial? @Mathglot, DFlhb, and Redrose64: you took part in the earlier discussion but have not yet added your vote. I will try and get this coded at the weekend. — Martin (MSGJ · talk) 11:38, 30 June 2023 (UTC)

• 1. Yes; 2. Yes; 3. Right; 4. [bgcolor: Yes, pale: unsure] - I like the idea to have bgcolor for importance and quality, but I'm not sure that having the same color for low and top-importance is good or if we should have a spectrum for it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:14, 29 June 2023 (UTC)

  I support right-alignment because that way importance isn't stuck close to taskforces (if exists) as individual task forces might have different importance from its parent. This alignment also ensures that the pink box of importance appears neatly in a column, instead of being scattered across the shell, depending on the length of project and its taskforces name. To @Tcr25: The distinctive strips for each project adequately connect the project and its ratings together. —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:11, 29 June 2023 (UTC)

  Sorry @CX Zoom, I appreciate the idea of keeping the pink boxes aligned, but to my eye the strip doesn't suffice to connect the importance/rating with the project because I have to scan too far over to see them. Keeping the information together is more efficient for the reader (even if it sacrifices some cleanness in the design). —Carter (Tcr25) (talk) 12:29, 29 June 2023 (UTC)

• 1. Yes; 2. Yes; 3. Left (but happy with Right also); 4. Yes. Not sure about the idea of a spectrum but accessibility is the more important consideration. — Martin (MSGJ · talk) 10:04, 29 June 2023 (UTC)
• 1. Yes; 2. No (inconsistent with other talk page banners and boxes); 3. Left; 4. Yes, but I don't think we should use pale colors. A spectrum like what the French Wikipedia uses would be good too. – MaterialWorks ping me! 10:12, 29 June 2023 (UTC)

  Are you happy with the colour that you said was "Good compromise" above? — Martin (MSGJ · talk) 11:39, 30 June 2023 (UTC)

  Yes, I think it would work well for low or mid-importance. Still need to find good colors for the other imp. ratings. – MaterialWorks 11:49, 30 June 2023 (UTC)

  I assumed we were just discussing the change to the header in the nested version, and I have added the standard colours back in the expanded version in Design 3 above. However it is essential that we comply with MOS:ACCESS so if these do not meet the contrast guidelines then we should make them paler. — Martin (MSGJ · talk) 12:02, 30 June 2023 (UTC)

  I agree. We'll definitely have to change them, since the standard top-importance color just barely passes WCAG AA against Vector 2010's unclicked link color.

  PS: For posterity, the nested assessments with the standard colors would look like this:

  Top‑importanceHigh‑importanceMid‑importanceLow‑importance – MaterialWorks 16:59, 30 June 2023 (UTC)

  I like this more than I do a constant pale color. Although, each could be made a shade or two paler if proper contrast with text isn't acheived here., —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:14, 30 June 2023 (UTC)

  It seems to me that if we use pale colours there simply will not be the range of colours available to make a visual distinction between different shades. And if don't use pale colours it will fail WCAG. I agree a visual distinction would be nice, but I don't think we can do it with background colours. — Martin (MSGJ · talk) 07:22, 1 July 2023 (UTC)

  Just a thought. Could we use some shade of colour between #F9E9BA and #FFFFFF as a compromise? Please check design 3 above? — Martin (MSGJ · talk) 07:28, 1 July 2023 (UTC)

  Oppose the cream background; I don't think it looks good or serves a semantic purpose, and the cream you picked is roughly what I planned to suggest as the default tmbox colour (since the current yellow is a contrast fail for both blue & purple links, on every Wikipedia theme, and most tmboxes are chock-full of links). DFlhb (talk) 10:16, 1 July 2023 (UTC)

  Oppose, I have to squint really hard to even notice the background color. If you can't see the color well, what's the point of using it? Plus, like DFlhb said, it doesn't serve any semantic purpose. – MaterialWorks 10:49, 1 July 2023 (UTC)

• 1. Yes; 2. No (agree with MarterialWorks' point); 3. Left (pushing to the right disconnects it too much from the WP name on standard-sized screens); 4. Indifferent (slightly opposed because too many colors and things going on starts to look cluttered, but this is a more an aesthetic concern than a UX one). —Carter (Tcr25) (talk) 11:28, 29 June 2023 (UTC)
• 1. Yes; 2. Yes (banner collapsing is unique enough that I don't think there's really a pool for it to be consistent in); 3. Yes (prefer right, but fine with either); 4. Yes. Thanks for all the design efforts! {{u|Sdkb}} ^talk 14:15, 29 June 2023 (UTC)
• Yes to all. Thanks for your work on this. Hopefully the text in each sub-banner can be combined or reduced next. czar 13:40, 30 June 2023 (UTC)

  @Czar: Just for clarity, on #3, you mean left or right alignment? —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:06, 30 June 2023 (UTC)

  Right (thanks!) czar 01:05, 1 July 2023 (UTC)

• Yes to all (so, design 2). Design 3 places semantically-related elements far apart, not ideal. White background for both project headers and project banner contents helps establish visual hierarchy, so I prefer that (and see the other reasons I listed earlier).

Accessibility is better than I said previously, since I'd forgotten that WCAG 2.0 defines "Large Text" as either normal 18pt+ or bold 14pt+ (and here, it's bold). Mea culpa. But Top-importance still has insufficient contrast on Vector 2022, Timeless, and Minerva. We could fix that by shifting each color slightly. New colors: #FFE6FF for Low, #FFCFFF for Mid, #FFB8FF for High, #FFA3FF for Top. For the class bubbles, here are some new colours with improved contrast: #FFB477 for Start, #FFAFAF for Stub, #CDB9FF for List, #A8C4FF for FA, FL and FM. For non-standard grades: #E9AFFF for Current-class, #B9C0FF for Future, #FFAFAF for Stub List, #E7BBA6 for Draft, #DDBCC4 for Portal, #C7C795 for Project. The rest should be fine. Tried to change each color as little as possible to just meet the minimum contrast ratio.

The coloured bubbles look a little overbearing to me with those colours, so I've added design 4 for consideration & refinement. Still support design 2, whether we go with pale colours or the normal gradation. DFlhb (talk) 10:16, 1 July 2023 (UTC) Rewrote second paragraph: changed my mind, I'm fine with the full gradated colours, and that's a minor aspect that can be refined later. I don't want that to hold-up the other changes. 16:50, 1 July 2023 (UTC)

How important is it that we have the importance and quality linked in the nested version? We don't currently link these, and the links are readily available in the uncollapsed version — Martin (MSGJ · talk) 09:54, 3 July 2023 (UTC)

Fine to remove. Visual simplicity is good. DFlhb (talk) 14:39, 3 July 2023 (UTC)

I too support removal of links, it is present in uncollapsed version already. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:23, 3 July 2023 (UTC)

• I support the above changes; however, does this proposal also include the suggestion of auto-sorting WikiProjects' position by importance? Because I currently oppose the suggested implementation for that. --SilverTiger12 (talk) 00:05, 3 July 2023 (UTC)

  No, that suggestion is not part of this proposal. We are confirming support for points 1-5 at this stage — Martin (MSGJ · talk) 07:33, 3 July 2023 (UTC)

Test3 is basically unreadable for me. Test2's yellow and light green on white are not friendly. And test1's black on yellow contrast is not nice to read either. The colors are what they are, so maybe look and see what else can be done on the point. Test3 might work for me with black borders or black text. Test1 is probably the best in the general.

As for rounded corners, it's not a terrible thing inline as in these cases (though it may be part of the cause for the inline issues I'm having here), but doing a full banner rounded corner I am strong not in favor of. One, because it breaks from general style that was set down 15 years ago after a whole lot of discussion, and two, let's not follow the apparent web trend that has put rounded corners back in our lives after they had fallen out of favor by the time border-radius finally got standardized 15 years ago. Izno (talk) 18:16, 4 July 2023 (UTC)

Any ideas on how you'd adjust test1? I was about to remove the code for test2 and 3 anyway to finalize the code for testing DFlhb (talk) 18:22, 4 July 2023 (UTC)

I'm almost thinking you don't need the color at all in the summary line. I don't see a lot of discussion of that above. You'd have to adjust whitespace some. (And, I've always thought the priority color scheme of various pinks and purples was ugly, but that's besides the point.)

Alternatively, could just put the colors in that are high quality like A, GA, and FA, and then the absence of color indicates stuff to work on?

It really is just the B and C class colors that are an issue here, the others are coming out fine.

Speaking of importance, some projects use "priority", does this module take that into account when using the word "importance"? Izno (talk) 18:33, 4 July 2023 (UTC)

Yes, takes into account "priority" vs "importance" (lines 337 and 362).

B and C might be bothering you because they've got the lowest contrast against the background (though it means those two also have the highest contrast against text, which is what counts for accessibility). Tested both of your suggestions in Dev Tools and IMO, without some/all colours, something feels missing; and somehow it feels more verbose and busier with the same amount of text. DFlhb (talk) 21:18, 4 July 2023 (UTC)

We could go back to using a nice pale background Design 2 ... — Martin (MSGJ · talk) 21:24, 4 July 2023 (UTC)

MSGJ: design 2 is based on using the same pale pink for all importances, and the same pale blue for all classes; don't thing it look good, but I could make a testcase if you'd like. If you're suggesting something else, I'd appreciate specific colour values.

Izno: what B-class colour do you suggest? And keep in mind that if B and C are the only issues, that'll go away in 99% of cases after the article-class conversion bot run, since they won't appear. Also, in the test cases, I've unbolded the bubbles; do B and C look any better like this?

Also, feel free to use User:Jackmcbarn/advancedtemplatesandbox.js on the sandbox module (with "Template name" set to "Module:WikiProject banner") to test how it looks on any talk page without modification. DFlhb (talk) 10:38, 5 July 2023 (UTC)

Well Design 2 is still the best in my opinion (without the linking inside the bubbles). But I'm happy to go with the majority and proceed on current basis as I don't want to hold up progress — Martin (MSGJ · talk) 11:44, 5 July 2023 (UTC)

Let's see if we can't balance the fore-background and the white background better. We have some room to play with I would guess. Izno (talk) 22:24, 4 July 2023 (UTC)

Check #FFEB00 as the C-class background & border in browser Dev Tools; is it better? DFlhb (talk) 23:17, 4 July 2023 (UTC)

That's good for C, but now it's not pretty next to B. Izno (talk) 00:03, 5 July 2023 (UTC)

And yeah, I can take or leave the no-colors suggestion. Izno (talk) 22:24, 4 July 2023 (UTC)

And yeah, rough consensus on the white feels right; not sure I'm a fan but pretty sure I could get used to it. Izno (talk) 18:19, 4 July 2023 (UTC)

Coding complete in sandbox

Thanks to DFlhb for his help, we now have this coded in the sandbox. There are two sets examples at Template:WPBannerMeta/testcases. They are aligned right, but this could be put back to left if people prefer. Personally I prefer the paler backgrounds that were proposed earlier. Waiting for final comments from people — Martin (MSGJ · talk) 14:30, 3 July 2023 (UTC)

Any reason why #5 wasn't implemented? – MaterialWorks 14:45, 3 July 2023 (UTC)

Haha, totally forgot. Will do it now! — Martin (MSGJ · talk) 14:46, 3 July 2023 (UTC)

 Done — Martin (MSGJ · talk) 14:48, 3 July 2023 (UTC)

Also, do we have a consensus on rounded corners? Seems like a quite a controversial change to do without a discussion first. – MaterialWorks 14:54, 3 July 2023 (UTC)

Agreed and removed. I would like to see this developed in conjunction with other talk page message boxes — Martin (MSGJ · talk) 15:03, 3 July 2023 (UTC)

I think I also prefer the pale icons. The full colors don't look great. DFlhb (talk) 15:12, 3 July 2023 (UTC)

RE [1], no it might be my eyesight but I really can't discern the different colours at 0.12em thickness. And most icons are wider than they are long, so x25px or x30px might be better than 20px in many cases. — Martin (MSGJ · talk) 15:12, 3 July 2023 (UTC)

The inspiration for the x20px project icon sizes was {{Article history}}, which also sets its miniature icons to x20px, and the goal was to keep the height of the banner unchanged. But we can change it of course. And isn't there a rough consensus for left-aligned? DFlhb (talk) 15:25, 3 July 2023 (UTC)

mockup5/test3 is an accessibility nightmare, its nigh-impossible to read the importance ratings against the white background. – MaterialWorks 15:24, 3 July 2023 (UTC)

Absolutely; the colors were supposed to be #D67A7B for Stub, and #FF00FF for Top (#D5803C for Start, #9A9A00 for C) but it's a bit difficult (for me anyway) to implement custom colors now that the bubble code is a separate function and shared among all bubbles; I'll try. DFlhb (talk) 15:31, 3 July 2023 (UTC)

• My preference: test1 > test2 >> test3. But, here's a little issue. If I reduce the width of the browser window to the lowest possible width, the one with both "Stub" & "Top" tag overflows out of the banner, even though there's white area to its left. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:35, 3 July 2023 (UTC)

  To be clear, if there is space deficiency, it should line wrap like normal tables (or it might be made more dynamic, flexbox?), but not overflow. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:06, 3 July 2023 (UTC)

  edit: now fixed DFlhb (talk) 17:00, 3 July 2023 (UTC) updated 18:17, 3 July 2023 (UTC)

The color on N/A is practically invisible to me in test3 and it gets worse when I run it through a color blindness simulator. I'd favor test 2 over test 1 because the more subtle use of color makes things look less busy to my eye (test three the colors wash out the text too much). I still strongly prefer having those elements to the left, not the right. —Carter (Tcr25) (talk) 19:11, 3 July 2023 (UTC)

test3 is now finished, and I've put all the standard classes on the testcases page so people can see how they look. My preference is test 1 > 3 > 2, and strongly prefer left alignment. The full colours look better than I thought now that the blue links are removed. DFlhb (talk) 20:09, 3 July 2023 (UTC) updated 20:54, 3 July 2023 (UTC)

I suggest we go with option 1, as this more closely matches the design we have been developing and not many people have supported option 2. I have put the alignment back to "left". Any last comments on the testcases? — Martin (MSGJ · talk) 07:32, 4 July 2023 (UTC)

DFlhb: I am aware you have made changes to a number of templates and style sheets to implement the new design and also fix the spacing glitch. Would you mind listing them here so I can be sure I update them all? — Martin (MSGJ · talk) 07:56, 4 July 2023 (UTC)

Will do. I'm running more tests now. I'd like to understand the page purging behaviour better. CSS, modules, and likely non-module templates will need to be changed; will all three reverberate instantly, without purging? Just the first two? Just CSS? None? DFlhb (talk) 11:55, 4 July 2023 (UTC)

Apologies if I missed it earlier in the discussions, but how will something like Talk:Louisiana Purchase present when you have a lot of child projects present, some with different ratings. Louisiana Purchase is part of WikiProject United States and the nested WikiProjects Arkansas, Franco-Americans, Louisiana, New Orleans, and History with importance ranging from High to Top. Will just WikiProject United States show up in the collapsed state? Will WikiProject United States / Arkansas, WikProject United States / Louisiana, etc., appear on separate lines? Or will it show WikiProject United States / Arkansas / Franco-Americans / Louisiana / New Orleans / History like the current display does with just the highest priority rating showing? —Carter (Tcr25) (talk) 13:26, 4 July 2023 (UTC)

This is unchanged; it shows all nested task forces, and the importance rating defined for the project overall (not the highest priority among its task forces). DFlhb (talk) 13:38, 4 July 2023 (UTC)

Thanks. —Carter (Tcr25) (talk) 13:42, 4 July 2023 (UTC)

Deployed

Change has now been deployed. DFlhb (talk) 12:21, 6 July 2023 (UTC)

— Martin (MSGJ · talk) 12:23, 6 July 2023 (UTC)

Looks nice: example- Talk:Louisy Joseph. —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:28, 6 July 2023 (UTC)

The new version seems to only show up in pages where the class parameter of the shell is filled (example: Talk:Biboy Enguio), is this intended? – MaterialWorks 13:00, 6 July 2023 (UTC)

It'll show up everywhere; that page just wasn't purged yet. DFlhb (talk) 13:05, 6 July 2023 (UTC)

@MaterialWorks: The new style is showing now. Considering the huge number of impacted pages, it would take time for the changes to carry over completely. In the meantime, you can WP:NULLEDIT the page (or make any edit to it) and the changes will show up. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:05, 6 July 2023 (UTC)

First bug found. When the class is blank, a bubble is still produced, e.g. Talk:Dysidazirine. Fixed in Module:WikiProject banner/sandbox I think — Martin (MSGJ · talk) 14:00, 6 July 2023 (UTC)

 Fixed — Martin (MSGJ · talk) 14:07, 6 July 2023 (UTC)

Some of the icons for projects are too wide, overlapping with the text. See e.g. the higher education icon at Talk:Haverford College. Could that be fixed? {{u|Sdkb}} ^talk 20:32, 6 July 2023 (UTC)

My only gripe with the new design is the white background. I hope there's consensus to change it back to yellow. SWinxy (talk) 21:50, 6 July 2023 (UTC)

Cream background colour now visible at Template:WPBannerMeta/testcases. Picked the same color as the background to the shell's |BLP=yes banner, which'll look nicer on pages like Talk:William Gibson. DFlhb (talk) 23:12, 6 July 2023 (UTC)

Yeah I like this. There's also an edge case for when non-WPBM templates are inserted into WPBS, e.g. Talk:Family of Donald Trump, where the inner banner is a different color. SWinxy (talk) 23:32, 6 July 2023 (UTC)

Tbf, Top25 report really shouldn't have been there. This is "WikiProject banner" shell after all. Those should go under {{Banner holder}}. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:36, 6 July 2023 (UTC)

Improved it hopefully.. DFlhb (talk) 23:53, 6 July 2023 (UTC)

Would appreciate more people weighing in on the background colour. DFlhb (talk) 08:52, 7 July 2023 (UTC)

Happy with either. I did previously suggest using a creamy colour. It's closer to the original colour and so will probably cause less surprise. I think people will get used to white but it is just such a sudden change. — Martin (MSGJ · talk) 09:59, 7 July 2023 (UTC)

Cream looks good to me. I'd say I have a slight preference for it over white. {{u|Sdkb}} ^talk 14:50, 7 July 2023 (UTC)

I'm also cool with cream background, alongside V4 pale colors exhibited below. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:09, 7 July 2023 (UTC)

• I think that the quality colors could be made a little paler. Imo hese are too bright, so much that it distracts me from the global rating that should've been more prominent on the banner. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:11, 7 July 2023 (UTC)
  • Perhaps this question of colours should be asked in a more visible forum rather than just here? -Kj cheetham (talk) 11:21, 7 July 2023 (UTC)

  I agree - design 2 was the best with subtle paler colours — Martin (MSGJ · talk) 11:25, 7 July 2023 (UTC)

  I like "v4" the best, in the testcases (link). DFlhb (talk) 13:12, 7 July 2023 (UTC)

  I also liked the open circled version used in the (early on #2 in the test cases) and similar to design 4 above. It incorporates the color without being as overwhelming as when the color fills the full background. —Carter (Tcr25) (talk) 13:36, 7 July 2023 (UTC)

  OOoooo yeah I like those pale pastels. SWinxy (talk) 13:42, 7 July 2023 (UTC)

I have never participated in technical discussions on WP, as it is far outside my wheelhouse, but I would respectfully ask that you stop this deployment until you have input from the wider community and have checked with experts on disability. I was unable to continue working on a GA review on Maria Mies yesterday because I inadvertently looked at the new banner shell. All of the bright colors and icons caused my sensory vertigo to kick in rendering me unable to see anything on the page. Bottom line is that now I question if I will be able to look at any talk page with a banner shell without it triggering nausea, headache, dizziness and seeing spots. Unfortunately, the only way to know that is to look at a talk page and I am not willing to risk that. This cacophony of colors has rendered article talk pages off-limits for me, which impacts my ability to work. I am not here to discuss this to death or be bullied, simply to tell you that there are actual consequences for people with sensory issues that must be addressed before you launch changes like this. I am not watching this page and do not intend to participate further. SusunW (talk) 14:33, 7 July 2023 (UTC)

Sorry to hear this. You're very welcome to the discussion. Before you go, can you just let us know if the paler background colours on version 4 are an improvement? — Martin (MSGJ · talk) 15:03, 7 July 2023 (UTC)

I am sorry, but I am not going to look at it and risk being sick. If there are colored icons, bright screaming highlighted colors (Mies's talk had neon green, yellow, orange and purple) and a brilliant white background, it will trigger my problem even if I have the filtering glasses I wear on. Words and the beige background it used to have were fine. All of these additional colors are not. SusunW (talk) 15:13, 7 July 2023 (UTC)

I apologize. For version 4, the saturation of each color was lowered ~60% to be equal to, or lower than, the old beige, so I really hope that fixes the issue. DFlhb (talk) 15:38, 7 July 2023 (UTC)

I respectfully point out that this is a serious issue and again ask that you refrain from making changes without consultation with the wider community and disability experts. Tweaking it and continuing this path without broader consultation makes all editors "test subjects" for these experiments and runs the risk of causing real difficulties for some editors. I have no idea what lowered ~60% means, but if multiple colors are still there, I may have an issue, as will others. This isn't about a "preference" it is about not causing harm. Please hear me, I am not going to look at a talk page to see if it triggers me. Please put the old system back, which wasn't causing issues, until you have had a real consultation. If after consultation, disability experts and the community at large give a pass to this, I'll have to make a decision as to whether I can continue editing. SusunW (talk) 15:57, 7 July 2023 (UTC)

SusunW, I know we're collectively sorry that this update has impacted you so strongly. I believe the changes comply with all current Wikipedia accessibility guidelines but I understand how they adversely affect your individual experience. MSGJ and DFlhb, I really like version 4 and we should deploy it, but I don't think that will solve SusunW's issue. Where would we start the process of creating a tool that allows editors to "opt out" of the upgrade and view the old shell as part of their custom user settings? Thanks.— TAnthony^Talk 16:06, 7 July 2023 (UTC)

Thank you TAnthony, that would be a start. For those of you who may think this is not a real issue, [2], [3] SusunW (talk) 16:17, 7 July 2023 (UTC)

An "opt out" seems a bit insufficient to me, as you've already exposed it to people like SusunW by then. Why not a more public consultation somewhere? -Kj cheetham (talk) 16:30, 7 July 2023 (UTC)

Ideally these could happen simultaneously. Stop the deployment, have a consultation, and work on an opt out. SusunW (talk) 16:35, 7 July 2023 (UTC)

As an immediate fix, the colors can be fully reverted to the old ones by creating a user-specific style sheet (link), and copy-pasting everything here into it verbatim, then clearing or bypassing your cache so the new style sheet gets used. Though I'm aware that's not an optimal solution DFlhb (talk) 16:48, 7 July 2023 (UTC)

Are you suggesting that I do something technical to reverse the changes you have made? I have no idea how to do that and looking at those links you provided means absolutely nothing to me and isn't instructional or intuitive for me. As I said before, I do not understand WP technology. A more logical immediate fix would be to undo the deployment and wait for a wider weighing in. It is beginning to feel as if I am wasting time that I could be contributing to building the encyclopedia to continue this discussion because the deployment is just plowing ahead without regard for the harm it may cause. SusunW (talk) 17:01, 7 July 2023 (UTC)

@SusunW, if you're okay with it, @MSGJ as an admin could edit your CSS page for you to restore the old colors. Again, that's only as a temporary fix while we figure out a more permanent solution. {{u|Sdkb}} ^talk 17:12, 7 July 2023 (UTC)

Please. SusunW (talk) 17:14, 7 July 2023 (UTC)

@Sdkb: He can't. Needs to be an interface administrator. See WP:INTADMIN#Technical access. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:19, 7 July 2023 (UTC)

Ah, I misread the "editusercss" permission. In that case, @Izno, would you mind lending a hand if you're around? {{u|Sdkb}} ^talk 17:54, 7 July 2023 (UTC)

Happy to make the changes if someone will tell me what to change. @Sdkb Izno (talk) 17:57, 7 July 2023 (UTC)

@Izno, thanks! The request is to create User:SusunW/common.css with the contents copied from here. {{u|Sdkb}} ^talk 18:00, 7 July 2023 (UTC)

Should be done. Izno (talk) 18:01, 7 July 2023 (UTC)

Will someone go to the talk page on Maria Mies and tell me specifically that it is beige and has text. No tiny colored icons, no screaming highlights? Thank you. SusunW (talk) 18:03, 7 July 2023 (UTC)

The only one who can test that is you, unfortunately. You can try closing your eyes and when you get there press (all three together) Ctrl + Shift + R, which will hard refresh the page, but you'll have to open them to check. Or if you have another able-bodied person lying around. Izno (talk) 18:04, 7 July 2023 (UTC)

Every color and highlight is gone and replaced with beige; though the icons remain. Give me a second and I can take them out too. DFlhb (talk) 18:05, 7 July 2023 (UTC)

I checked it by copying the css code to my stylesheet, and the bright bgcolors are gone. Should be the same for you too. Don't worry. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:06, 7 July 2023 (UTC)

Really afraid to look, but I did. The icons are there, but larger, more space keeps them from being jumbled into a mass of color and there are no highlights. I am able to see it without it causing the problem. Thank you! SusunW (talk) 18:11, 7 July 2023 (UTC)

For those unsure, this is Talk:Maria Mies. --Redrose64 🌹 (talk) 23:08, 7 July 2023 (UTC)

Really sorry to hear of this. I'm a bit confused about what specifically in the change triggered the reaction, though, as there are lots of templates on Wikipedia that use bright colors and icons (as part of the overall 2000s-ish design). If we can figure that out more specifically (and I totally understand you not wanting to look at it again, SusanW), it'll be easier to resolve. I'll leave a note at WT:ACCESS to hopefully bring in some more accessibility-minded editors. {{u|Sdkb}} ^talk 16:58, 7 July 2023 (UTC)

I wish I knew specifically and then I could avoid it. Various times computers caused me issues, but when we bought a new television 8 years ago, nightly I was projectile vomiting and dizzy. After consulting with a physician, he ran a bunch of tests and diagnosed me with cyber sensitivity. My issues are related to both color and backlighting. I can tell you that the previous text with larger icons did not cause a problem. The many small icons and brilliant colors on Mies's talk yesterday triggered the problem, so my guess would be overload. Too many images, too many colors. SusunW (talk) 17:07, 7 July 2023 (UTC)

I checked that talk page- the banner shell is supposed to collapse once it contains a certain number of WikiProject banners yes? To limit/avoid banner blindness and fatigue? But there were five or six there and I had to add the collapse=yes parameter. SilverTiger12 (talk) 18:23, 7 July 2023 (UTC)

It's not, the shell doesn't autocollapse as far as I know. There was a discussion for it, but there was no consensus for autocollapsing. – MaterialWorks 18:52, 7 July 2023 (UTC)

@SilverTiger12, @MaterialWorks, yeah, I thought for a while that there was some threshold for autocollapsing, but then I found that failed proposal. As I see it, the core issue is that, even with the new design, we still devote an entire line to every project. This means that on highly active pages (the ones most at risk of banner bloat) with many projects, the uncollapsed banners can sometimes occupy 10+ lines. If we changed it so that all projects at a given importance level are listed on the same line (as in the mockup at the very beginning of this section), it would never go onto more than a few lines and we wouldn't really need to worry about collapsing. {{u|Sdkb}} ^talk 20:52, 7 July 2023 (UTC)

I very much appreciate SusunW's reactions here. As she is one of Wikipedia's most constructive and successfull editors, I am devastated by the problems this small group of technical editors are causing her. If any administrators are reading this page, I would urge them to revert the entire deployment as soon as possible. Changes like this without appropriate consultation should not be allowed.--Ipigott (talk) 18:10, 7 July 2023 (UTC)

I appreciate you Ipigott. This has been very difficult for me to work through, as even broaching a technical issue is hard for me. I honestly think it should not have to be an individual fix for "certain" editors. We need to be more aware that our collective actions may impact others. SusunW (talk) 18:14, 7 July 2023 (UTC)

Personally, I found both the bright colors and white background very useful. And I have a [different] sensory issue. So I oppose reverting the deployment, because you're not going to be able to satisfy everyone. Happy editing, SilverTiger12 (talk) 18:21, 7 July 2023 (UTC)

I agree that if a deployment is done it may not satisfy everyone, but would argue that a deployment should rarely (possibly never) be done without an opt out having been created and a wide consultation. SusunW (talk) 18:28, 7 July 2023 (UTC)

For the record, I do want to note that this update was deployed in good faith by editors who engaged in detailed discussion, performed adequate notification and considered accessibility guidelines. Editors in this discussion have been talking about "consultation" as if we run every template change by a committee of accessibility experts before updates are made, and we just don't. And shouldn't need to in most cases. I think we can agree no one involved could have anticipated the terrible and unfortunate impact that the nature of this template update has had on SusunW, and potentially other editors. Nothing "wrong" has occurred here, and I for one am impressed at the speed at which the team was able to address the issue, at least temporarily. Thanks to all. — TAnthony^Talk 18:56, 7 July 2023 (UTC)

Concur. In the #Moving ahead? section above, we had input from nine editors and fairly clear agreement, which seems a reasonable level of consensus on a template's talk page to make a change to that template. In retrospect, it's really unfortunate that we didn't discover the sensory vertigo issue during that phase, but we know of it now.

As for where to go from here, given that the white banners seem to have been at least part of the issue, and that overall reaction to the cream option @DFlhb mocked up in the testcases has ranged from neutral to highly positive, I think we should go ahead and deploy that to reduce the risk anyone else has a similar adverse reaction. As always, we can continue to refine the design from here — the iterative process applies to article work the same as it does to content work. Best, {{u|Sdkb}} ^talk 19:01, 7 July 2023 (UTC)

Giving heads up to design changes to WT:ACCESS (or a new noticeboard) to invite discussions on design would be good for pointing out accessibility but very bad because nothing will ever get consensus. SWinxy (talk) 19:28, 7 July 2023 (UTC)

I generally notify WT:UX of discussions like this, so feel free to follow that page. (In this case, it was missed because this section started out as more of an early stage idea brainstorming and only later turned toward implementable changes.) {{u|Sdkb}} ^talk 20:54, 7 July 2023 (UTC)

Cream background now deployed. Hopefully that's a better middle-ground between various accessibility needs. edit: bubbles are now much paler too, and none are more saturated than the previous beige shell colour (many are less saturated). DFlhb (talk) 20:36, 7 July 2023 (UTC)

That seems much less garish and distracting to me (that means, much better; banners are not supposed to be a distraction). I hope it is also less problematic for the bright-color-sensitive. —David Eppstein (talk) 21:07, 7 July 2023 (UTC)

‎Why is this local consensus allowed to deploy changes to all of Wikipedia without wider community involvement?

Simple question. The local consensus of 10 people above should not be allowed to make such a massive change to all Wikipedia articles without broader community involvement through a general RfC decision. I find it rather telling that there wasn't a plain option in the discussions above to oppose any changes happening at all. So I suppose I should state it here, even with the beige changes made above after having to be actively prodded by other editors about the really obvious visual accessibility problems with the forced through design change, I oppose all design deployment without a community RfC on the change. Silverseren^C 06:22, 8 July 2023 (UTC)

I also welcome the beige shading but I agree with Silver seren that a drastic change like this should first be submitted to wider consultation.--Ipigott (talk) 07:06, 8 July 2023 (UTC)

I concur. Absolutely shouldn't be a wider consultation for all template changes, but banner shell is incredibly widely used and this is a significant visual change. -Kj cheetham (talk) 10:05, 8 July 2023 (UTC)

Indeed. The recent changes make Wikiprojects and importance ratings extremely prominent on about 2,880,000 pages. I see no discussion above as to whether that prominence is desirable or appropriate on article talk pages, let alone discussion with the wider community, a good number of whom will be utterly mystified as to where this change has come from, why or what to do about it. NebY (talk) 17:29, 8 July 2023 (UTC)

Would a post to a VP or on the centralized discussion template be desirable? 2.9 million pages affected is a large number. Should changes to templates with 1m+ transclusions require alerts to discussions to VPT, VPP or VPM? SWinxy (talk) 00:34, 9 July 2023 (UTC)

Using a template's talk page to suggest changes to that template is the way we generally do things. 2.9 million is certainly a sizeable impact, but it's also talk pages rather than article pages, so I'd say it's considerably less impactful than a change to that number of articles. In retrospect, there should have been more notices sent out, but as TAnthony pointed out above, there was nothing invalid about the process used, and the overall reception has been fairly positive by design change standards. More discussion is always welcome, so feel free to post at the pump (VPT would probably make the most sense) if you'd like, but post-deployment the change itself is probably going to be the main way most editors find out about this. {{u|Sdkb}} ^talk 01:41, 9 July 2023 (UTC)

This is the sort of (unhelpful) response I expected. So, what's the best community process then to get the deployment completely reversed? Because that's what I'm planning on doing, Sdkb. It was inappropriate to do this sort of change without broader community involvement and I plan to see it undone. Silverseren^C 01:51, 9 July 2023 (UTC)

WP:IDONTLIKEIT applies to changes (to templates) as well. Please provide substantive concerns which can perhaps be addressed and then we might attempt to address them. Izno (talk) 02:13, 9 July 2023 (UTC)

How about WP:CONLEVEL, does that apply as well? Do changes pushed through on a template talk page that affects all Wikipedia talk pages in a significant manner deserve any form of respect when the community wasn't involved even at the Village Pump level, which is where the RfC for such a change should have occurred? No substantive problem was even given at the top of this discussion for the change in the first place, it was just assumed that everyone agreed. Local consensus to the extreme. Silverseren^C 02:19, 9 July 2023 (UTC)

Sure, CONLEVEL applies, but there is no pre-existing higher level of consensus here, which is what CONLEVEL is about. It is not a card to use to veto a change that the users involved in a specific discussion think was a good change unless that veto can point to specific pre-existing policy or guideline (or commonly these days, a large RFC) on the matter.

You've got roughly a dozen users above who think the change was a good one. One person came forth and said "this breaks talk pages for me", and the dozen users said "ok, we can fix that [even if we would prefer otherwise]". That's how WP:Consensus works.

Anyway, the discussion above follows from this February 2023 RFC that said that ratings should be a "global" to all WikiProjects question. The primary question following the RFC regardless is "how do we reflect "global" assessments best in WPBS?" That leads to discussion for the past several months, starting from this section in archive 6 (and I trust you can navigate to archive 7). The further discussion eventually led to "we like how this looks". So from that perspective and after review, the CONLEVEL question supports this change, even if you might prefer the aesthetics of another, so you will need to identify specific aesthetic points that you think are insufficiently considered in the discussion(s) above and in the archives to be taken seriously. Izno (talk) 02:37, 9 July 2023 (UTC)

Discussion about new design

I'm uncomfortable with the new colour scheme, and like others here I'm looking for where the consensus was sought for making these changes. I've looked at your links Izno (and navigated to Archive 7), but couldn't see where the consensus was achieved for moving from this File:Article-level assessment example.jpg to the Baskin Robbins / Hello Kitty situation we have now. I see a consensus for merging assessments into the banner, but not for the colour scheme. It's the colour scheme we are concerned about, as it is too distracting and also somewhat inappropriately primary school. SilkTork (talk) 12:01, 9 July 2023 (UTC)

It follows from earlier discussions in the archive, but the discussion and consensus on the design changes are all to be found in this very thread starting at #How project banners should look. You'll probably find there was more discussion about these changes than there was for the original design in 2007 actually! Personally I would be more interested in your constructive comments about further improving the design than side discussions about process. — Martin (MSGJ · talk) 16:07, 9 July 2023 (UTC)

Because to address the process would be to address the fact that the local consensus done on this side template talk page to make changes to all Wikipedia articles was wrong from the beginning? The fact that this has been "the way it's always been done" makes it even worse. Reminds me of issues we've had with Wikiprojects in the past trying to have strict control over articles in their areas and the general community has had to step in and knock them down. The fact that you've gotten so many editors that disagree with these changes both here and at Template talk:WPBannerMeta and seemingly at random places across Wikipedia because basically no one knows where these changes came from shows you that maybe y'all made the wrong decision. Silverseren^C 16:16, 9 July 2023 (UTC)

I have left a notification at WP:VPR asking people to comment here — Martin (MSGJ · talk) 16:18, 9 July 2023 (UTC)

I think it's fine for now, it's definitely not as garish as some people are making it out to be. The only change I'd make is removing the icons, they clash a lot when theres many banners and don't convey much information at such a small size. If there's a consensus against the bubbles, we could always just use normal text without the background colors, like it was before. – MaterialWorks 16:49, 9 July 2023 (UTC)

RfC

Split off the RfC to a new section at #RFC on WikiProject Banner shell redesign section below. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:33, 9 July 2023 (UTC)

Visual glitch when uncollapsing project banners

Uncollapsing project banners shifts the banner shell's text slightly to the right. Tested on Blink, WebKit and Gecko, adblock off. The shift is inconsistent; on Talk:Ronald Reagan, you can see that some WikiProject banners do it, some don't. DFlhb (talk) 14:52, 1 July 2023 (UTC) updated 14:57, 1 July 2023 (UTC)

This is the standard behaviour with collapsed tables, see the table at Special:Permalink/1162864615. If you click "show", the text in the same cell as [show] button will shift to the right, because it is center aligned, and "hide" takes less space than "show" leaving more space for content. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:03, 1 July 2023 (UTC)

Yes, but I'm talking about the shell's text shifting (by 10+ pixels) when I uncollapse WikiProject banners, not when I uncollapse the shell itself (that shift is only 1-2 pixels). DFlhb (talk) 15:09, 1 July 2023 (UTC)

Thanks, I now understand what you're referring to. It's weird how uncollapsing WP California shifts the shell text a lot, WP Chicago shifts it a little, and WP Intl Relations does nothing. Most of them, however, shifts the text by a ot. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:13, 1 July 2023 (UTC)

The ones that shift the text mostly have portal boxes (Milhist doesn't, but it does have that great big FA star on the right); the ones that don't shift mostly don't have portal boxes. WikiProject Chicago does have a portal box however I see no shift with that one. --Redrose64 🌹 (talk) 19:04, 1 July 2023 (UTC)

Is it related to the width of the image on the project banner perhaps? — Martin (MSGJ · talk) 20:11, 2 July 2023 (UTC)

No. {{WikiProject Baseball}} has narrow image but shifts the text; {{WikiProject International relations}} has a wide image but doesn't shift the text. --Redrose64 🌹 (talk) 21:49, 2 July 2023 (UTC)

Now fixed in the sandbox module. DFlhb (talk) 18:59, 3 July 2023 (UTC)

Fix now deployed. DFlhb (talk) 14:22, 4 July 2023 (UTC)

Confirmed, this looks much better, thanks! — Martin (MSGJ · talk) 14:45, 4 July 2023 (UTC)

When should projects opt-out?

Am I misunderstanding why projects would opt-out through |QUALITY_CRITERIA=custom? Custom non-FQS classes defined in a class mask (like Future-class) work without opting out. Standard ratings that differ from article class (e.g. article rating is C-class, project rating is Start-class) also work without opting out.

My understanding is that projects only need to opt-out when they use different criteria for the standard grades. Right? For example, project-specific requirements for a C-class rating. I think only MILHIST and Roads do this.

I'm asking because I don't understand why WP:VG opted-out because they don't support A-class. It requires them to maintain ratings for every single article, when they could achieve the same result by only setting a project rating when the article-class is A-class, without opting-out. Same for WikiProjects Square Enix and Middle-Earth. DFlhb (talk) 16:48, 2 July 2023 (UTC)

I think that unless projects opt out they should be using the standard quality scale, otherwise it will not work correctly. The idea is that all projects (except those which have opted-out) will eventually use a single harmonised quality rating, and any conflicts are tracked via Category:Articles with conflicting quality ratings. But if a project is using Future-class then there will be perpetual conflicts which cannot be resolved. — Martin (MSGJ · talk) 20:06, 2 July 2023 (UTC)

About non-standard content grades

Not sure if this has been brought up before, but is there a reason why this template does not display icons for non-standard grades like redirects and disambigs, or non-mainspace content like drafts? I feel like it would be much more helpful to see relevant icons for each of these, rather than the default NA-class message and icon. —TechnoSquirrel69 (sigh) 05:59, 3 July 2023 (UTC)

Please see Template talk:WikiProject banner shell/Archive 7#NA classes — Martin (MSGJ · talk) 07:31, 3 July 2023 (UTC)

We pinned our hopes on separating quality & type, but didn't take this into account. May be worth revisiting?

FWIW, looks like 1,410 projects/task forces out of 1,987 support Redirect-class. I've extracted the non-intersecting set with Petscan and it looks like many (most?) are TFs. DFlhb (talk) 20:42, 6 July 2023 (UTC)

Came to post a similar question/query. It feels odd to have the banner show an "NA class" (which is defined as A page that does not fit into any other category. Used as a "catch-all" by all WikiProjects.) when projects do categorize them as Redirects, Categories, Drafts, etc. which are applicable categories. If it is possible to separate out these quality without regard to type, it would be much appreciated. - Favre1fan93 (talk) 17:08, 8 July 2023 (UTC)

I raised this point below #Redirect-class invisible when banners inside WPBS. I think this particular issue needs to be thought about and a better solution reached. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:12, 8 July 2023 (UTC)

Minor bug

Moved from User talk:MSGJ

{{WikiProject banner shell|
}}

doesn't behave quite the same as

{{WikiProject banner shell|}}

or

{{WikiProject banner shell}}

It probably needs a {{trim}} somewhere. — Qwerfjkltalk 17:26, 5 July 2023 (UTC)

Fixed in sandbox. Thanks for the report — Martin (MSGJ · talk) 21:28, 5 July 2023 (UTC)

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.— TAnthony^Talk 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)

Icons and text overlapping

Icons that exceed the standard width (like those of Wikipedia:WikiProject Internet culture and Wikipedia:WikiProject YouTube for example) overlap the fixed text to the right, making WikiProject names unreadable in some cases. Perhaps change it so the position of the name of each WikiProject adjusts automatically according to the icon width? I don't know how to do that, so posting here in hopes that someone else does. Throast ^{{{ping}} me!} (talk | contribs) 20:58, 6 July 2023 (UTC)

Fixed, thanks to you and Sdkb for reporting.

Icons are now set to 25px max width (no minimum width), so both very large and very narrow icons look fine. This allows us to keep project name alignment too, because non-alignment with super-wide icons like YouTube's would make the shell look pretty bad. DFlhb (talk) 21:48, 6 July 2023 (UTC)

Do you mean 35px width? — Martin (MSGJ · talk) 10:01, 7 July 2023 (UTC)

Oops, yes. DFlhb (talk) 10:09, 7 July 2023 (UTC)

Rating tool

This might not be the appropriate place to ask, but I wanted to raise the issue of WP:RATER ideally needing to be updated, given the recent changes in the banner shell. I posted a message at User_talk:Evad37/rater.js#Move_article_quality_rating_into_banner_shell, but I don't know how active Evad37 still is. Thanks. -Kj cheetham (talk) 10:11, 7 July 2023 (UTC)

Not just WP:RATER, but a number of other scripts too. I made a list of them at Template talk:WPBannerMeta/to do#Scripts needing update. Since the conversion isn't completed yet, I guess we will ask for an update to the scripts at a later date because a lot of things are being modified, added, removed on a frequent basis. If you come across other scripts that might need updates, feel free to list them there. So that we have a complete list of affected parties. —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:26, 7 July 2023 (UTC)

CX Zoom, thanks for the reply, and good to know it's on the radar. I'll keep an eye out, thanks. -Kj cheetham (talk) 10:38, 7 July 2023 (UTC)

@CX Zoom: AutoWikiBrowser will probably need some updates as well. GoingBatty (talk) 14:45, 8 July 2023 (UTC)

@GoingBatty: If you think the changes hit AWB also, feel free to add it to the list, if you are unsure add it anyway with the suffix "(potential)" which I'm using for scripts that may or may not be affected. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:03, 9 July 2023 (UTC)

@CX Zoom:  Done! GoingBatty (talk) 20:47, 9 July 2023 (UTC)

Factor out 'listas'

Similarly to what was done to factor out param |class= from the individual WikiProjects, I think we should factor out param |listas= in the same way and let the projects inherit the value (if they use it), and for essentially the same reasons. The only thing is, I'm much less familiar with this param, and I'm not sure if the situations of class and listas are completely analogous or not. My understanding is that listas functions as a kind of {{DEFAULTSORT}} operator, and offhand, I can't think of why we'd want to sort something one way for one project, and another way for another one, but I may be missing something. Even if that were the case in some exceptional circumstances, it would still be useful to have the banner version, with the possibility of override in the projects, if they needed to. Mathglot (talk) 00:20, 8 July 2023 (UTC)

Yes, it is only for default sorting.

I see no utility to moving it myself in the sense that I think WP:BIO is the only project that uses listas. Most others don't see a need to spend time on sorting talk pages. Izno (talk) 00:49, 8 July 2023 (UTC)

Personally, I'd oppose moving listas= into the banner shell, because to my knowledge only WP:BIO uses it and thus passing it onto the others could, likely would, disrupt them. SilverTiger12 (talk) 01:23, 8 July 2023 (UTC)

Currently, |listas= uses {{DEFAULTSORT}} magic word. So, when a single project uses it, all categories on the talk page inherit it. For example, at Special:Diff/1164178803, I used |listas=-A for WPBIO, but it gets also inherited by WPUSA, which categories it under the - section. Since, one listas affects the whole page, I'd support moving it to the shell, as this will also help from potential conflicting DEFAULTSORTs. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:55, 8 July 2023 (UTC)

Moving it to the shell sounds sensible to me. Out of interest, what currently happens if multiple projects on the same page use it but with different values? Something like the first or last one sets it for the entire page?

SilverTiger12, are there any specific examples of possible disruption? -Kj cheetham (talk) 10:02, 8 July 2023 (UTC)

Template:DEFAULTSORT#Understanding_DEFAULTSORT says that the last occurring DEFAULTSORT is applied for the whole page. Did it practically, at Special:Diff/1164215717 and its true. I supplied three "listas" in three of the four banners: -A, *B, #C; all four WikiProjects inherited the last occurring "listas", i.e., #C. —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:36, 8 July 2023 (UTC)

Which also means that WPBIO's "listas" comes at the last in the order of precedence, because WPBIO is always the topmost banner on the page. —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:41, 8 July 2023 (UTC)

I don't really have any specific example in mind, just the possibility that if a WikiProject has things categorized without using listas, but then it is mass-implemented, that could disrupt any background processes or categorization. SilverTiger12 (talk) 19:26, 8 July 2023 (UTC)

@SilverTiger12: No categorisation will change. As explained elsewhere in this section, all WikiProject banners (that I have checked) provide the |listas= parameter, and if a talk page has two or more banners, only one of them needs to have the listas set for it to be effective for all of the other WikiProjects on that page. As an example, consider Talk:The Deer Hunter: it has eleven WikiProject banners, but only one of them has |listas=Deer Hunter, The. In virtually every one of the 62 categories listed at the bottom (excluding Category:Former good article nominees, where Module:Article history forces an override sortkey) the page is sorted under D, not under T. --Redrose64 🌹 (talk) 21:21, 8 July 2023 (UTC)

Hi everyone, this is an excellent idea, but you are too late! We already implemented this, as documented at Template talk:WikiProject banner shell/Archive 7#Sort key — Martin (MSGJ · talk) 18:13, 8 July 2023 (UTC)

The parameter is commonly documented as:

• listas – This parameter, which is the equivalent of the DEFAULTSORT sortkey that should be placed on all biographical articles, is a sortkey for the article talk page (e.g. for John Smith, use |listas=Smith, John so that the talk page will show up in the S's and not the J's of the various assessment and administrative categories; similarly, for topics with titles beginning with an article such as "the" or "a" - e.g. for The Example, use |listas=Example, The so that the talk page will show up in the E's). This is important because it is one source used by those who set DEFAULTSORT on the article; consider also setting the DEFAULTSORT for the article when setting this parameter. For more information about this, please see Wikipedia:Categorization of people § Ordering names in a category.
  If the article is using {{WikiProject banner shell}} then it is preferable to add |listas= to that template instead of a project banner template. Putting the parameter on more than one template is not required.

Its behaviour has changed recently: in the pre-Lua version of {{WPBannerMeta}}, using |listas= on two or more WikiProject banners on the same talk page, with at least two different values for that parameter, would throw the error and put the page in hidden Category:Pages with DEFAULTSORT conflicts. It seems that this no longer occurs (see this sandbox), although the override referred to in that error message certainly takes place, even though no error is shown.

I think WP:BIO is the only project that uses listas - the |listas= parameter is recognised by almost all WikiProject banners, and the only exception that I am aware of is milhist I know of no exceptions. I don't see any evidence that WikiProjects other than Biography don't use it (see e.g. Category:B-Class core film articles where several films beginning with the word "The" are not listed under T), but AFAIK {{WikiProject Biography}} is the only one which complains when there is no listas set. Even if Biography were the only one to make proper use of this parameter, I don't see any reason why |listas= should not be added to the banner shell. --Redrose64 🌹 (talk) 11:50, 8 July 2023 (UTC)

It may be moot now given comments above, but plenty of other projects use it (or, to be more accurate, plenty of editors *believe* other projects use it), such as Bridges, Christianity, India, Ireland, Pornography, United States and others (see advanced search). Mathglot (talk) 03:55, 9 July 2023 (UTC)

Probably the better search for a rough order of magnitude, about 70k uses (to your 150k) outside of pages that already have BIO on them. Which is not a very big number given that we're in the realm of 6.6m pages right now (well, subtract the biographies and that'd be about 5m, or about 1.4% of those pages). Izno (talk) 03:58, 9 July 2023 (UTC)

Maybe in addition to factoring out |listas= to the banner, we can also let the banner automatically handle this with titles that start with "A", "An", "The"? No reason to have to do manual work when the module can easily handle this. |listas= should in this situation be a manual override for the automatic work. Gonnym (talk) 16:24, 19 July 2023 (UTC)

Not a bad idea. We could be clever and for people get the family name (P734) and given name (P735) and automatically generate the lastname, firstname format from that — Martin (MSGJ · talk) 17:02, 19 July 2023 (UTC)

+1 Mathglot (talk) 23:30, 23 July 2023 (UTC)

ORES

Related to #Rating tool above, does anyone know how mw:ORES work? It seems to be used quite a lot in management of WikiProjects. Does it get affected by shift in how we do things? —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:05, 9 July 2023 (UTC)

ORES just takes a look at the article and spits out what it thinks a human would've rated the article as. It *shouldn't* be affected, AFAIK. Though, if you want, you can talk to someone in the machine learning team. – MaterialWorks 11:12, 9 July 2023 (UTC)

RFC on WikiProject Banner shell redesign

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. Silverseren^C 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."— TAnthony^Talk 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)

• The new Left-alignment and top bar are not visually helpful either. Beyond My Ken (talk) 19:13, 9 July 2023 (UTC)

  Since you're the second one to bring this up: the top bar was not part of this recent redesign, and is separate from what we're discussing. DFlhb (talk) 19:48, 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. OhanaUnited^{Talk 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. Reywas92^Talk 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. OhanaUnited^{Talk 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)

• Support all. I like it, condensing and cleaning up the template a bit has been overdue for years. I have no opinion on the exact tweaks of colour labels beyond nothing that I'd like there to still be colour labels in some form, rather than purely text. Andrew Gray (talk) 17:17, 13 July 2023 (UTC)
• Oppose all Ouch! It hurts my eyes..... too many colors and messy icons. — Prodraxis {talk • contributions} (she/her) 19:16, 13 July 2023 (UTC)
• Support all. These are great improvements. Many thanks to the editor(s) wo did all the coding to implement those welcome upgrade. --BrownHairedGirl (talk) • (contribs) 21:21, 13 July 2023 (UTC)
• Oppose all too much color, too much clutter. LEPRICAVARK (talk) 22:15, 13 July 2023 (UTC)
• Oppose if it causes editors to hide project names on the talk pages. Today the banner shell at Talk:Galaxy was collapsed to as single line saying only

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://en.wikipedia.org/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)

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)

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)

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)

Problems with vital article lists

Posting this here because I assume people who know what they're doing are more likely to be here (if I'm wrong please tell me where to go). The lists at WP:VA have somewhat broken, with many non-good/featured articles being listed without their class ratings (diff of the bot removing them). I assume that this is because of the banner shell changes causing the bot to not find the information where it thinks it should, but any help/fixing would be appreciated. ~~ AirshipJungleman29 (talk) 10:03, 17 July 2023 (UTC)

I have notified the bot owner at their talkpage: User talk:Kanashimi. Joseph2302 (talk) 10:19, 17 July 2023 (UTC)

Okay this was me, as part of the temporary conversion to WPBM which does not support the old category naming scheme. I've left a message with Kanashimi to ask if they can update the bot's code — Martin (MSGJ · talk) 10:20, 17 July 2023 (UTC)

I’m sorry for the robot malfunction that resulted from renaming the categories. I have fixed the code and it should be updated by tomorrow or the day after. Please kindly remind me what the new name of the categories are if this occurs again in the future. Kanashimi (talk) 11:07, 17 July 2023 (UTC)

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)

Missing project specific class-based categories

Following is a copy of a comment left by Liz in my talk page, with my reply. . Aymatth2 (talk) 16:43, 23 July 2023 (UTC)

Hello, Aymatth2,

I have a question about Wikipedia:Village pump (proposals)/Archive 198#Project-independent quality assessments closure. Not a complaint about the closure but how this change might affect pages that I monitor. Semi-regularly, I look over WikiProjects and sometimes change the status of the project to reflect an increased or decreased level of activity. Over the years, I've discovered that marking a WikiProject as "inactive" can affect or remove the quality assessment categories from articles. Occasionally, when all of the assessment categories for an inactive WikiProject are emptied, they are sometimes deleted.

Recently, I've noticed a new phenomena that I wonder might have something to do with the quality assessment banner change. To be upfront, I'm not well-versed on the article assessment process and even less so on banner templates, my interest in this subject has to do with the categories. But now I'm coming across WikiProjects where the some previously full categories are now emptied but others have been left alone. I think this will be better explained with an example, Wikipedia:WikiProject Insects/ant task force. Right now, all of the categories in Category:Ant task force articles by quality have been emptied but not the categories in Category:Ant task force articles by importance. And there are a large number of uncategorized by partially assessed articles in Category:Ant task force articles. These "by quality" categories were not emptied before now or I would have run into this issue months ago when I was last reviewing WikiProject categories. Over the past few months, I've run into other examples of where the "by quality" categories were emptied but not the "by importance" ones are not.

A slightly similar case can be found with Wikipedia:WikiProject Cricket/Bangladesh cricket task force where the categories in Category:Bangladesh cricket articles by quality have been emptied but many articles in Category:Bangladesh cricket task force articles. If you look at Talk:2013–14 Bangladeshi cricket season, for example, the tag says that it is ranked as a Stub-class but Category:Stub-Class Bangladesh cricket articles is empty.

Could this be a problem localized to Task Forces of WikiProject? Or is this emptying of categories due to changes in the Talk page banners? Sometimes the status changes can take months to affect the emptying of categories but this doesn't seem to be the issue with the Ant task force or Bangladesh cricket task force. What do you think might be causing the emptying out of these categories, especially when other assessment categories haven't been emptied? Thanks for any insight you can provide or a pointer on whom I should talk to about this or where I might go. I'm really a neophyte when it comes to understanding the ramifications of templates. Liz ^{Read! Talk!} 19:51, 22 July 2023 (UTC)

Also the case with all of the "by quality" categories in Category:WikiProject Ethiopia articles but not the "by importance" ones and with Category:Hymenoptera articles, Category:WikiProject Philippine History, Category:WikiProject Monotremes and Marsupials, Category:WikiProject Shaktism articles and Category:Taskforce Jupiter articles and that is probably enough examples for you to check out. Liz ^{Read! Talk!} 19:57, 22 July 2023 (UTC)

• Hello Liz. That looks like a serious issue. I think the problem is that these projects have special logic in their talk page banners, e.g. in Template:WikiProject Insects, which has not been fixed to "inherit" |class= values from the banner shell. But I am guessing. I am going to copy your note to Template talk:WikiProject banner shell, where people with the right expertise can check it. Aymatth2 (talk) 16:43, 23 July 2023 (UTC)

  I do not know what is causing it. In the ants case, most talk pages "show" correct categories but these pages are not listed at the respective category. A null-edit to the talk page fixes it, but this not ideal. For example, Category:Category-Class Ant task force articles shows two members (at the time of writing), now go to talk page of any assessment category of this taskforce, you would find Category:Category-Class Ant task force articles at the bottom, but the actual category page does not show this. A null edit to the cattalk page fixed this. But it is still very weird. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:46, 23 July 2023 (UTC)

Thanks for reporting this Liz. I have fixed the ants one (which is why CX Zoom noticed that null edits work). I think I will add some tracking to find similar errors because it has happened before. Category:Monotremes and marsupials articles by quality and Category:Jupiter articles by quality were other ones with a different value to "yes" in TF_QUALITY, now fixed. Regarding the other ones:

• Category:Ethiopia articles by quality looks fine
• Category:Hymenoptera articles by quality was another affected by the bug on Template:WikiProject insects, now fixed
• Category:Philippine History articles by quality as far as I can tell is working correctly: Template:WikiProject Tambayan Philippines is not set up for task force quality and has not been edited recently
• Category:Shaktism articles by quality was deliberate because a lot of the categories did not exist, so I decided to disable that feature

— Martin (MSGJ · talk) 18:02, 23 July 2023 (UTC)

Thanks for reminding me! I have an outstanding action on Tambayan Philippines. --Redrose64 🌹 (talk) 18:42, 23 July 2023 (UTC)

Tracking now added for the TF_n_QUALITY issue in Category:WikiProject banners with errors under "Q" and I fixed another 7 with the same issue yesterday — Martin (MSGJ · talk) 07:52, 24 July 2023 (UTC)

Tagging this VPT discussion for attention, though it involves importance, not quality. DFlhb (talk) 22:41, 24 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)