Template talk:Infobox musical artist

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Template:Infobox musical artist page.
Please sign and date your posts using four tildes (~~~~). New discussion topics go at the bottom of the page; click here to start a new topic. New to Wikipedia? Welcome! Frequently asked questions.	Talk page guidelines Be polite Assume good faith No personal attacks Don't bite the newcomers!

	This template is within the scope of WikiProject Biography. For more information, visit the project page.	Biography Portal
Template	This article has been rated as Template-Class on the Project's quality scale. [FAQ]
	This article is supported by WikiProject Musicians, an attempt to build a comprehensive and detailed biographical guide to musicians and musical groups on Wikipedia.

This template was considered for deletion on 2006 June 22. The result of the discussion was speedy keep.

Contents 1 Name field problem 2 Field Names 3 Documentation transclusion 4 Individual band members? 5 Centering Subsection Headers 6 Colors 7 Colour selection 7.1 Proposed colour selections 7.1.1 Proposal 1 7.1.2 Proposal 2 7.1.3 Proposal 3 7.1.4 Proposal 4 7.1.5 Proposal 5 7.1.6 Proposal 6 7.1.7 Proposal 7 7.1.8 Proposal 8 7.2 Voting 7.2.1 Proposal 1 7.2.2 Proposal 2 7.2.3 Proposal 3 7.2.4 Proposal 4 7.2.5 Proposal 5 7.2.6 Proposal 6 7.2.7 Proposal 7 7.2.8 Proposal 8 8 Proposal 6 Implemented 9 Request:The Template's code (for Arabic Wikipedia) 10 Color - Hex vs. Name 11 Archive 12 New field: distinguishing genres and styles

[edit] Name field problem

Did someone update the part of the infobox with the name? It looks fine for most artists, but for some (say, with Japanese names, like Ayumi Hamasaki for example) it's cutting the field off. Would someone mind looking into it? --Shiori 18:26, 9 November 2006 (UTC)

Can you be more specific? I don't see any cutting off. The contents of the name field seem to render exactly the same for me whether it's inside or outside the name field. That is to say, I see "Ayumi Hamasaki (浜崎 あゆみ, Ayumi Hamasaki^?)" displayed just fine, and it looks the same here as it does in the infobox. I don't know if that's how it's supposed to be rendered, since my Japanese is very limited, but if there's a problem, it doesn't seem to be related to the infobox. (And in answer to your first question, no, the name field has not been updated or changed in, well, ever.) -- Xtifr _tälk 23:46, 9 November 2006 (UTC)

Sounds like a system-specific problem. You could take a screenshot, upload the image to one of the free hosts (such as imageshack.us) and then link it here. Prolog 23:52, 9 November 2006 (UTC)

The problem seems to only be happening in IE. Screenshot (Cropped to make it easier to see). It's fine in Firefox. -- Shiori 22:39, 9 November 2006 (UTC)

I tried with IE (6.0) now and the same thing happened, so it's definitely an IE-related bug and not just on your system. Prolog 16:02, 10 November 2006 (UTC)

