From StrategyWiki, the video game walkthrough and strategy guide wiki
Jump to: navigation, search
Archive
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 staff lounge page.

November 2009 | December 2009 | January 2010

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:

  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.

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)
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'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)
I think we need an actual consensus on such a large change to the wiki, rather than assuming a default. At this point the issue has gotten such little attention that I don't think there's even support to move away from the current standards at all. — najzereT 20:57, 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)

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)

Wikimedia Commons has a feature to assist in adding multiple categories, and I believe it uses the CategoryTree extension. From what I can see, CategoryTree just allows you to navigate categories and sub-categories, but with some scripting it would be possible to allow adding categories to an upload by finding them in the category search. That still leaves the guide-specific category, but this extension could be used also to find a guide name through Category:Games (provided it exists). — najzereT 22:55, 16 December 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)
Postponed to January 9th due to not enough people joining. -- Prod (Talk) 19:18, 5 December 2009 (UTC)

mw:Extension:InputBox

Input Boxes would be very beneficial to the wiki, and could serve a plethora of uses. For example, I recently made a Pokemon Page Creator, but at its present stage it would be very difficult to use for others. To add to that, you have to subst the template onto the page, which creates a lot of template fluff that editors would have to wade through, or remove. With the Input Boxes, I would be able to change the template call into preloaded text. Then I could simply type, for example, Rock Tunnel into the input box and it would open Pokémon FireRed and LeafGreen/Rock Tunnel with all the repetitive tables preloaded, minus template fluff. Page creators could be made for any guide, or even a generic one for the whole wiki.

Input boxes can also be used for searching specific pages, or groups of pages, for example if one wanted to find a specific quote from 2007, you could search that archive for the quote, instead of the entire wiki. Drew R. Smith 03:58, 9 December 2009 (UTC)

This looks pretty cool. I think there are some definite benefits to it, although we'd have to find a way to maintain control over it. Preloading a user-defined page seems like the most useful function, as we often come across pages in guides that need to be set up the same way. Much like we use templates to provide an easy, uniform way to present certain information in a guide, a preload page or two for a guide could come in very handy, especially in huge guides like MapleStory where all the item pages, for instance, are all set up the same. That being said, I don't want to see these on the main pages of guides, so maybe they could be "hidden" away on the talk page? Anyway, I'm for adding the extension, at least temporarily to see how we like it. — najzereT 18:43, 9 December 2009 (UTC)
No, they wouldn't be on the main page of the guide. Putting them on the talkpage of the guide would be one solution, and may end up being the best solution. Another solution would be to hide it away in a template, or even on a dedicated SW namespace page.
While I'm on that subject, are there dedicated pages for game specific manual of styles? If not, it may be something to look into. Drew R. Smith 21:31, 9 December 2009 (UTC)
The guide's main talk page is where guide-specific styles would be outlined. Most of the time someone just starts making a guide and everyone follows suit with however the first page is laid out unless there's an issue with it. Guide-specific templates are also used to enforce a certain style across guide pages. — najzereT 21:35, 9 December 2009 (UTC)

Smileys 2

As I've been editing more over at WP I stumbled across wp:Template:=) (on some talk pages), and I recalled that there was some apprehension last time this was brought up that smileys might be pointless or informal, so I thought I'd update you all in case this changes anyone's mind. Cheers, — najzereT 21:35, 18 December 2009 (UTC)

I still think the number of people that would bother typing out the template instead of a simple :P or :D or whatnot are limited, and thus still think this is a stupid idea. --Skizzerz 22:20, 20 December 2009 (UTC)

Categories and templates

We touched on this briefly in another discussion a couple months ago, and recently it's come up on my talk page. The issue is that certain pages are being mis-categorized because some of the templates we use to display information also automatically insert categories. This is normally associated with redirects, as we want the reader to see the information on one page and have the redirected page's name show up in categories. A simple example is a game that was re-released a year later under a different name for a different system. The new game would get redirected to the original, but if we tried to use {{sys}} for the new system or {{rd}} for the new release date, the original game would be erroneously categorized. Clearly then, it is sometimes appropriate to use our main page templates simply for information purposes without also categorizing.

The easiest way to handle it would be to include some sort of flag in the templates to let them know not to insert the category. I think this could be done fairly simply for all the main page templates that do that: {{sys}}, {{co}}, and {{rd}} and its children. Since I was thinking about the {{sys}} template, I also thought it might be nice to do something about times where we have to stack the templates in the infobox. {{super sys}} uses a fairly simple markup to stop categorization – piping off "nocat" after any system suppresses the category. It also accepts up to ten uncategorized systems (or 20 categorized ones), so it should take care of any template stacking except in very extreme cases (and then extra parameters can be easily added). The code could replace what's in {{sys}} right now without breaking anything on the site as well.

So this is a proposal to incorporate category suppression flags into the main page templates and, if that is accepted, a sub-proposal to move {{super sys}} to {{sys}}. — najzereT 22:50, 22 December 2009 (UTC)