Template talk:WikiProject banner shell/Archive 1a

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Functionality

Latest comment: 17 years ago19 comments6 people in discussion

"close to all the functionality found on most of them..."

Nope. Not close, not anywhere near close. In fact, it doesn't support almost any useful functionality, at the moment; it's a raw display table, nothing more.

(It also rolls back years of common-sense template design principles by requiring things like images to be specified on a per-page basis, but that's a minor point in comparison.)

I am quite disturbed that the people pushing this little project seem to be entirely unwilling to respond to any of the concerns that have already been raised about the basic design being advocated here. There has been no explanation provided for how, exactly, a combined template is supposed to retain the rich functionality of the current set. The attitude here seems to be that keeping the templates useful is not as important as making a pretty table; this is frankly insulting to those of us who have spent enormous amounts of time getting the existing templates to work in the sophisticated manner they currently do. Kirill Lokshin 05:02, 5 February 2007 (UTC)

Amen! I haven't been part of the discussion yet, but I can agree with that! -- SatyrTN (talk | contribs) 05:06, 5 February 2007 (UTC)

I think the proposed template looks good, but having used whatlinks here and categories incorporated in talk page templates, I can understand the concerns about losing functionality. Kirill, can you explain exactly what this "rich functionality" is that you are referring to? Does the same argument apply to the FA/GA/FAC etc combined template, or is this specific to the WikiProject templates? Carcharoth 15:44, 5 February 2007 (UTC)

Let's see now... how about, oh, say, this template: how would you suggest converting it into this new model without losing any of the features?

(And, no, this doesn't apply to the FA/GA/etc. templates, since all of those were basically single-feature to begin with. WikiProject templates, on the other hand, generally each support more features than {{ArticleHistory}} does now.) Kirill Lokshin 16:57, 5 February 2007 (UTC)

Tsk, tsk, tsk! That's a WikiProject that needs decentralising. Joke! Joke! :-) I see what you mean about a WikiProject template being complicated, especially when it has all those taskforces. Wikipedia:WikiProject Military history/Automation is just scary! Though it is well-organised, I must admit. I like the 5 criteria for class-B articles, that is something to think about. How many other WikiProjects use the features in the MILHIST template - or putting it another way, which are exclusive features? Do you know of any example of this template using lots of these features? How much room does it take up when all possible parameters are activated? Carcharoth 00:11, 6 February 2007 (UTC)

Let's see:

Regarding other projects: well, off the top of my head, I'm not sure. The thing about such features is that they tend to spread virally, as people notice ones they like and adopt them for their own projects. The basic idea of task force tags are pretty standard among the larger WikiProjects (see, for example, {{WP India}}, {{WPBiography}}, {{WP Australia}}, etc.); the other parameters are more variable. I know WP:GREECE borrowed the 5 criteria & accompanying code recently, for example.
Regarding size: not much more than it does with none of them activated, since they're all contained inside show/hide blocks; the only overhead is two extra lines for the show/hide buttons themselves. I'm pretty sure the most parameter-rich example I've seen in practice is on Talk:World War II, but I haven't exactly been looking for them.

Kirill Lokshin 00:19, 6 February 2007 (UTC)

The two most parameter-rich ones I've seen are {{WPBiography}} and {{Film}}. But, as Kirill said, I haven't gone looking for them. And they don't hold a candle to WPMILHIST.

On another note, is there a way the parameters could just be sent "as is" on to the embedded project's template? I haven't thought this through, and I'm not expert in wikicoding, but can parameters be accessed as a set? In other words, something like enclosing {{WPMILHIST {{{parameter_set()}}} }} inside this template. Just a thought. -- SatyrTN (talk | contribs) 01:41, 6 February 2007 (UTC)

Not per se; there's no way of collecting parameters automatically, and parameter names will overlap between different templates anyways. But an equivalent functionality would be trivial. All you'd be making is an outer shell, of sorts, that would include the actual project templates within itself; this shell could, for example, be a collapsible block. On the talk page, you'd get something like this:

{{WikiProjects

|{{WPMILHIST|class=B|...}}

|{{WPBiography|class=A|...}}

...

}}

I'm not sure that it would be particularly useful, though; it would need to be added to each page individually, and if you're doing that, you might as well use the small-option calls (or even impose the small option globally).

That has nothing to do with what's being attempted here, however; the intent of this effort is to replace project templates rather than just wrapping them up in some fancy formatting. Kirill Lokshin 02:32, 6 February 2007 (UTC)

If you do want to see something like that (basically wrapping templates in a collapsible table), have a look at User:Dr_pda/Sandbox. --Dr pda 02:44, 6 February 2007 (UTC)

Nice ! SandyGeorgia (Talk) 02:48, 6 February 2007 (UTC)

Not bad, but why the multiple templates? Wouldn't it be cleaner to have the sub-templates simply passed in as parameters to a single template? And I don't think the multiple levels of show/hide functionality are useful, particularly given that many project templates include their own show/hide functionality, meaning that pages with this will have three nested levels of it; maybe it would be better to simply have all the templates contained in a single show/hide block? Kirill Lokshin 02:54, 6 February 2007 (UTC)

This was just a quick proof-of-concept. I used multiple templates (succession box style) because when I tried just passing the templates in as parameters, it didn't work :) That isn't to say it can't be done. Yes, one level of show/hide could probably go; being able to see the different projects at a glance is nice so I'd be inclined to remove the show/hide from the top level. Dr pda 03:08, 6 February 2007 (UTC)

Well, here's a proof-of-concept that handles the templates as parameters to the overall one. I've made two versions, one with the separate blocks and one without; I'm still not convinced as to which one is more useful, but if the second type is to be used, we'll probably need some way to standardize the displayed text for each project. Kirill Lokshin 03:13, 6 February 2007 (UTC)

Single box, single box. SandyGeorgia (Talk) 03:20, 6 February 2007 (UTC)

Or multiple, if it can be toggled to one line only. SandyGeorgia (Talk) 03:26, 6 February 2007 (UTC)

It could be, but if it defaults to that, then the secondary blocks become pretty pointless. Kirill Lokshin 03:28, 6 February 2007 (UTC)

Yours is a more elegant way of handling it. I'm not sure why it didn't work when I tried it, probably the interaction of parser functions with wiki table syntax.Dr pda 03:25, 6 February 2007 (UTC)

I like the approach Kirill has taken here, specifically the single show/hide box for all wikiproject templates. I think something similar was tried for all talk page templates when the 'small' template approach was designed and rolled out at Wikipedia:Talk page templates. I've commented back at the ArticleHistory template on which option is preferred. Maybe people can chose between having a small style or an all-inclusive style, or even a small version of the ArticleHistory style templates? Carcharoth 10:47, 6 February 2007 (UTC)

Kirill's single-box solution looks very good. (My only concern is a small aesthetic one - that it should use standard talk colors instead of purple; I've tweaked it as such). Does anyone object to it? Raul654 16:45, 6 February 2007 (UTC)

The Kirill Lokshin PoC

Latest comment: 17 years ago5 comments4 people in discussion

I'm REALLY fond of the Proof-of-Concept Kirill showed above! As a first step, it's GREAT!

I say first step because I'd rather see some parameters that are pertinent to multiple projects be defined more "globally". For instance:

{{Multiproject | class=B | label1=WikiProject Biography | template1={{WPBiography | living=yes}} }}

Where the class parameter gets passed down to WPBiography and any other projects. -- SatyrTN (talk | contribs) 04:55, 6 February 2007 (UTC)

That's a whole different story. The issue with having a common class is that different WikiProjects evaluate articles somewhat differently; the ones with a stricter (or more formal) assessment process won't be happy if their assessments suddenly all get bumped up, and the ones with a looser process will be upset if theirs are pushed down.

(In other words: too much strife, minimal gain, almost certainly not worth the trouble.) Kirill Lokshin 05:13, 6 February 2007 (UTC)

(On a practical level: there's no way to implement it like that, since the overall template can't fiddle with the sub-templates' parameter lists. You'd still need to pass the parameter separately to each template.) Kirill Lokshin 05:15, 6 February 2007 (UTC)

I agree with what Kirill has said, and said something similar here. Carcharoth 10:48, 6 February 2007 (UTC)

I think eventually we'll want a lot more Wikiproject/Task Force organization like that of WikiProject Biography or WikiProject Military history. If we could assemble, say, all the country-specific, transportation or WP:TOL projects into a "task force" style system, templates could be streamlined far more easily (and we wouldn't have inactive projects' banners littering talk- and templatespace)Circeus 19:04, 6 February 2007 (UTC)

Putting this template into use

Latest comment: 17 years ago7 comments4 people in discussion

I've put this template (using hte version copied from Kirill's single-box version) into use at Talk:Jogaila. It looks good, but there appears to be a larger-than-ordinary space above and below the template. Raul654 16:57, 6 February 2007 (UTC)