I think I've tracked down the cause. IE doesn't seem to like Template:Nihongo, which adds the small question mark and wikilink to Help:Japanese after the Japanese spelling (as shown on Xtifr's post above). Prolog 16:26, 10 November 2006 (UTC)

Ah, that makes sense. Thanks for solving the puzzle, Prolog. I didn't think this infobox could possibly be doing anything complicated enough to confuse even IE—and sure enough, it's not. Has someone reported the problem on at Template talk:Nihongo? Xtifr _tälk 05:20, 11 November 2006 (UTC)

I don't know how to fix it, so I left a note at Template talk:Nihongo. Prolog 18:09, 12 November 2006 (UTC)

Reply to question from Template talk:Nihongo

It is caused by the fact that an HTML sup tag is used to create a superscript ?-mark. It is a peculiarity of the default IE stylesheet that this causes the line-height to be slightly larger. Since the designer of the infobox didn't account for that and tightened the line-spacing, text is cut off.

I would like to take this opportunity to ask you not to try to solve this problem, but to instead refrain from using the kanji spelling in the infobox. You see, the name in roman letters + the name in kanji is, for most artists, too long to fit in the caption. That, and I don't think that such information is needed more than once in an article. We would already have the kanji, and possibly Hepburn, in the lead, so why duplicate in the infobox title? Shinobu 05:59, 16 November 2006 (UTC)

I think that is a good point about not using Template:Nihongo in the infobox, especially when the template is already in use in the first sentence of the introduction. – Heaven's Wrath   ^Talk  00:21, 17 November 2006 (UTC)

Fully agree. I'll see if I can think of some appropriate brief comment to add to the docs to cover not just this, but other potentially problematic templates in the name field as well. Xtifr _tälk 00:53, 17 November 2006 (UTC)

I must agree as well. There's already an overuse of kanji (along with excessive capitalization of English) in quite a few Japanese music-related articles, despite the last paragraph in WP:MOS-JP. Using the nihongo template within the infobox would just encourage this sort of overkill. Cyrus XIII 00:15, 1 December 2006 (UTC)

[edit] Field Names

It's too bad the fields in the solo and Band templates are not consistent with the field names here. Makes more work for a switch.

Is there a tool that would automate switching solo and Band templates to this one? *Spark* 03:35, 16 November 2006 (UTC)

You might want to talk to Kingbotk about that. He developed some plugins for AWB, available here. I have been replacing them by hand, so I would be interested if he could make one. – Heaven's Wrath   ^Talk  00:14, 17 November 2006 (UTC)

I have an idea for making it easier, but don't have the time to try it juuuuust yet. When I do I'll report back here on it. *Spark* 01:25, 17 November 2006 (UTC)

Well, I ran a test and am awaiting some answers regarding template substitution. If you look at User:Sparkhead/TemplateTest and User:Sparkhead/BandTest (which was a copy of the infobox code on the Marillion page) when I edited it, I replaced {{Infobox_band with {{subst:User:Sparkhead/TemplateTest and nothing else, saved. It ran the subst, and it almost worked. There are some other issues. I'm no expert with template syntax, nor with AWB plugins. If someone else a little more knowledgeable about template subst wants to mess with it, feel free to do it right in my user space. *Spark* 14:23, 17 November 2006 (UTC)

• I wrote a little utility that will convert templates. I'm using the "View Source With" plugin for Firefox to launch it. Which means I have to go to the page, hit edit, hotkey the "view source with" for my util, hit "show changes" to make certain all works correct, then hit save. Anyone know of a faster way to edit the wiki on a large number of pages? If I could go to the "what links here" page for the band template, and simply launch tabs for 20 links at a time, I could convert them all in a short time. I'm not familiar with AWB but will check it out to see if it can launch my utility. *Spark* 20:51, 17 November 2006 (UTC)

[edit] Documentation transclusion

Browsed Wikipedia:Template doc page pattern and it seems like an excellent idea, so I've implemented it on this template. I don't see any ill effects and it should reduce impact of doc changes. Apologized if I've missed anything, but looks like pages using it are still evaluating it properly. *Spark* 23:10, 16 November 2006 (UTC)

Sounds fine. Would help if we need to protect the template in the future. – Heaven's Wrath   ^Talk  00:17, 17 November 2006 (UTC)

Indeed, I've seen this done on other templates, and had been thinking it might be a good idea, but hadn't gotten around to doing anything about it. We might even want to go a little further, and split it up a bit so that important pieces can be transcluded elsewhere (e.g. the docs on the background field, which a lot of people find tricky), but this is an excellent start. Kudos! Xtifr _tälk 00:47, 17 November 2006 (UTC)

Thanks. Glad it worked smoothly. This is not a template I make a major edit to without more than a bit of hesitation. *Spark* 01:29, 17 November 2006 (UTC)

I redirected the talk page back here, as I think it makes more sense to have all the discussions in one place. I did add it to my watchlist, but I don't think that everyone who wants to keep track of discussions should have to do so. Xtifr _tälk 01:45, 17 November 2006 (UTC)

[edit] Individual band members?

What is the appropriate type for an individual band member? It appears that group_or_band would be for articles on the band, not its members. Joltman 13:56, 17 November 2006 (UTC)

It depends on what they do within the band. If they sing and play an instrument, use solo_singer and if they only play an instrument, but do not sing, use non_vocal_instrumentalist. – Heaven's Wrath   ^Talk  01:50, 18 November 2006 (UTC)

Doesn't that kind of contradictory to list a band member as a solo singer? Perhaps we should either change the wording or create a type just for members of a band? I think that a type just for band members would be best, because why should a singer get their own color but every other band member be the same? Joltman 12:44, 20 November 2006 (UTC)

I think you're correct. There should be a "band_member" category with the same color as the band color. Maybe add the wording "Member of /band/" up top, like singles have "from /album/" on them. *Spark* 13:01, 20 November 2006 (UTC)

[edit] Centering Subsection Headers

If you check any usage of this template, the name of the artist is centered at the top of the template, but the subsection headings (Background info, Members, former members, etc.) are left justified. I believe they should all be centered (just looks better IMO). Comments? *Spark* 23:01, 17 November 2006 (UTC)

They are all centred in my browser.--NeilEvans 23:06, 17 November 2006 (UTC)

I don't see any explicit centering code in the template. Check Rush (band) for an example. The subsection headers are left justified in my browser (Firefox). *Spark* 23:12, 17 November 2006 (UTC)

There lies the problem. I am using Internet Explorer. If I knew how to change the code I would.--NeilEvans 23:21, 17 November 2006 (UTC)

Well, I'm using Firefox, like Spark, and it's centered for me. Furthermore, the explicit centering code is the part where it says 'style="text-align: center;"', which it says before each of the headings. Spark, I don't know why it's not centered for you, but I strongly suspect that the problem is on your end, somehow. Does anyone else see the headings left-justified? Xtifr _tälk 23:50, 17 November 2006 (UTC)

Very very strange - I logged out and viewed the page. Everything is centered correctly. Logged back in, left justification. I have a few css/javascript changes, looks like something is mucking with the pages. *Spark* 00:22, 18 November 2006 (UTC)

Found it. My Preferences->Misc->Justify Paragaph was checked, and overriding the centering code. Don't know if there's a way to fix that, but that was the cause. *Spark* 00:46, 18 November 2006 (UTC)

[edit] Colors

Can someone pretty please change the pink color that gets assigned to instrumentalists? Of all the proposals above, I don't see that anyone is actually in favor of that color. It's killing me. --Aguerriero (talk) 18:15, 20 November 2006 (UTC)

Sorry, I have lately been involved in the Esperanza MfD, so discussion has died out. Hopefully we can get a vote going soon. – Heaven's Wrath   ^Talk  21:46, 20 November 2006 (UTC)

[edit] Colour selection

While I agree with the idea of colour-coded boxes, and particularly like the khaki scheme used for the 'solo artist' box, I'm not sure cyan is the best candidate for 'band' infoboxes. To my eyes it doesn't travel well, in that while it looks ok and appropriate for pop bands etc, it generally looks too 'soft' for most alternative and rock bands. Also cyan is a colour that clashes easily, IMHO.

I'd like to know what others would think of using more a neutral and muted colour, such as "darkseagreen" or "#cccc99". Sorry If im coming late to this discussion and you've already been through the issue, but its an important one. Thanks - Coil00 22:54, 30 October 2006 (UTC)

I agree that the current colors bear further discussion. Note that they're a legacy from the first, defunct, Musicians WikiProject. I strongly disagree with any suggestion that genre or style should be a consideration (I know you didn't say that, but I want to make it clear up front). I definitely think some of the current colors are oversaturated, and would be less obtrusive if they were more subdued. Members of the Guitarists WikiProject have expressed their dislike for the pinkish-red used for non_vocal_instrumentalists, and I tend to agree with them. Gross changes (i.e. switching from cyan/blue completely) will affect huge numbers of articles, and should only be done after consultation with many other WikiProjects that will be affected, but more subtle changes, such as reducing the saturation or making minor adjustments to the tint, should be fairly non-controversial. The darkseagreen, IMO, is much too dark, much too saturated, and, well, green.  :) I actually made a psuedo-template over the weekend that can be used to help this discussion (based on something I saw at the albums wikiproject), but it's not quite ready to go. But I definitely think it's about timme to start this discussion. Xtifr _tälk 23:41, 30 October 2006 (UTC)

I acknowledge that you didn't contradict me, but to be clear, my wish is that the colour selected is: 1. neutral, 2. does not 'imply' upon the article it is used for, and 3. is unlikely to clash with the band image used in that article. (We're really saying the same thing here.) I'm not sure a desaturated blue will deliver this, but am open to suggestion.

What we are effectively talking about is a 'picture frame', meaning the colour should be as unobtrusive as possible. My own preference would be for a light brown, grey or green (hey, I like green!), but if you're making up mocks, great. Maybe we can put together a few templates (I'd need help on this), and try for a consensus. Anyway, thanks for the quick reply! - Coil00 00:00, 31 October 2006 (UTC)

I also agree that we should try for agreement from all projects, and, given the number of pages affected, should lobby wide, getting as many views as possible before a decision is made. - Coil00 00:44, 31 October 2006 (UTC)

I agree that the current cyan colour is not very good in terms of aesthetics, although my real gripe is having it as a background colour for the title bar. Precious few infoboxes have this, and it when rendered it results in many infoboxes (in particular those that use band logos as names) looking stupid. Toning down the colour would be a good start, but I would like to see a simultaneous removal of background colour for the "name" field - it the broader scheme of things it does not serve any purpose. DJR (T) 02:37, 31 October 2006 (UTC)

I took this comparison template for WikiProject Albums. Just copy the code an you can add your new suggestions. This will allow us to better see the differences between colors. (also, see this dicussion for color ideas) – Heaven's Wrath   ^Talk  02:56, 31 October 2006 (UTC)

Proposal #0

solo_singer	khaki	===>	solo_singer	new
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	new
non_performing_personnel	lightgreen	===>	non_performing_personnel	new
group_or_band	lightskyblue	===>	group_or_band	new
cover_band	plum	===>	cover_band	new
classical_ensemble	paleturquoise	===>	classical_ensemble	new
temporary	darkgray	===>	temporary	new

As the user who created the original color scheme, I should point out that the colors were not selected for decoration, but for cataloguing purposes. I had three requirements in mind when selecting the colors: (1) make them obviously different from one another, and (2) make them natrually bright, but not overly saturated. Upon re-evaluation, new colors wouldn't be a bad idea, and the template colors is easily adaptable (never realized just how...wrong a choice that red really was, especially for the "guitarist jock" set. I just needed somethign that wasn't one of the other hues and...that's what I ended up with). So long as functionality and purpose are not compromised. Also, not to be a drag, but geez...aren't there more important things to worry about on Wikipedia than what color your favorite band's article's infobox is going to appear? (And to the person who said that infobox colors serve no purpose -- they indeed do, as they allow quick and easy identification of various musical act types before one jumps into the article. It is an organizational mechanism). --FuriousFreddy 05:46, 3 November 2006 (UTC)

To reply to the dismissive comment above: it's not just my 'favorite band's infobox' that's effected, but all band's infoboxes on Wikipedia. Surely, the visual presentation of hundreds of articles is worth tiring people with. Coil00 23:31, 3 November 2006 (UTC)

Yes, visual presentation is important, but in no way are any of the color options truly garish or inconvenient (or, at least, certainly not as garish or inconvenient as the original album infobox colors, or the colors that were originally to accompany this infobox). While changing the colors is certainly not a wholly objectionable activity, I just think it might be more important to press for putting this much energy into improving the overall quality of music articles on Wikipedia, and also to make sure the infoboxes are being used properly in the first place, verses color selection. But that's just my opinion, and I'm neither pushing for or against any changes. --FuriousFreddy 02:37, 5 November 2006 (UTC)

There has been a fair amount of negative feedback about the current colors, and many instances of people resisting the use of this infobox because of the colors. For that reason, I think it's worthwhile exploring some alternatives. This is not what I'm spending all, or even most, of my time on, but it's something I'm keeping an eye on, and I hope to get it resolved before long so I don't have to spend any more time on it! :) Xtifr _tälk 02:59, 5 November 2006 (UTC)

[edit] Proposed colour selections

[edit] Proposal 1

Yeah, Heaven's Wrath has obviously been looking in some of the same places I have.  :) I made it into a psuedo-template, though, which is even easier than copying HW's whole table. Just fill in the colors (or colours if you prefer) in order. (A good place to start to find possible colors is at Web Colors). Here's a quick suggestion:

Proposal #1

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	SandyBrown
non_performing_personnel	lightgreen	===>	non_performing_personnel	lightgreen
group_or_band	lightskyblue	===>	group_or_band	LightSteelBlue
cover_band	plum	===>	cover_band	Thistle
classical_ensemble	paleturquoise	===>	classical_ensemble	paleturquoise
temporary	darkgray	===>	temporary	LightGrey

I really like the LightSteelBlue. It's much closer to a neutral grey, but still contains enough blue to be obviously colored. I'm not as sure about the SandyBrown, but I do think it's an improvement over the lightcoral (almost anything would be). Xtifr _tälk 09:58, 31 October 2006 (UTC)

Comments

• I like this selection of colors because it keeps a variety of colors and mutes them at the same time. I also think the lightsteelblue is a very general color and would look good for all bands. Thistle is close to lightsteelblue, so maybe we should find a new color for cover bands (or keep the old). – Heaven's Wrath   ^Talk  23:29, 31 October 2006 (UTC)
• This is a good proposal, as it retains something of the hues of the original scheme while making them less saturated. --FuriousFreddy 05:46, 3 November 2006 (UTC)
• This is an improvement and even keeps much of the colour info for nearly-blind and colour blind persons, but I still think that lightgreen and sandybrown are too strong. I also seem to be the only one to have a problem with paleturquoise? I'd much prefer AntiqueWhite or some other more neutral colour. Prolog 19:50, 4 November 2006 (UTC)

I share your paleturquoise concern ;) Would be happy with AntiqueWhite as suggested, or, not wanting to push my luck, #cccc99 as in option 2 below. - Coil00 20:00, 4 November 2006 (UTC)

