StrategyWiki:Staff lounge

__NEWSECTIONLINK__

Welcome to all users! This page is where people can ask StrategyWiki-related questions to the staff and senior community figures, and they will do their best to answer. If you want to raise a topic for discussion (rather than just ask about it), please use community issues instead. New issues are entered here, with the most recent at the bottom of the page. If your question does not pertain to editing StrategyWiki (i.e. asking for hints or game-specific information), please ask on the guide's talk page or on the forums.

Please review the Table of Contents to see if your issue has already been raised; also check the archives (to the right) in case it was discussed some time ago.

To facilitate ease of browsing and replying, please:
 * 1) Place your question at the bottom of the list
 * 2) Title the question (by placing the title between equals signs: ==title==)
 * 3) Sign your name and date (by adding two hyphens and four tildes: --~ )

Control table styles

 * First section archived: Part 1

Update: Surprisingly, no one has really said we shouldn't move away header cells, so it seems that Wanderer's proposal has been accepted by consensus. What remains to be worked out are styling issues with the new table format. To boil down the above discussion, the two primary style proposals are: I'm assuming everyone's fine with keeping controls on the left, explanatory columns on the right and using a header row, as no one has mentioned changing those aspects. The style would already have been decided, except for a disagreement between the aesthetics of center-aligning controls and the ease of creating the table. Please voice your opinions, thanks. — najzere T 20:34, 17 October 2009 (UTC)
 * 1) Controls column(s) center-aligned (not sure if bolded was wanted as well), explanatory text column(s) left-aligned
 * 2) All columns left-aligned.
 * Since the controls columns are mostly images anyway, I don't think the bolding really matters. Wanderer 00:08, 19 October 2009 (UTC)
 * I agree. I prefer them center-aligned, but could care less about the bolding. It would be nice if we could put together something that would make the wiki code cleaner, though. -- 22:27, 19 October 2009 (UTC)
 * I suppose Skizzerz's idea of making a template and CSS classes for it could work, and it would let us change the styling rules later if we wanted to. But I see no reliable way to apply the different styling rules to the description columns without putting a class attribute on each description cell. Even if the last-child selector were sufficiently well-supported, we'd run into problems with tables that have multiple description columns (example) and possibly ones where the description cells cross rows (example). Maybe a second template could be made for description cells to add the class attribute? Wanderer 03:45, 22 October 2009 (UTC)
 * I wish someone besides myself and Wanderer would opine on whether it's worth the hassle to have center-aligned control images. Speaking as the person who will be fixing all these complicated tables new users attempt to make, it's in my own personal best interest to keep things simple, which, by the way, is a pervasive maxim in nearly ever endeavor existant. — najzere T 06:40, 22 October 2009 (UTC)
 * I still don't think this is an issue. I think the standardization for SW is an issue. I see no value in following "Web standards." No casual reader is going to care what the tables look like or how they are centered as long as they can read it. -- 06:03, 24 October 2009 (UTC)
 * So that's currently two votes for centering (Vizeroth and myself), one vote for left-aligning (Najzere), and one vote for "I don't care" (Notmyhandle). Anybody else? Wanderer 18:06, 24 October 2009 (UTC)
 * I think by changing things we are making things worse. If we have to choose, then I choose left align. Left align requires no formatting, right? -- 18:56, 24 October 2009 (UTC)
 * I think using templates would allow the necessary formatting rules to be applied without that much work on the editor's part. Something like yes or n/a could do the trick. It really wouldn't be as difficult as Najzere seems to make it out to be; a bot could probably do it. Wanderer 19:34, 24 October 2009 (UTC)
 * A bot would help in fixing existing tables, but it won't stop problems with all the future controls tables. No matter which style is decided on, we'll have to spend a lot of time updating all the existing tables, so that's not a concern of mine. From my experience with new users' edits, many of them know how make a standard wiki-table, perhaps from editing Wikipedia or Wikia, or maybe from clicking the "insert a table" icon. Even with our current guideline of making controls header cells and descriptions data cells, we still have to do a lot of cleanup – and that only requires an exclamation mark and putting descriptions on a separate line. Anything more complicated than that will just create more cleanup work and less people will be able to correctly create a standard guide element. Beyond the work to clean up the controls pages, this would also require more talk page discussions as we try to teach our control table methods. I still feel that the costs outweigh the meager benefits (if any). — najzere T 18:13, 28 October 2009 (UTC)