Fixed it; there was a manual margin setting that you didn't take out when you added the standard classes.

(If we're going to use this widely, it might be worthwhile to come up with a way of reducing the margin setting on the actual project banners inside it; as it is, they're being narrowed twice.) Kirill Lokshin 18:06, 6 February 2007 (UTC)

Since I'm working on tons of talk pages (installing ArticleHistory templates) can someone give me a dummies guide to how to install this while I'm there? I've never been involved with WikiProject templates. SandyGeorgia (Talk) 18:25, 6 February 2007 (UTC)

It's extremely simple. Just copy the existing wikiproject tags (sans small=yes) into this framework. Here is the example in the prototype:

Before:

{{WPMILHIST|class=GA|Medieval-task-force=yes|Polish-task-force=yes}}

{{WikiProject Lithuania|class=GA|importance=Top|comments= [[User:M.K|M.K.]] 14:25, 30 January 2007 (UTC)}}

After:

{{WikiProjectBanners

|1={{WPBiography|class=GA|priority=High}}

|2={{WPMILHIST|class=GA|Medieval-task-force=yes|Polish-task-force=yes}}

|3={{WikiProject Poland|class=GA|importance=Top|}}

|4={{WikiProject Lithuania|class=GA|importance=Top|comments= [[User:M.K|M.K.]] 14:25, 30 January 2007 (UTC)}}

}}

The template takes care of the rest. Raul654 18:29, 6 February 2007 (UTC)

Thanks ! SandyGeorgia (Talk) 18:30, 6 February 2007 (UTC)