Nice to know I'm not the only one, although colours do show differently to each eye and monitor. I agree with #cccc99 as a colour for classical ensembles. Prolog 20:06, 4 November 2006 (UTC)

Just a tought, but I'd be in favour of broadening the scope of classical ensemble to also include composers and conductors. I'll give it some tought and maybe raise it as a seperate thread. - Coil00 20:13, 4 November 2006 (UTC)

Antique white is extremely similar to khaki, to the point where some users will not notice a dicernable difference --FuriousFreddy 23:41, 4 November 2006 (UTC)

Possibly, but some of the light-brownish colours listed on web colors should make a contrast high enough, so it wouldn't be mixed up with khaki. Prolog 13:30, 6 November 2006 (UTC)

[edit] Proposal 2

Ok good, this is a handy template for comparing diff options. I've gone for #cccc99 for bands; as I was saying color should be muted, unobtrusive and mix well with other colours appearing in the band photos.

Proposal #2

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	SandyBrown
non_performing_personnel	lightgreen	===>	non_performing_personnel	lightgreen
group_or_band	lightskyblue	===>	group_or_band	#cccc99
cover_band	plum	===>	cover_band	NavajoWhite
classical_ensemble	paleturquoise	===>	classical_ensemble	paleturquoise
temporary	darkgray	===>	temporary	LightGrey