I've created a couple of templates (Controlstable and L) for this purpose and set up a demo to show how this could work (see User:Wanderer/Sandbox). It's very simple, easy to use, and seems to work well. Currently the templates apply the styles inline, but they could be modified to use class attributes instead if we wanted to put the style rules in a style sheet. Wanderer 19:09, 29 October 2009 (UTC)

Update: We need more voices on what control tables will look like. Thanks. — najzere T 07:39, 4 November 2009 (UTC)

Collapsible infobox
Here is a mockup: User:Najzere/Sandbox. It came up in a different discussion that some of the fields in the infobox can become quite long, and collapsing them was mentioned. I've seen this used on Wikipedia, but I can never seem to find a usage of it when I want one. The current WP infobox doesn't seem to have the ability to collapse individual fields, but rather one big parameter to collapse the entire infobox down to the image and title.

If this functionality is deemed useful, I see two ways to incorporate it: either as part of the infobox template or as a separate template of its own, to be used within infobox parameters. The former method would be very complicated in an already complicated template, so I would recommend a separate template to handle this. The title could be decided on once, e.g. "Click link to expand", or it could be left up to the user, if there's a benefit to that.

Another option would be to use WP's whole-infobox collapsing, perhaps even by default, so main pages would just have the title and box art. Some additional parameters that would be good to leave out of collapsing might be the preceded by, followed by and series parameters. Anyway, I'm interested to see what people think of this, as finding a way to shorten lengthy infoboxes would make a lot of guide main pages look cleaner. — najzere T 19:49, 19 October 2009 (UTC)
 * I like the general idea, but I'm somewhat in favour of the WP method. I figure most of the information will be looked at once (if even), and then never again.  I think the most important ones to make unhideable would be expansion packs and series.  After that would be preceded/followed by, but with the series link, I don't think those are that necessary.  -- Prod (Talk) 05:31, 20 October 2009 (UTC)
 * I actually prefer the whole-infobox collapse as well, but didn't think such a radical change would meet with much enthusiasm. Also, as you say, with the series parameter, preceded by and followed by aren't all that necessary as non-hideable fields. — najzere T 07:10, 20 October 2009 (UTC)
 * My only real issue with hiding is that we lose the "many eyes" benefit of the open content. If nobody sees the mistakes, nobody corrects it.  Based on that, I'd say we're probably a bit too early to implement that.  I'm sure we've got more infoboxes <100% accurate than infoboxes that are 100% accurate. -- Prod (Talk) 05:04, 22 October 2009 (UTC)
 * Naj, those are both great alternatives. There's also the issue Prod brought up. Perhaps we should start a SW todo list to keep track of future implementations. I feel that if and when we choose to implement this, this sort of thing should be a part of user preferences, as it affects the standardized view. We're used to large ToC's that are of relatively the same length; for instance when we set up the main page layout standard, ToC length was ignored because we had maybe 1 or 2 super large infoboxes (i.e. it wasn't apparent at the time that we would need to deal with it). -- 05:44, 22 October 2009 (UTC)
 * @Prod: Every edit gets patrolled, so if they haven't been fixed by now, it's going to take a long time (by this I mean years) before a random user comes around who can fix it. In the meantime we're not implementing something which at least the three of us deem useful. Personally, I don't see much benefit to waiting. Having looked at every edit to the wiki for at least the last six months, I don't think I can recall even one infobox fix from a non-admin to an existing guide main page. 'Course, that's not very scientific. :P
 * @NMH: User preference would be ideal, if harder to implement. I'm sure Prod or Skizzerz could come up with a way to do it though.
 * — najzere T 06:40, 22 October 2009 (UTC)
 * If we hide it, that random user will never come along. Patrolling the edits for vandalism is one thing, but correcting minor inaccuracies is quite another. Can you link to an example of this infobox hiding somewhere? -- Prod (Talk) 14:18, 22 October 2009 (UTC)
 * collapsible=yes search string reveals many. For illustration purposes I'd say by leaving infobox open, you'd improve your odds of a random person fixing it from 1/1,000,001 to 1/1,000,000. The only people who change infoboxes are people who contribute to the guide, and if they're interested in checking the main page for accuracy, I don't think a show/hide link is gonna stop 'em. — najzere T 15:24, 22 October 2009 (UTC)
 * That's a good point. Random contributors cannot be relied upon to fix infoboxes. I like the collapsible elements, particularly for multi-line entries such as the Release Dates and System requirements (as Naj simplified in the first example). I don't like the third example as much because a lot of the quickness of the infobox is lost; people browsing the site, even myself, will not be aware of all of the possible data on the page. Collapsing only a select few boxes is useful, as it cuts down on whitespace, but tells people that there is something there. However, I don't think we will have a problem if we implement either form of this; people learn. -- 15:59, 22 October 2009 (UTC)
 * Figured I should mention this, but we're on a wiki, where random contributors are expected to fix everything. -- Prod (Talk)
 * I think that's an overstatement. We should imagine contributors as fellow guide writers, not grammar checking robots. We should be considering contributors as people interested in the games they play, without concern for this site as a whole. Most of the people who come to this site have no idea what we're about, just what we have available. I think Najzere shares my view that editors typically only edit things on the main page if they care about the guide that's on SW. It's like, if a reader comes and views a page for information, the majority of them won't help with the page or the guide as a whole, they will just move on when they have received the information or find that its not sufficient. The others, the ones that edit, are either too shy or whatever to invest in the guide (e.g. the random anonymous spelling fixes) or feel like its worth contributing to. We should be focused on those that find us worth contributing to. These are the people like us who continue to focus our efforts to improving things on a massive scale. By relying on the "random contributors" we are just being lazy. -- 06:00, 24 October 2009 (UTC)