Thanks Raul! Speaking for some of the Jogaila editors, we've really been wanting a way to decrease the # of boxes at the top of the talkpage. Though, having read the other comments here at Template Talk, I'd also like to hasten to say that this does not mean we're against having the WikiProject banners. Indeed, anyone who's familiar with my own Wikipedia editing history probably knows that I'm a big fan and supporter of WikiProjects. ;) In the case where an article is only in one WikiProject, a large and complex banner is a definite help. However, in the case of an article like Jogaila, which overlaps through so many different subjects, the banners have really become a clutter, especially because so many of them have duplicate information.

There are a few other articles that I'm involved with, that are also multi-discipline, and I'd love to expand the use of this template. May I proceed, and list the locations here? Or should I hold off until things are more stable? --El on ka 19:31, 6 February 2007 (UTC)

Yes, go ahead - I don't see the core functionality changing much. Raul654 19:41, 6 February 2007 (UTC)

Pashtun people practice

Latest comment: 17 years ago7 comments4 people in discussion

Ah, a sigh of relief. Seven to one - can someone check my work on Talk:Pashtun people before I go crazy? [1] SandyGeorgia (Talk) 18:46, 6 February 2007 (UTC)

Looks good. Raul654 18:48, 6 February 2007 (UTC)

And for the "before" version, see how the page looked prior to double surgery. SandyGeorgia (Talk) 18:49, 6 February 2007 (UTC)

The problem I have is that some categories are useful, and I don't know how we determine which are and which aren't. I check FFA and FAC categories regularly, and find three or four misplaced or incorrect nominations each week, so I can see a use for at least some categories. SandyGeorgia (Talk) 18:54, 6 February 2007 (UTC)

Most of those are needed for WP 1.0 bot to function correctly; they're not really intended for actual editor use. It'd be nice if there were some way of having hidden categories on a page, but no such luck yet. Kirill Lokshin 18:56, 6 February 2007 (UTC)

Who cares if talk pages are littered with categories? :) Oleg Alexandrov (talk) 05:33, 17 February 2007 (UTC)

What to do with selection versions?

Latest comment: 17 years ago26 comments9 people in discussion

I'd like to hear what people think we should do about selected versions 0.5, 0.7, and 1.0? I can see four possibilities:

Incorporate it into ArticleHistory (like Maindate, DYK, 'etc)
Incorporate it into this template
Treat it as any other wikiproject
Create a third (and probably final) meta-template that incorporates selected versions, deletion nominations, and whatever other common occurrences I can't think of at the moment.

Any thoughts? Raul654 19:06, 6 February 2007 (UTC)

Treat it as any other WikiProject, it goes in this template. Please keep it out of ArticleHistory, which is complex enough to install. SandyGeorgia (Talk) 19:12, 6 February 2007 (UTC)

Well, they're not really WikiProject templates, not having an associated WikiProject in any real sense of the term; this template is intended specifically for those, and I don't really think we ought to use it as a catch-all for anything else that happens to be on the talk page. Having said that, all of those can probably be combined into a single "release version" template; it'll just need parameters for which versions to take in. I'll see what I can put together as a PoC. Kirill Lokshin 19:16, 6 February 2007 (UTC)

OK - since I had added V5 to Pashtun, and was told it was OK, I thought it was. I see Circeus has already corrected my mistake, and now Pashtun is back to having a skipto template and a V5 template. No more clean talk page. [2] SandyGeorgia (Talk) 19:21, 6 February 2007 (UTC)

I readded the Skip template because even with the merged banners, the ToC still was not visible in 1020x800. {{talkpageheader}} is certainly the most cluttering template present. Circeus 19:38, 6 February 2007 (UTC)

I stand corrected: {{talkpageheader}} was the most cluttering template XD Circeus 19:39, 6 February 2007 (UTC)

Frankly, I'd prefer to delete template:talkpageheader entirely. It serves no purpose, it should never have been created, and it should never be used. Raul654 19:40, 6 February 2007 (UTC)

Amen - I'll agree to that!!! -- SatyrTN (talk | contribs) 20:06, 6 February 2007 (UTC)

The talkheader template instructions say: "Using the template is suggested for talk pages that are very active or have had policy violation problems. This template should be used only when needed. Do not add this template to every talk page. In particular, it should not be added to otherwise empty talk pages." - unfortunately, it is in use on over 25,000 talk pages (I stopped clicking on 'next 5,000' on the 'what links here' thing after the fifth time). I'd support the deletion of this template as well, but wouldn't a bot be needed to tidy up those 25,000+ pages? Carcharoth 00:44, 7 February 2007 (UTC)

Like Sandy, I too would prefer not to have a separate selected-versions template. Raul654 19:27, 6 February 2007 (UTC)

Well, you're going to have all sorts of miscellaneous templates (e.g. the various "this article was cited in X newspaper" stuff, etc.) up there anyways. Kirill Lokshin 19:47, 6 February 2007 (UTC)

Which would argue for folding the most common ones into a common template. Raul654 22:25, 6 February 2007 (UTC)

Or several common templates. There's no reason why we should jam everything into a three-template model at the expense of having the third template composed of things that have no connection to one another except for the fact that they're all represented by talk page banners. Kirill Lokshin 22:38, 6 February 2007 (UTC)

Why not have a look at Category:Talk header templates and its subcategories, and try and systematically come up with multitemplates for common groups? Incidentially, the article history template only documents history recorded by templates. I'm sure a lot more history could be mined from a page's history and recorded. Page moves is one thing that is sometimes difficult to dig out from a page history. Also, could someone put all these "multitemplate" templates in a category, so they are easy to find again? {{ArticleHistory}}; {{WikiProjectBanners}}; {{oldafdmulti}}; and {{multidel}} are what I've found so far. Carcharoth 00:52, 7 February 2007 (UTC)

The more I think about it, the more I think selected versions appropriate in the ArticleHistory template. It's finite, small, and easily enumerable set of states (none, 0.5, 0.7, and 1.0), which are very much related to the concept of reviewing articles. As such, I think I'm going to see about getting it implemented there. Raul654 03:08, 7 February 2007 (UTC)

Make sure to preserve the message about GFDL images that is in the CD selection One.Circeus 18:46, 7 February 2007 (UTC)

As per Raul654's request, a test implementation of ArticleHistory containing support for v0.5, v0.7 and Releaseversion can be found at User_talk:Dr_pda/Sandbox. The extra text does make the box somewhat bigger, particularly if there's already a Main Page date in there. Also the v0.5 etc templates contain class and category parameters, which have to be included into ArticleHistory to maintain equivalent functionality. The test implementation does not handle the CD selection or things like {{core topic}}. Comments? Dr pda 01:26, 8 February 2007 (UTC)

Just one - drop all the bolding. It's unnecessary, distracting, and tacky. Other than that, it looks great (as usual) Raul654 01:31, 8 February 2007 (UTC)

Some articles may be in more than one CD selection. Also note {{WPCD}}. Another approach is to create a second toggle box (inside ArticleHistory) containing "misc" templates, that could be passed in as parameters without change. This would allow the same article to be tagged with 0.5, WPCD, and CoreTopic without incorporating code for multiple options here. (V0.7 seems mostly un-used.) You might have parameters misc1={{core topic|class=FA}} misc2={{v0.5|class=FA|category=Natsci}} This would also allow any combination of CD selections. Gimmetrow 02:03, 8 February 2007 (UTC)

Do you have an example of an article that's tagged with more than one selection template? As far as I know, the selection sets are incremental; everything in 0.5 is automatically in 0.7, and so forth. Kirill Lokshin 02:06, 8 February 2007 (UTC)

Moving it into the show/hide area sounds like a pretty good idea, actually. Although I do agree with Kirill that versions are supposed to be exclusive (although I think he got it backwards - things in 0.7 should be in 0.5, not vice versa). We could also incorporate a WPCD=yes option at the same time. Raul654 02:13, 8 February 2007 (UTC)

Well, basically, 0.7 = 0.5 + (added articles). :-) Kirill Lokshin 02:17, 8 February 2007 (UTC)