- Coil00 22:02, 31 October 2006 (UTC)

Comments

• The problem I have with this color selection is the similarities between the colors. I do not think I could tell the difference between the colors if they were alone in an article. (Does that make sense?) The goal is to have a set of colors that are easily distinguishable from each other. – Heaven's Wrath   ^Talk  23:34, 31 October 2006 (UTC)

• That does make sense, I've changed "PaleGoldenrod" back to "lightgreen" accordingly. - Coil00 23:47, 31 October 2006 (UTC)

• The #cccc99 is a little too close to, um, babypoo brown for my tastes. :) --Xtifr _tälk 08:32, 1 November 2006 (UTC)

Mmm, 'too green' (quote), 'too brown' (paraphrasing)..! Thanks for you honesty anyway Xtifr ;). I can see it's going to be difficult to agree a move away from blue, but that's ok too; it's a matter of taste, and taste is always going to be subjective. I'm not particularly married to either of the colours I've suggested - what I'm looking for is one having a framing effect, similar to the khaki of the solo singer box. To use these words again - muted. neutral. unobtrusive. compatible. And those blues are just not such colours. But your own suggestions are welcome.

On a side note, perhalps the height of the coloured bars could be reduced, might help negate the imposing effect they currently have.- Coil00 00:09, 3 November 2006 (UTC)

