Archives
Welcome to all users! This page is where you 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 the community issues forum 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 (e.g. 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:
- Place your question at the bottom of the list.
- Title the question (by placing the title between equals signs: ==Title==).
- Sign your name and date (by adding 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:
- Controls column(s) center-aligned (not sure if bolded was wanted as well), explanatory text column(s) left-aligned
- All columns left-aligned.
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. — najzereT 20:34, 17 October 2009 (UTC)
- 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. --~Vizeroth · (c)~-- 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. — najzereT 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. --Notmyhandle (talk • contribs) 06:03, 24 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. — najzereT 06:40, 22 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 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. --~Vizeroth · (c)~-- 22:27, 19 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? --Notmyhandle (talk • contribs) 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). — najzereT 18:13, 28 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)
- 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? --Notmyhandle (talk • contribs) 18:56, 24 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. — najzereT 07:39, 4 November 2009 (UTC)
- I guess nobody else has anything to say about this. The "center vs. left" vote tied, so since the guidelines already support centering and that's currently the common practice anyway, why don't we just go with that (or leave it up to individual preference?). Those templates I made should make it easy enough. Wanderer 01:31, 29 November 2009 (UTC)
Collapsible infobox
Here is a mockup: User:Najzere/Sandbox#collapsible infobox. 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. — najzereT 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. — najzereT 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). --Notmyhandle (talk • contribs) 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.
- — najzereT 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. — najzereT 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. --Notmyhandle (talk • contribs) 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. --Notmyhandle (talk • contribs) 06:00, 24 October 2009 (UTC)
- Figured I should mention this, but we're on a wiki, where random contributors are expected to fix everything. -- Prod (Talk)
- 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. --Notmyhandle (talk • contribs) 15:59, 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. — najzereT 15:24, 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)
- 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). --Notmyhandle (talk • contribs) 05:44, 22 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)
- 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. — najzereT 07:10, 20 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. — najzereT 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}}. --Notmyhandle (talk • contribs) 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. — najzereT 06:00, 5 November 2009 (UTC)
Update: I imported that collapsible list template from Wikipedia, as it might come in handy elsewhere besides just the infobox. The sandbox example has been updated to use it. It's pretty easy to use, just wrap any existing content with the template (only needs the first parameter) and add a title parameter and you're all set. The default settings seem to look good in the infobox as it is, and custom ones could easily be #switch'd out if there's ever some other place we want to use this a lot. — najzereT 21:10, 17 November 2009 (UTC)
- I'm not a fan of using the table within the infobox like that as it's somewhat restrictive how it works. I have an idea on how to improve on this, but it will take me a little while to implement it. -- Prod (Talk) 05:59, 29 November 2009 (UTC)
- The {{collapsible list}} template doesn't use a table, it's a simple list of parameters separated by {{-}} within a navframe. If you mean you don't like to use separate fields for each list item, you could put everything into the first parameter as far as the template is concerned, and you could use the exact same markup as we currently do for infoboxes (e.g. {{us|2009|October 1}}{{eu|2009|...). Instead of waiting "a little while" for you to implement it, why don't you tell us what you're thinking so we can help. — najzereT 20:57, 29 November 2009 (UTC)
classmates ad
Carried over from here. It's the full-screen classmates.com ad as reported by myself and Dukeruckley. New User (talk) 21:52, 24 November 2009 (UTC)
- These should now be gone. Let us know if you see them again. -- Prod (Talk) 00:28, 25 November 2009 (UTC)
- I just encountered it again about one minute ago. New User (talk) 17:54, 27 November 2009 (UTC)
- Here's a screenshot of another ad I've been encountering the past two days. New User (talk) 00:56, 29 November 2009 (UTC)
- I have yet to see a full screen ad with FF 3.5.5. The worst I've encountered were the military (Modern Warfare 2?) and Assassin's Creed 2 flash pop-out ads. --Notmyhandle (talk • contribs) 06:51, 29 November 2009 (UTC)
mw:Extension:CategoryOnUpload
How about adding it? As of now Special:Upload consists of adding categories manually to the summary field. That extension will make the task much easier. --Arseny1992 (talk · contribs) 10:17, 28 November 2009 (UTC)
- Looks useful. I like it better than the auto-fill feature of Wikia. We could use more user friendly stuff like this. Usefulness is debatable, but may cut down on misspelled cats. I can see Category:Images being placed incorrectly. Luckily we can restrict which categories can be picked from. Nice. Unfortunately, we probably won't include game-specific image cats in there (so many...). --Notmyhandle (talk • contribs) 00:28, 29 November 2009 (UTC)
- Unfortunately it looks like it only inserts one dropdown field, which might give the impression that images only require one category. I wish there was a way to make categorizing images easier, but this doesn't look robust enough to handle the way we do things. — najzereT 20:57, 29 November 2009 (UTC)
Community Meeting
Today's the day that wiki editors have their picnic. Details at http://abxy.org/forums/viewtopic.php?f=20&t=27061. Unlike previous meetings where we had an open session at the end, only topics that are mentioned in the forum thread and approved for inclusion in the meeting will be discussed. -- Prod (Talk) 09:54, 5 December 2009 (UTC)
- Meeting starts in 10 minutes. -- Prod (Talk) 18:49, 5 December 2009 (UTC)
- Meeting starts 10 minutes ago. --69.165.156.217 19:12, 5 December 2009 (UTC)