Talk:Sun has core topic and V0.5. Many of V0.5 or V0.7 have WPCD, eg Talk:Fish, Talk:Baseball, Talk:Cheese. Why did they all use different CD images? Gimmetrow 02:23, 8 February 2007 (UTC)

They're unrelated. Core topics is different from release versions (0.5, 0.7, 1.0), which is different from the external WPCD project. Kirill Lokshin 02:27, 8 February 2007 (UTC)

Well, that's fine then. If the CD selections are like wikiprojects, just put them in the meta project banner bin. By this I mean, why not just put all these CD-related templates (V0.5, core topics, WPCD, etc.) in the big banner here, if people want to? Gimmetrow 03:33, 8 February 2007 (UTC)

(unindent) I've only just seen this discussion. I think it's a great suggestion, and it matters a lot as we plan to get a bot picking articles soon - so the no. of articles will shoot up. I think I like the ArticleHistory solution is best, though I think we could be flexible. A couple of points

Just to clarify - "Release Version" is a rolling term, referring to the most recent version we are working on, whereas specific numbers are supposed to be applied at publication. That means we can have permanent links to WP:WPRV, and have a permanent set of associated pages. Version 0.7 is the latest one we have started on, and Kirill is right, V0.7 = V0.5 + (added articles). We don't plan to give lists of versions that include the article - just essentially say "Version 1.3 onwards".
I was planning on writing a combined Core Topics/Release Version template, in order to reduce clutter, since all decent Core Topics are automatically included in all Release Versions. We can simply add "core" as a parameter into the Release Version template, similar to what is done at {{Chemicals}} (see Talk:Sulfuric acid for an example). The only thing holding up the Core Topics combo is that there are a handful of core topics that are omitted as embarrassingly bad! Hopefully we can fix that fairly soon.
The 2007 version of the WPCD selection is likely to be the last one, as User:BozMo is suggesting we merge future work with an appropriate release version such as V0.7. I think that makes sense, now we have things like bot systems and offline readers. The WPCD template automatically grabs anything in Version 0.5 already.
We hope in the future (next year?) to start releasing WikiProject-based specialised releases such as "Chemical reagents" or "The KLF". Although we don't need to deal with that right now, it might be good to consider this at least when weighing pros and cons. These releases could go into ArticleHistory, though these may belong better inside the WikiProject template, if the project designed the release.

In summary, it seems to me that all of these different general releases (0.5, 0.7, Release Version, WPCD) will end up in a few months in one single template, with core added for Core Topics. This should then be combined further into a more general template as suggested here. The specialised release idea might swing things a little towards the metaProject box option, though I think I'd prefer the ArticleHistory option overall. Walkerma 07:17, 8 February 2007 (UTC)