The colored bars should not be reduced in height. The main title needs to be its larger size for obvious reasons (when this template becomes populated, it can appear long and monotonous -- offsetting the title prevents the entire thing from being a homogenous mess), and the other bar is to re-emphasize the color and to match the album and singles infoboxes. --FuriousFreddy 05:46, 3 November 2006 (UTC)

• I'm with Xtifr, I guess. The band colour should be something easier, more neutral and suit better to Wikipedia's current layout, since "group_or_band" is and will stay the most popular one. Prolog 20:00, 4 November 2006 (UTC)
• That's ok, I've since supported Xtifr's suggestion for the band color below. The brown is probably more suited to classical composers or ensembles, as I've mentioned above.
• My concern re the bar height stands. Maybe not so much with the title bar, but both the 'Background information' and 'Former members' bars have a lot of space between the edge and text. Also, do we really need a separate bar for former members? - Coil00 20:10, 4 November 2006 (UTC)
  • About the "Former members" section, it's good that you brought it up. Former members isn't so crucial information that it would need to be in the infobox. On Iron Maiden, there's 18 (!) of them, and the box has sort of lost its purpose and become a long list instead. Prolog 20:28, 4 November 2006 (UTC)
    • This has already been debated above, but I know what you mean - had a similar problem with Mayhem a few months back. I'd say in cases like these former members are best kept to a seperate section at the end of the article. However, for most bands former members is a valid infobox subsection. My point is that it's not one that warrants a third colour bar. - Coil00 21:00, 4 November 2006 (UTC)
      • The Fall is the supreme example of an out of control former members section. And it grows week by week! - Coil00 21:05, 4 November 2006 (UTC)
      • I wan't joking! [1] - Coil00 00:10, 7 November 2006 (UTC)
        • "Former members" was something that was debated long ago, for articles about acts that continue to perform, but without hteir best-recognized lineup. For example, it looks rather odd to have an article on The Miracles without listing Smokey Robinson. Iron Maiden's "former members" list is no worse than The Temptations', but The Fall's list is poor looking because it is not properly formatted. I will fix that. And how and why does "Former Members" not require a separate "color bar" section? What would the alternative be?--FuriousFreddy 23:48, 4 November 2006 (UTC)
          • Why a bar for former members in paticular, is a blank space not enough? Former members seems arbitrary, and on that logic why not a large colour bar for each element? The footprint of the infobox should be as small as possible IMHO. Freddy, your judgement on these issues seems to be sound so far, I'm just voicing my openion, am open to your views and willing to stand corrected. I just want to get these issues out and off my chest. On a side note, it's a badge of honour with the Fall about all the ex-members, as a long term, damn it, fanatic, i think the list is great. my to-do list is turning the reds to blues. - Coil00 01:03, 5 November 2006 (UTC)
            • Yes, the footprint should be as small as possible, which is why we want to avoid listing anything but names. However, former members is an important field for many groups, and, yes, maybe not so for others. We have to find some sort of balance, however, so that we can accommodate each type of article. Perhaps we could make it policy for, with groups that have more than 10 former members, to list any particularly notable former members up to ten, and then place a note "for more, see [[#Personnel|Personnel]]". As for the bar thing, I was just asking for an alternate solution. I, personally, don't care one way or the other, so long as any changes are done without breaking any of the pages. Many articles on musical acts have all "former members" and no "current members" (The Supremes, for example), so the seperating bar needs to be there if it is to be there for the "(current) members" section as well. --FuriousFreddy 02:30, 5 November 2006 (UTC)
              • My openion is that neither the current nor former members bar is needed. Can I get some views on this. - Coil00 00:10, 7 November 2006 (UTC)

[edit] Proposal 3

Ok, let's try something else. If we're going to go with green for "group_or_band", then we should pick one thats neither too saturated nor too muddy. And if "group_or_band" is going to be green, then "non_peforming_personnel" can't be. And I think it's more important to have "non_performing" stand out than to have "cover_band" stand out. I mean, honestly, is "cover_band" really worth wasting a whole color on? Anyway, this is what I've come up with. I'm not sure we're there yet, but it's something to contemplate.

Proposal #3

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	SandyBrown
non_performing_personnel	lightgreen	===>	non_performing_personnel	plum
group_or_band	lightskyblue	===>	group_or_band	#bfe0bf
cover_band	plum	===>	cover_band	lightsteelblue
classical_ensemble	paleturquoise	===>	classical_ensemble	paleturquoise
temporary	darkgray	===>	temporary	LightGrey

BTW, while I'm here, I want to suggest adding singer_instrumentalist. With a color possibly somewhere between khaki and sandybrown:  singer_instrumentalist  in peach, or something like that. The category certainly seems far more useful than "cover_band"!  :) Xtifr _tälk 21:14, 3 November 2006 (UTC)

The band colour is well chosen, Xtifr. BTY what IS a non performing personnel? Bez is the only example I can think of ;) - Coil00 21:31, 3 November 2006 (UTC)