Update: This use on Wikipedia is most often accomplished with collapsible list. It is used on thousands of articles, such as on Sam & Max. For collapsibility in general, the series templates at the bottom of many articles are all collapsible, and many are collapsed by default. For us, while the full infobox collapse might be a bit much, a simpler one like collapsible list might be good and would serve the original intention, which was to shorten overly-long fields. — najzere T 07:39, 4 November 2009 (UTC)
 * Again, I agree that we should start using this for select entries on the infobox. On the topic of collapsible series templates, I think we should enable the ability to do this, but reserve it to large ones like Hokuto no Ken. -- 04:07, 5 November 2009 (UTC)
 * I think our series navs are fine as is, since they're at the bottom out of the way. For Hokuto no Ken, I think there's a different problem, as even if you expanded it from being collapsed, I'm not sure how usable it would be. I had the same problem with Dungeons & Dragons, and I just made as many sub-series as I could to condense it. Someone more knowledgeable (or who wants to spend more time on it) might be able to organize huge series navs like these ones in a meaningful way. Final Fantasy looks good to me and Batman or Naruto: Clash of Ninja might be reasonable ways to split long-lasting series up too. — najzere T 06:00, 5 November 2009 (UTC)

Community Meeting
There will be a community meeting a week from tomorrow. Although it's already going to be a fun filled meeting, please add comments on any other (preferably minor) topics you would like brought up. -- Prod (Talk) 21:49, 30 October 2009 (UTC)
 * Is this replacing November's meeting? — najzere T 21:57, 30 October 2009 (UTC)
 * Good catch, apparently I can't tell the date anymore. -- Prod (Talk) 23:52, 30 October 2009 (UTC)
 * I don't have my forum or IRC passwords at the moment, so I am unable to comment on the thread, nor will I be able to easily verify my identity when I show up on IRC. I am planning on being at this meeting. -- 00:32, 31 October 2009 (UTC)