Showing project names in this template

Latest comment: 17 years ago8 comments5 people in discussion

What are the pros and cons for showing the project names like on the second option here? Personally, I like being able to see at least the names of the projects. -- SatyrTN (talk | contribs) 19:10, 6 February 2007 (UTC)

Heh, I was just about to suggest the same thing, and Kirill's multi-template is exactly what I was going to propose. Though, if it's at all possible, it might be nice to also have the graphic of each WikiProject next to the name. Or is there even functionality to do that? --El on ka 19:36, 6 February 2007 (UTC)

It could be done, in theory; you could have, say, {{WikiProjectHeaders}} as a switch statement listing various projects, and call things like this:

{{WikiProjectBanners
|1={{WikiProjectHeaders|WPBiography}}
|2={{WPBiography}}
|3={{WikiProjectHeaders|WPMILHIST}}
|4={{WPMILHIST}}
...
}}

The issues I see are twofold:

I'm not sure if this is doable for an arbitrary number of WikiProjects given the template transclusion limit.
The call would be quite fragile; misspelling the project name, for example, would cause it to not display the proper header.

Kirill Lokshin 19:45, 6 February 2007 (UTC)

Is there a way to use images to show the projects concerned based on the banner name? My programming is a long way back and limited to ZX Spectrum basic, but it feels like there should be a way of saying if WPMILHIST appears in 1-10 then display Image:Waricon.svg at 20px. Does that make sense? Hiding Talk 12:02, 7 February 2007 (UTC)

Nope; the functionality available through parserFunctions isn't enough do do arbitrary string recognition. Kirill Lokshin 13:17, 7 February 2007 (UTC)

That's a shame. If only I knew what parser functioning was. :) I'm now impressed at the capability of the old ZX Spectrum. Hiding Talk 18:27, 7 February 2007 (UTC)

m:parserFunctions ;-) Kirill Lokshin 18:28, 7 February 2007 (UTC)

I don't like it. People can always choose to click show on the current version. Quadzilla99 22:01, 19 February 2007 (UTC)

Questions

Latest comment: 17 years ago3 comments3 people in discussion

Two things: 1. What is the maximum amount of boxes this takes? 2. Should we be putting this out or is someone going to make a bot to do all this? The Placebo Effect 22:20, 6 February 2007 (UTC)

1. At the moment, ten; but this is trivial to change.

2. Any mass-conversion is probably (a) not bot-doable unless we have a bot that can recognize WikiProject banners and (b) premature until the remaining design issues get settled. Kirill Lokshin 22:23, 6 February 2007 (UTC)

To answer the second question - Both. Sandy has already asked] Gimmetrow if Gimmebot could do this, and I'll be notifying the signpost soon. Raul654 22:24, 6 February 2007 (UTC)

I don't like it

Latest comment: 17 years ago27 comments14 people in discussion

Sorry, I just gotta say I think this is the wrong way to go about cleaning up banners. Ideas like this have been considered and shot down before, and I doubt WikiProjects will be very happy with it. You're much more likely to get people to agree to use their banners less, have size / text limits on banners, and using the small option. -- Ned Scott 23:57, 6 February 2007 (UTC)

It's not ideal right now, but when it's applied, it's usually to great usefulness. Look at the already mentioned Talk:Pashtun. There's no obligation to use it either.Circeus 00:12, 7 February 2007 (UTC)

I'm kinda on the fence. Hiding Talk 11:57, 7 February 2007 (UTC)

I have to agree with the original comment, this is a bad idea. I'm a member of Wikipedia:WikiProject Alternative music, so every single article that is under our scope will have to have this banner (whether its because of WP:BIO, WP:ALBUM, or WP:SONG). It obscures some WikiProjects while promoting others. Teemu08 17:43, 7 February 2007 (UTC)

How does it do that? All banners will be put into this template if it's used on a talk page, so they're all treated equally. --Conti|✉ 17:50, 7 February 2007 (UTC)

Where have ideas like this been considered and shot down before? I'd love to read some of the criticism to see if it can be addressed. -- SatyrTN (talk | contribs) 18:50, 7 February 2007 (UTC)

Like I said before, I think limiting banner size (both picture and graphic) would be a much better idea than this kind of "push under a rug" approach. Also there are many projects which use banners that don't really need to use banners. One that I'm actually responsible for is {{WikiProject LOE}}, which isn't needed and can go away. That or situations where there are parent and child WikiProjects both using banners, when usually just the child needs a banner (such as the TV WikiProject Banner + a show specific banner, one really only needs the show specific one since that project should already be linking back to the parent). If they need the banner for article assessment, well that can be done with a template that doesn't actually show a visual banner. Basically this defeats the entire point of having a WikiProject banner, to advertise and get people's attention. The problem is many projects are trying to do too much within their banner. A while ago I re-worked {{WikiProject DIGI}} to take up a whole lot less room by moving most of the content to the "show/hide" area (not just the to do list).

In other words, we should actually fix the issue rather than just trying to hide it under a sub page/template/etc. -- Ned Scott 19:21, 7 February 2007 (UTC)