The template page lists it as: "All composers, producers, songwriters, arrangers, engineers, and other non-performing personnel." – Heaven's Wrath   ^Talk  00:02, 4 November 2006 (UTC)

The definition is incomplete. Should be changed to "All composers, producers, songwriters, arrangers, maracca shakers, engineers, and other non-performing personnel." - Coil00 00:12, 4 November 2006 (UTC)

Maracca shakers would be under "non_vocal_instrumentalist." :-) – Heaven's Wrath   ^Talk  04:07, 4 November 2006 (UTC)

[edit] Proposal 4

Get rid of the colors. —freak(talk) 01:47, Nov. 4, 2006 (UTC)

[edit] Proposal 5

Basically, a milder version of #3. Per Prolog, I toned down the SandyBrown by reducing its saturation to 40, and this is what I got. Thistle is a lot more subdued than Plum. And I think the PowderBlue is at least a little less intrusive than the paleturquoise.

Proposal #5

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	#f4bf92
non_performing_personnel	lightgreen	===>	non_performing_personnel	Thistle
group_or_band	lightskyblue	===>	group_or_band	#bfe0bf
cover_band	plum	===>	cover_band	lightsteelblue
classical_ensemble	paleturquoise	===>	classical_ensemble	PowderBlue
temporary	darkgray	===>	temporary	LightGrey

I'm not sure about "composer_or_conductor", if we end up adding that, but perhaps a tan or brown of some sort would work. Xtifr _tälk 22:37, 5 November 2006 (UTC)

I like this. All the colours are pretty neutral and unobtrusive, yet they are still clearly different from each other. I'd personally keep the old primary colour set between non_performing_personnel, group_or_band and cover_band though, as I think the blue (lightsteelblue) fits best to the current WP colour scheme, and the band colour is much more popular than cover band one. The green does look very good, though. Prolog 13:15, 6 November 2006 (UTC)

Just in case it wasn't obvious: my thought (with this and #3) was to have similar things use similar-but-distinctive colors, so that even if you see a new color for the first time, you'll get a strong hint that it's similar to things you have seen before. Thus, individual musicians from red/yellow range of the spectrum, groups from blue/green, and non-performers get purple all to themselves. However, given the relative rarity of "cover_band", perhaps "cover_band" and "classical_ensemble" could be switched. (I do like the lightsteelblue.) Xtifr _tälk 23:23, 6 November 2006 (UTC)

[edit] Proposal 6

Proposal 5 colors, different order - Today's colors muted a bit. Any sort of group (band/cover/ensemble) have a stronger blue channel in the color (cooler colors), soloists have yellow/orange (warmer), green goes to non-performers (which could be expanded later). *Spark* 22:44, 20 November 2006 (UTC)

Proposal #6

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	#f4bf92
non_performing_personnel	lightgreen	===>	non_performing_personnel	#bfe0bf
group_or_band	lightskyblue	===>	group_or_band	lightsteelblue
cover_band	plum	===>	cover_band	Thistle
classical_ensemble	paleturquoise	===>	classical_ensemble	PowderBlue
temporary	darkgray	===>	temporary	LightGrey

Note: I mostly went with the color order in #5 due to some strong objections to the use of blue for group_or_band. Xtifr _tälk 10:10, 21 November 2006 (UTC)

[edit] Proposal 7

This is a variant of 5 above, except haved used lightsteelblue for non-vocal instrumentalist (a fairly widely used template, deservs more than the link /orange. Also, I think #cccc99 would be well suited to classical related infoboxes. - Coil00 22:14, 22 November 2006 (UTC)

Proposal #7

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	lightsteelblue
non_performing_personnel	lightgreen	===>	non_performing_personnel	Thistle
group_or_band	lightskyblue	===>	group_or_band	#bfe0bf
cover_band	plum	===>	cover_band	#f4bf92
classical_ensemble	paleturquoise	===>	classical_ensemble	#cccc99
temporary	darkgray	===>	temporary	LightGrey

I still find cccc99 extremely ugly, and I have no idea what "deserves more than the link /orange" means. I think the orange for non_vocal_instrumentalist has the strong advantage of being similar enough to the "khaki" yellow to make people think they're dealing with something similar (which they are) while still being distinctive. Whereas, making it the color used for cover_band makes that category so completely distinctive from group_or_band that it is potentially confusing. Xtifr _tälk 02:20, 23 November 2006 (UTC)

Re: "link /orange" - typo there, meant 'pink'. Not sure its a general enough colour for such a widely used category. Everything else looks good. - Coil00 21:54, 24 November 2006 (UTC)

[edit] Proposal 8

On the other hand, if we absolutely must have cccc99, it should be used (IMO) on a category that appears rarely. Plus, this eliminates all variants on the baby-blue that several people have objected to. And it leaves open the possibility of using another shade of blue for the proposed new category, composer_or_conductor. Puts individual musicians in the yellow/orange spectrum, bands in the greenish spectrum, classical in the bluish spectrum, and leaves purple for the not-really-musicians-after-all category. Xtifr _tälk 02:20, 23 November 2006 (UTC)

Proposal #8

solo_singer	khaki	===>	solo_singer	khaki
non_vocal_instrumentalist	lightcoral	===>	non_vocal_instrumentalist	#f4bf92
non_performing_personnel	lightgreen	===>	non_performing_personnel	Thistle
group_or_band	lightskyblue	===>	group_or_band	#bfe0bf
cover_band	plum	===>	cover_band	#cccc99
classical_ensemble	paleturquoise	===>	classical_ensemble	lightsteelblue
temporary	darkgray	===>	temporary	LightGrey

[edit] Voting

Please indicate your support for a color system below.

[edit] Proposal 1

• Oppose, I think the lightgreen is unacceptable, and the sandybrown and paleturquoise are marginal. (And note, this was my proposal.) Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 2

• Oppose, I think the lightgreen is unacceptable, the sandybrown and paleturquoise are marginal, and the cover_band color is potentiall confusing. Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 3

• Oppose, I think the lightgreen is unacceptable, and the sandybrown and paleturquoise are marginal. (And note, this is my proposal.) Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 4

• Neutral, I think the colors are useful for identification, but this does have the advantage of not using any colors that anyone has objected to. :) Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 5

