Difference between revisions of "Template talk:Req sub"

Latest revision as of 16:27, 8 June 2012

A Thought

I have noticed that this handy little template is getting thrown around quite a bit, and wonder if it is really necessary in all of those places... one recent change was removing it from the WST Page due to the way it clipped into the text and the idea that moving it above or below the relevant bullet-point may make it unclear what aspect of the list it was referring to, somehting a simple in-text mention of the requirement wouldn't do. Is there a "style guide" of sorts to when and how this template should be used?

While I am thinking about it, I further wonder why it is that this template is the size and shape that it is... should it maybe be formatted in a page-wide divbox similar to the different IOFlags for consistency sake? In my mind, it gives the same type of information, and should therefore be formatted similarly. This would also make it easier to "rule-out" illogical placements: if a page-wide divbox wouldn't look right, then it would be a good clue to use a simple in-text mention of the requirement. Or is the ability to make it really obvious important? Perhaps a seperate template could be made like: ( This activity requires an active subscription.) could be used?

And then, for pages like the BAF and other things in which the entire page is gated by a VIP subscription, something more like:

In order to make use of this content an active subscription is required!

could be used across the top?

Just spitballing ideas here based on what I have seen. ~ Thirty7 19:50, 30 November 2011 (UTC)

The flag is the size and shape it is because a) it's a very short statement and thus doesn't need to be big, b) it's meant to be used in-line when the whole page doesn't require a subscription, and c) it's placed directly below the Overview or within the Infobox of pages that the entire contents requires a subscription (or GR, or SSA purchase, or zone pack, whatever). One template to do the work of two. The IOFlags are used ONLY on pages where the entire contents are applicable (individual IO pieces), and often have extended descriptions, thus the large flags. I am 100% against making the VIP flag so big. Take a look, for example, at BAF - how much better that little notice looks in the infobox, rather than a giant banner across the top? ~ AGGE talk/cons 22:44, 30 November 2011 (UTC)

To a degree, I see your point. However, I disagree with you that it looks good in the Infobox (eg. on the BAF page). To me, it is too small in that box, and seems more of a side note. Also keep in mind, that like the IOFlags, I only proposed the use of a larger banner on pages that were totally gated beyond the VIP Wall... such as the trials. On other pages, like the one for WST Rewards, it would only need to be a small notice as it is now. However, the way I see it, the current notice is too small in some places, and too large in others. Also, in my thinking, the length of the statment itself is a non-issue. To me, the importance of the statement is of more significance. It states some very critical information to have when one is perusing the pages on which it is used... but the duality of that matter is that it can also serve to highlight some rather insignificant information as well. Like I said earlier, I am just sorta thinking out loud about this thing, and don't really want to cause waves... but I just don't agree with your position (totally). ~ Thirty7 20:29, 1 December 2011 (UTC)

I have to say, I'm not a fan of the way this template looks.

• In infoboxes, the background color matches the infobox background color (to my eyes, at least), so it just has a border around it and ends up looking a bit odd to me. Remove the border, or change the background color, or something. Or better yet, don't use it in the infobox. Add it to the infobox as a normal key=value entry like anything else if it needs to be there.
• Inline in text, it sticks out like a sore thumb and I personally don't care for it. The contents won't wrap so if it happens near the edge of a page, the whole block gets sent to the next line leaving a bit gap; of course, allowing wrapping inside would be even worse. Why does it need the border and background color in the text? The icon is sufficient for calling attention to it, I think.
• In contexts where it applies to a whole page, it's fairly easy to miss. It's a little box of text, often embedded in something else (a paragraph of text, an infobox) and thus easy to miss. If it's that important to know, then it should be more pronounced. A full-width banner might not be the worst of ideas; I don't think it'd be ideal, but I can't think of a better way to handle it.

In short, I don't like the "one size fits all" approach being used here. We don't need to limit ourselves to a single template and then force all contexts to use it. We can (and I think, should) have multiple ways of presenting this tidbit of information. They should have a consistent theme, of course, but they can vary in exact display. -- Sekoia 21:57, 1 December 2011 (UTC)

That is pretty much exactly what I was trying to get across... but you said it a million times better, Sekoia, thanks! ~ Thirty7 01:10, 2 December 2011 (UTC)

Formatting issues

Regardless of the outcome of the above conversation, this template is not rendering nicely within Chrome. Two examples:

The first image is from the Behavioral Adjustment Facility Trial article; notice how the icon dips below the box's boundary. The second image is from the Weekly Strike Target article; notice how the icon touches the bottom box boundary. So the icon has a different vertical alignment in each of those cases. Worse, neither case looks good (IMO). There should be space below the icon, and it should look vertically centered with respect to the text/box. -- Sekoia 21:42, 1 December 2011 (UTC)

Auto category?

Should this template automatically include its articles into a category? Maybe some sub-category of Category:Gameplay? That way it would be easy to see all the content and information which require a VIP subscription. — MrDolomite • Talk 21:19, 6 June 2012 (UTC)

The template is often used on specific items within a larger article. As an example, Issue 23 Badges uses the template, but only some of the items on the page are VIP restricted. I think it'd be good to have a category for VIP restricted articles, but I don't think auto-categorizing them with this template will give a good result. -- Sekoia 00:37, 7 June 2012 (UTC)

Perhaps a Parameter that does it then? {{Req sub|cat}} would do it automagically? There are some cases, (individual badge pages) where it would come in handy. —  Talk · Cont 01:24, 7 June 2012 (UTC)

I wouldn't call it automatic at that point. If we have to manually add on a parameter to the template for it, we may as well manually just add the category to the page. :) -- Sekoia 05:58, 7 June 2012 (UTC)

I suppose one could look at it that way... but it seems easier to me than that. *Shrug* I have no vested interest in it.  :) —  Talk · Cont 14:39, 7 June 2012 (UTC)

Well, I certainly won't revert the change if it's made, especially if I'm the only one saying such. :) If it's done, I would suggest making it {{req sub|cat=1}} (that is, using a named parameter rather than a positional one). Usually we use nocat=1 to suppress categories on templates that auto-categorize by default, so cat=1 is a natural analog. It's also more extensible if we want to add other options at some point. -- Sekoia 21:07, 7 June 2012 (UTC)

Good points. I was thinking of its use on a standalone page for one item, which is where the autocat makes sense. When it is on a larger page, like an issue, and used inline, then the autocat doesn't. Which way the template is used most would help decide if the cat parm should be a default setting with either an opt-in or opt-out override. — MrDolomite • Talk 07:48, 8 June 2012 (UTC)

I honestly think that it is used most often as an in-line note on things like Issue 22 Badges and the like. If added, the param should have to be set in order to add the Category. If not least of all so that pages ALL don't have to get updated to forcibly remove said category through editing them all. —  Talk · Cont 16:27, 8 June 2012 (UTC)