Ned makes some good points here, especially about making the parent WikiProjects invisible, relying on people to find them by following the trail back from the daughter WikiProject. I think the main point though, about keeping the different WikiProjects visible, but still reducing clutter, is to have the image and name visible at the top, but nothing else. See the second option shown here (that was archived too quickly, really - let's keep the options visible for people to see who come to the discussion now and later). Carcharoth 02:44, 8 February 2007 (UTC)

If I understand what you've said, Ned, one issue is project banners that don't need to exist or that are unwieldy - either because the project is inactive, or because the banners are used when a cat or some other device might be better suited for the purpose, or because the project is jamming too much into their banner. As I see it, those issues should be addressed on a per-project basis. (side note - is there a WikiProject for Deletion process?)

But the other issue, one that this template attempts to address, is having to scroll down through 4, 5, 6 or more different project banners, whatever their size, all of which might be relevant and pertain to the article, before getting to the actual discussions. I don't see the two issues canceling each other out - in fact, they both aim to clean up talk pages. -- SatyrTN (talk | contribs) 04:12, 8 February 2007 (UTC)

They are both ways to clean up talk pages, one hides WikiProject banners and one doesn't. We can use the small option if people don't want to scroll down, and we can further limit banner text and image size even after being small (because small isn't always.. small). Here's an example of a banner that isn't really needed "all the time" (probably something for Template:ArticleHistory): Template:WP:LoCE. Also, I keep seeing stuff like WikiProject Cats or something on the article of a fictional cat.. now that's just silly, because WikiProjects aren't about categorization by topic alone. I'd much rather clean up the mess than push it under a rug.

I think the only real guidelines on project banners we have are Wikipedia:WikiProject Council/Guide#Advanced project banners and Wikipedia:Talk page templates, and there's many experienced users who don't know those pages exist, nor are they really.. hard hitting. Take Kirill's example, why not just make all WikiProject banners be one line with a show/hide button individually? I know it sounds like a lot of work to get people to change, but heck, spin it the right way and it almost becomes a fad, with editors jumping to update with new cool banner style.

This just seems like a really sloppy solution to something that we haven't really tried to fix yet. I'm betting the clean up is a lot easier than we think. At least it's better than pushing it under a rug. -- Ned Scott 05:38, 8 February 2007 (UTC)

You mean something like this? Kirill Lokshin 05:56, 8 February 2007 (UTC)

Yeah, and maybe even a small "text high" graphic and a message (X number of words/letters or less) incase the name of the project wasn't completely clear, etc. Something that would most often only take up one line and then have a show/hide box. -- Ned Scott 06:03, 8 February 2007 (UTC)

I like that too, much better, although like Ned a graphic would be good. I also prefer that purple one that's in your sandbox over this as well. I only just got around to making the Comics banner small compliant, now I have a new trick to learn. I have to agree with Ned about the scope of some of the WikiProjects. The cats one is something I noticed too. Hiding Talk 08:41, 8 February 2007 (UTC)

In technical terms, this model has an advantage over the purple one because the entire rendering is controlled by the template itself, rather than being dependent on outside help; I still haven't come up with a good way of setting up the meta-template version such that it doesn't require all of the project names to be entered by hand.

(It's not that hard to implement, incidentally; on a basic level, it's two extra CSS classes and a new top row in the table. ;-) Kirill Lokshin 13:17, 8 February 2007 (UTC)

I can agree with some of the concerns mentioned here - many projects rely on these templates to recruit new people. However, some pages have got silly. I really like Kirill's last solution and similar efforts - I think listing out each WikiProject on the "outside", with a direct link to the project, is a fair compromise. I think we should let the pages go the way editors think is right (being Wikipedia, that has to be the way anyway!). Many simpler pages will have full templates, and more cluttered ones will have a choice of this or the small option. If any project violently objects, they can switch styles and (if needed) debate the issue on the talk page. Hopefully, 99.99% of such things will happen without any problem. Could we "pilot" the scheme on something like WP:MILHIST, and see if people get upset? Walkerma 16:54, 8 February 2007 (UTC)

Well, I've implemented it on {{WPMILHIST}}; it's enabled by calling the template with hide=yes. Kirill Lokshin 23:27, 10 February 2007 (UTC)

I really like Kirill's solution, too. The names of the WikiProjects can be easily seen, while the talk page stays neat and tidy. --Conti|✉ 17:20, 8 February 2007 (UTC)

Is there a way to code this as a template option similar to how small works, perhaps as a hide variable? So you start with {{WPMILHIST}} and if you add hide=yes then you get User:Kirill Lokshin/Sandbox/Template4. Or is that asking too much? Hiding Talk 19:55, 8 February 2007 (UTC)
- Yes, there is. :-) Kirill Lokshin 21:04, 8 February 2007 (UTC)

However, that means getting each of the wikiprojects to adopt the new framework. -- SatyrTN (talk | contribs) 22:04, 8 February 2007 (UTC)

Well, on some fundamental level, you simply can't have your cake and eat it too. ;-) Kirill Lokshin 22:25, 8 February 2007 (UTC)

It's all about how we spin the idea. I know that sounds slightly car-dealerish, but hey, presentation is everything in a virtual community. If it sounds like a chore, then it will be a chore. If it sounds like a rule, then it will be a rule. If it sounds like a great idea (which it is) then we'll have editors jumping to do this themselves. -- Ned Scott 05:44, 9 February 2007 (UTC)

Can't it be default show, with the option to hide? Alexj2002 09:56, 19 February 2007 (UTC)

When designing an interface, you cater to the majority. The vast majority of talk page visistors do not benefit from wikiproject templates. They do, however, benefit from uncluttered talk pages. Therefore, the default is to hide. Raul654 16:23, 19 February 2007 (UTC)

I will have slow, limited dialup access for the next two weeks, so I just want to add my name to the consensus of the arguments put forward by Raul. SandyGeorgia (Talk) 16:26, 19 February 2007 (UTC)

I agree whole-heartedly with Raul on this matter. I support wikiprojects and am actively involved in several of them, however talk pages are not meant as billboards for advertising WikiProjects. Quadzilla99 22:08, 19 February 2007 (UTC)

Could it possible for a page with multiple banners to have designate one banner as a Main project that would have its banner displayed fully (with the hide in place still) while others would be minimized? On an article where it quite clearly in the camp of one project while others are more periphery, it would be a nice compromise. —The preceding unsigned comment was added by SauliH (talk • contribs) 15:31, 7 March 2007 (UTC).

Small

Latest comment: 17 years ago31 comments9 people in discussion

How does this work with small=yes? I tried it out at Krazy Kat, and it seemed like if there was a way the banners could, if they were all made to work with small, stack up inside the template a lot easier if the right float aspect could be tweaked, maybe through a css class? Seems to me maybe this could be a step forward for the banners, mandating them to be built as small. Okay, it's a dream, but I'm curious. Hiding Talk 18:30, 7 February 2007 (UTC)

Yes I would appreciate it if this template could be modified to allow "small=yes". Then it could be employed on pages such as Talk:Supernova. Thank you. — RJH (talk) 18:46, 11 February 2007 (UTC)

I am not sure that this is a better idea than small=yes for gaining control of unruly talk page headers, but if people do like this, is there a way to get it to itself work with small? I also think having a collapsible small thing would be cool for its own sake. :) ++Lar: t/c 17:31, 13 February 2007 (UTC)