• Support Very subdued and nice color selection. – Heaven's Wrath   ^Talk  21:54, 20 November 2006 (UTC)
• Support, I like the green, and hate to waste it on a variation of the infobox that is almost never used. Though #6 is fine too Xtifr _tälk 07:16, 21 November 2006 (UTC)

[edit] Proposal 6

• Support Like 5's colors, think the assignments are wrong though. *Spark* 22:45, 20 November 2006 (UTC)
• Support. As I mentioned above, I like #5 but prefer to have lightsteelblue for group_or_band. Prolog 22:56, 20 November 2006 (UTC)
• Support For same reasons as #5. I like this more. – Heaven's Wrath   ^Talk  23:20, 20 November 2006 (UTC)
• Support These colours are similar to those already in use but will be a lot less intrusive on the article pages.--
• Support Is similar to the existing scheme, which has advantages. I slightly prefer #5, but this is perfectly adequate. Xtifr _tälk 07:16, 21 November 2006 (UTC)
• Support as for reasons stated above Andrzejbanas 09:28, 21 November 2006 (UTC)

[edit] Proposal 7

• Support Per Xtifrs reasoning above with a few swap arounds. - Coil00 22:14, 22 November 2006 (UTC)
• Mildly Oppose, I think the blue for instrumentalists and orange for cover bands is simply too confusing. Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 8

• Support while I still have mild reservations about the puke-green, it could grow on me, and this does have the advantage (IMO) of making similar things similar-but-distinctive. Xtifr _tälk 02:43, 23 November 2006 (UTC)

[edit] Proposal 6 Implemented

Since proposal 6 seemed the clear preferred choice, I've implemented the changes. *Spark* 15:39, 2 December 2006 (UTC)

Sounds good. Thanks for being bold. – Heaven's Wrath   ^Talk  16:03, 2 December 2006 (UTC)

I agree, it was definitely time. (Would have done it myself if I hadn't been sick the last couple of days.) However, since the color names aren't part of the W3C standards, I've replaced them with color codes. I also took out the aliases that Spark had silently added because A) I'm not sure they're a good idea--simpler is better, and B) if they're going to be done, they should be proper aliases, not just additional cases. We can discuss it at length later, but for now, I think the status quo is more sensible. Xtifr _tälk 17:10, 2 December 2006 (UTC)

Good move. Looks great. - Coil00 19:15, 2 December 2006 (UTC)

Problem: The selected color for bands is almost exactly the same as the color used in template:album infobox for studio albums, this might cause confusion in the future. —The preceding unsigned comment was added by Nightmare X (talk • contribs) 13:50, 3 December 2006 (UTC).

[edit] Request:The Template's code (for Arabic Wikipedia)

Hi. Listen, I'm currently expanding the article for Linkin Park in Arabic [2] and I'd like to know the code for the Arabic musical template asap. And if there is, can you add the Arabic interwiki? Thanks.

P.S. Here's one interwiki that needs to be added for this musical template: "fa:الگو:جعبه اطلاعات هنرمند موسیقی"

-- Qasamaan 6:52, 23 November 2006 (UTC)

I added the interwiki, but what do you mean by the code? It is all there on the template page. Just hit edit and you can look at it and copy it. – Heaven's Wrath   ^Talk  00:01, 27 November 2006 (UTC)

[edit] Color - Hex vs. Name

Xtifr updated my name changes with the comment "use more portable color encodings, rather than color names". Can someone explain the rationale behind this?

I was going to comment on Xtifr's talk page but thought it might be useful as a MOS on templates. To me, using names is more portable, as if a mirror wants to implement different values for those colors, they can. Same for printing, a named color can be changed, a hex RGB triplet not so much. In fact, I believe a user could override these colors if they wanted using css (though haven't investigated). Thanks. *Spark* 17:08, 2 December 2006 (UTC)

Those color names aren't part of the W3C standards. And no, I don't know of any way that color names can be overridden, although we might be able to re-implement the template using styles, which would allow the colors to be overridden. Seems like it might be a lot of work for not much gain, though. So really, the only difference between color names and hex triplets is that hex triplets are a real web standard, while the color names (at least, these ones) are merely a convention. Xtifr _tälk 17:16, 2 December 2006 (UTC)