What exactly do you mean by "work with small"? If you mean including small banners inside, it already does that. If you mean collapsing to small size in its own right, that would be possible, but only when all the banners inside were also using the option. Or do you mean something more complicated? Kirill Lokshin 17:35, 13 February 2007 (UTC)

I did. I had the idea that the banner could accommodate two small project banners per row, if the technical aspects could be arranged. But on reflection, that was probably naive wishfulness. Hiding Talk 20:05, 13 February 2007 (UTC)

Not really doable (neatly) unless you turn off the float:right in the small-talk CSS class (which will break all the pages that use it at the moment), or force all the banners to support explicit alignment. Kirill Lokshin 20:11, 13 February 2007 (UTC)

Yeah, I thought the float:right would kind of kill it. It's way too much hassle to recode all banners just for this. Hiding Talk 10:30, 14 February 2007 (UTC)

I'm not all that conversant in CSS... Would the float right float the small box to the right of a table cell? Or an enclosing div? -- SatyrTN (talk | contribs) 21:48, 13 February 2007 (UTC)

You could table it, I guess, but then that's dependent on all banners being small compliant to allow the tabling to work. Hiding Talk 10:32, 14 February 2007 (UTC)

Maybe I'm crazy and this can't be done, I'm not that good with css... but I was thinking that if you told this box to be small=yes that it would make all the containing banners be small=yes (as if they had that parameter) as well and it would be the same width as a small banner, and positioned where small banners go, just as if it were one. I'm not suggesting that it hold a bunch of small banners arranged horizontally... does that help clarify? ++Lar: t/c 23:37, 13 February 2007 (UTC)

The contained banners would need to be called with the small=yes option to generate small banners. While that can be done, it takes a bit of extra code to make it happen automatically. (One way to do it is discussed below.) Gimmetrow 02:37, 14 February 2007 (UTC)

Yeah, each template needs to have its own small and large versions to allow the template call small=yes to work. What it basically does it acts as a filter: you code two versions of the template and make one of them dependent on the call of an "if" function with the keyword "small" acting as the target for "if". So every template needs to have been written to use the "small" call. I'm nopt sure you could code the template to insert the small call into each inserted banner, either. Well, I mean, techinicaly I think you might, but the method of doing it would be more complicated than the editor adding it to all banner templates when they add this wraparound template. Hope that all that makes sense, my programming is over half my lifetime away. Hiding Talk 10:30, 14 February 2007 (UTC)

Yes. this only works if small is already supported in the embedded templates. Note that I have been informally (and on a spot check basis) converting templates that don't already support small whenever I find them. I'd been thinking about doing some toolserver automation (my first project there so likely to be slow to get done) to find ones that need it (because they are used on a long talk page and don't yet support small=yes) but am not sure if that's needful, I get the sense that swift progress is being made on converting them all already... Kyrill, is that true in your judgement? ++Lar: t/c 16:49, 15 February 2007 (UTC)

This thing basically makes the small function null and that is the reason why I personally love it. Not sure why small option is even being discussed as in my humble opinion this little template outmodes it. Quadzilla99 20:05, 19 February 2007 (UTC)

I concur with Quadzilla -- the small option was an attempt to clean up talk page clutter. It was ill concieved and failed. This template makes the small option obsolete, and its use should now be considered deprecated. Raul654 20:24, 19 February 2007 (UTC)

Eh? I think I missed some stuff! Why is small ill conceived? Why did it fail? I was not aware it failed... Where do I need to do more reading on this? Small seems a very elegant solution for the template clutter problem. This... seems more a hack, as it takes up a lot of vertical space no matter what you do. Small takes up no vertical space at all. ++Lar: t/c 20:43, 19 February 2007 (UTC)

It's incongruous, cluttered looking, and if you have a high resolution computer screen (like me and mine's only 1680 x 1050) the boxes become too small. Quadzilla99 20:53, 19 February 2007 (UTC)

To which I'll add - the reason it was ill concieved is that it was an attempt to reduce talk page clutter concieved and exexcuted by the very people with a vested interest in keeping those talk pages cluttered. The result was something that was a true hack (in the computer programming sense), it was an aesethetic nightmare, and it didn't really make pages uncluttered. Having the wikiproject people come up with an anti-clutter solution is sort of like having the NRA write gun control legislation - it's an insurmountable conflict of interest, and the results are not pretty. Raul654 21:00, 19 February 2007 (UTC)

I agree whole heartedly. I'm an avid member of the NBA wikiproject and a semi-active member of the NFL wikiproject so I'm not anti-wikiproject, but talk pages are not meant as billboards for advertising wikiprojects. Quadzilla99 21:39, 19 February 2007 (UTC)

That's rather a POV characterisation of what project banners do. ++Lar: t/c 17:09, 20 February 2007 (UTC)

I'm not sure what's POV about it. Rather just hazard a guess could you just explain what is POV about it. Keep in mind that if you visit the NBA wikiproject you'll see I am very active there and have invited 10+ people to the project. Quadzilla99 21:17, 20 February 2007 (UTC)

No slight of YOU was intended, just that I think "billboards for advertising" shows a certain POV about what those banners are for. My POV is that they're not advertisments at all, but rather that they convey important information. ++Lar: t/c 22:36, 20 February 2007 (UTC)

As I have already cited elsewhere on this page, the Wikiproject council is quite clear that the primary (if not only) use of the wikiproject template is indeed for advertising purposes. Raul654 22:50, 20 February 2007 (UTC)

Interesting that you read that discussion in that way, Raul654. I read the first part that the tags are advertisements, which then changes to talk about the content of the tags - specifically the article rating. So perhaps the tags do convey more than just advertisement... -- SatyrTN (talk | contribs) 23:00, 20 February 2007 (UTC)

So your view, in rose-colored glasses, is probably something like, "they convey very important information to the reader about a group or project that is dedicated to improving the type of articles in question." How is that not advertising? because it's something good? Advertising isn't defined by value judgements, an ad by coca-cola and the public ad campaigns in the 1980's for AIDS awareness are still both called advertising. What you're saying is that these are good things and therefore should be given billboard like status on every talk page. Which, of course is an entirely different argument. Your argument should be something like, "Yeah it's advertising but the product/idea is so good that the advertising space is well deserved and merited." Quadzilla99 23:16, 20 February 2007 (UTC)

So would it be more accurate to say that "failed" really is just the opinion of a few folk who don't like talk page project banners, rather than a broad consensus already arrived at and documented somewhere else that I missed seeing? Please let me know if small was discussed in depth somewhere else and rejected, but failing that, I plan to continue to keep applying it when I see the need for it on a a talk page. I do not think there is yet consensus that this solution is better. Some opinion, yes, but not consensus. I certainly don't think it is. ++Lar: t/c 14:29, 20 February 2007 (UTC)

Small doesn't reduce talk page clutter; it just puts it on the side rather than the top, and makes it harder to read. SandyGeorgia (Talk) 14:31, 20 February 2007 (UTC)

I disagree that it doesn't reduce clutter. Conversely, I feel this option takes important information that ought to be visible on a talk page, and hides it. Plus, IIRC, load time was a concern of yours. This option doesn't help load times at all, everything is still loaded full size even if hidden, while small (by using smaller images) does in fact help load time. But more importantly, your comment fails to address my point, that some folk here act like there's consensus that small is failed. If that's so, please point me to where that consensus was determined. I'm not yet seeing it, and I'll continue to convert stuff to small when it makes sense to do so, I guess. ++Lar: t/c 17:09, 20 February 2007 (UTC)

Small option doesn't reduce clutter, it just moves it to the right, and makes it look more incongruous. Must be nice to have a low resolution computer screen also Lar. I have a 1680 x 1050 screen which is nothing compared to the ultra high resolution screens that are out now and 20-20 vision (with contacts). The small option boxes are very hard for me to read from the distances I normally like to sit from my computer screen. Quadzilla99 21:31, 20 February 2007 (UTC)

Not following you there. I happen to run 1600x1200 and wear bifocals and don't see the merit in your argument about sizes, and as for clutter, I think things that take up the whole width of the page are more cluttered than things that don't. To each his own, really... Further, I think you assume a bit too much about me. But again, you miss the real point of my comments. Where is the consensus that small has failed which has been asserted above? I looked and didn't find it. ++Lar: t/c 22:36, 20 February 2007 (UTC)

I'm sure I could consult an optomologist to prove this but from where I sit from the computer (about 30 or so inches I just measured) they're unreadable without squinting to a person with 20/20 vision on a 1680x1050 15 inch screen. Quadzilla99 23:22, 20 February 2007 (UTC)