Color names are listed in the CSS3 working spec [3] and are standard on popular browsers [4]. Using a name is more flexible than hardcoding RGB. Keep in mind certain color combinations don't work well for the colorblind, which could have their software configured to handle css color names differently. Is there a MOS statement on named vs rgb colors? *Spark* 18:24, 2 December 2006 (UTC)

RGB triplets are just as easy/difficult to override if someone really wants to. There's no more flexibility in the one than the other. And the triplets give greater backward compatibility with older software. Also, there's a consistency issue: we're using some colors that don't have names. I think it's better to have all names or all triplets, and since all names isn't an option any more, I think all triplets is the btter choice. I don't feel strongly about this, and if you can find some MoS or something to support using color names, then I'm fine with it, but it just doesn't seem right to me. Xtifr _tälk 19:49, 2 December 2006 (UTC)

Named colors are easier to tailor to your preferences. It's much easier to have a stylesheet change than having a program parse and recalc RGB. The named colors go back quite a few revisions, even though they haven't been official until CSS3. Much more flexible than hardcoded values. Hardcoded RGB just doesn't seem right to me. Interesting, isn't it? I'll investigate more, but am leaning toward putting back the names where they can be put back unless there's something stating that is definitely not proper. *Spark* 00:47, 3 December 2006 (UTC)

Hex triplets can be matched just as easily as arbitrary names. You don't need to "parse and recalc" anything! In any case, there's no named styles here to override (just "infobox", which is too generic to help in this case). We could possibly rewrite the infobox to use different named styles for each type of background. But then you wouldn't care what the default colors were, you could just plug in your own preferred values. Which is maybe something to consider in the future (I might even try to build a prototype). But as it is, hex triplets are compatible with old browsers, cell phones, and all sorts of things, whereas named colors (beyond the sixteen that are standard) are not necessarily. And overriding seems just as easy either way (unless you can show me a counterexample). Xtifr _tälk 01:40, 3 December 2006 (UTC)

(<-left shift) On matching - named values are evaluated through a lookup table/map. RGB values aren't. Customizing a lookup table for 147 named colors would require a change in that map. Doing it for 16 million colors would be a bit more complex and require a change beyond an updated map. Named colors give you a known working set of possibilities. Named colors (most if not all of the X11 colors), have been in Netscape since 1.1 and IE since at least 3. I don't think I can name a browser on any platform that doesn't support that named color set. If you can point one out, please do. Keep in mind when talking about mobile platforms or older systems, going with named colors is generally better, as the software for those systems can easily map those colors to something decent on that platform. I'm saying not only should we use named colors, we should be restricted to them (or styles) in templates. I had thought about starting a push to use styles for infoboxes. Maybe it's time to head in that direction. This discussion goes beyond the musical artist template. *Spark* 11:51, 3 December 2006 (UTC)

Ah, I assumed you were talking about using some combination of javascript and styles to remap the colors, which would work just as well for these seven specific colors no matter what their format. If you're talking about hacking your system colormaps, well, I think that's a bit much to expect of most people. Anyway, we already have two colors that lack names, so at best, you'd be able to remap five of the seven. Furthermore, those two nameless colors happen to be our red and green, and red-green color-blindness is the most common type, so we wouldn't be able to help most color-blind people even if we did enable this dubious hackery. If we want to allow people to control the colors, I think the right way is with styles (or javascript), not color-map hackery. But the real bottom line for me is that the template was using hex triplets, and I don't know why, but I don't want to find out the hard way that there was a very good reason. I don't think this is the right template to use for casual experimentation. A meta-discussion at a higher level sounds great; experimenting with this template, not-so-great. Xtifr _tälk 18:18, 3 December 2006 (UTC)

I'm not certain if, for example, the firefox base allows for changing named colors via some sort of properties file. Looked around a bit, didn't find anything. I wouldn't expect an end user to modify maps, but I could see a usability group putting together a special build or a patch or plugin that could be applied to the generic browser to address the issue, if one hasn't already. As to why I did it, I did not consider it experimentation, I considered it consistency. Most every other template I've worked with uses named colors. That's why I was looking for a MOS statement. If you find the right forum for discussing the potential for a style based approach, fire me a message. Don't know that I have much time to dig into it at the moment but that might change in a few weeks. *Spark* 18:27, 3 December 2006 (UTC)

[edit] Archive

Can someone with the know-how archive closed discussions please (page is now 115kb) - Coil00 21:41, 2 December 2006 (UTC)

Done. See floating archive box for the link. *Spark* 00:42, 3 December 2006 (UTC)

Thanks, I was about to do this myself. The page was getting rather large. – Heaven's Wrath   ^Talk  02:52, 3 December 2006 (UTC)

[edit] New field: distinguishing genres and styles

As part of a proposal to try and end "genre edit wars", one of the things I requested was that a Style(s) field be added to this template.

To view this proposal, see Wikipedia talk:WikiProject Musicians#Genre wars and the distinguishing of genres and styles.

I would appreciate feedback on this proposal. I am going to push hard for this proposal to be put into action, and I appreciate any supporters in helping me do so. Thank you. --Reaper X 00:53, 11 December 2006 (UTC)

This has already been discussed and rejected (see the archived discussion). Xtifr _tälk 04:29, 11 December 2006 (UTC)