[2:10:25p 2/6/10] !logon [2:12:02p 2/6/10] Welcome to the february community meeting [2:12:21p 2/6/10] we've got only a few people here today, so we'll have a fairly limited meeting [2:12:39p 2/6/10] so first thing we'll go over is the control table style [2:12:45p 2/6/10] this will be simply a discussion [2:12:54p 2/6/10] any decisions will be postponed till next meeting [2:13:18p 2/6/10] The current discussion is held at http://abxy.org/forums/viewtopic.php?f=20&t=26771 [2:13:36p 2/6/10] the way I see it [2:13:38p 2/6/10] there are now two options [2:13:44p 2/6/10] one is to stick with what we have [2:14:06p 2/6/10] the other is to go with {{prettytable|text-center=true}} (or whatever the markup is [2:14:14p 2/6/10] and then use |align=left for the description cells [2:14:35p 2/6/10] so my main question is why bother? [2:14:49p 2/6/10] Web standards. [2:15:18p 2/6/10] the "standards" don't exactly relate to this (they're a few layers of discussion in) [2:15:33p 2/6/10] i think the main point is to look at the reasoning behind the standard [2:15:38p 2/6/10] and see how it benefits us [2:15:55p 2/6/10] While the current method may not break your browsers, we can't guarantee it won't break someone else's. [2:16:11p 2/6/10] how so? [2:16:15p 2/6/10] tables are tables [2:16:24p 2/6/10] Personally, I think SW's top priority should be the simplicity of editing to the user... [2:16:27p 2/6/10] there isn't going to be a significant change in the forseeable future that will damage them [2:16:33p 2/6/10] These days there's like a zillion different applications using the web behaving in different ways. [2:16:58p 2/6/10] Text-to-speech readers, mobile browsers, and other god-knows what. [2:18:01p 2/6/10] Without following web standards, we may get undesired results in apps we didn't account for. [2:18:26p 2/6/10] Can't we bake the alignment stuff into a template? [2:18:38p 2/6/10] barely saves any trouble [2:18:42p 2/6/10] A test run did; used {{l|description}}. [2:18:42p 2/6/10] Of course, I already did. [2:18:59p 2/6/10] and just adds another layer of markup to learn [2:19:19p 2/6/10] Well, [2:19:24p 2/6/10] the stuff that would already be used isn't that complicated that the template would be necessary [2:19:25p 2/6/10] if it's not a straightforward problem, [2:19:33p 2/6/10] it won't have a straightforward solution. [2:19:34p 2/6/10] The current system uses headers at the top, and the control buttons on the left. [2:20:24p 2/6/10] It "works" for now, but if you remove the header tag on these buttons, they'll be left aligned. [2:20:48p 2/6/10] That can be corrected if you can apply a style to a given column - which isn't possible under MediaWiki markup or the current version of HTML. [2:21:10p 2/6/10] (Actually, it works in HTML, but not for all styles.) [2:21:10p 2/6/10] right [2:21:10p 2/6/10] it would solve all our problems if it was :) [2:21:46p 2/6/10] Well, [2:22:02p 2/6/10] What is the primary drawback of the current situation? [2:22:11p 2/6/10] Is it simply non-standardization? [2:22:31p 2/6/10] At worst, it looks like there's headers on the top, and ~3 header columns on the left. [2:23:05p 2/6/10] It's technically valid as a 2D-table thing, but abusing the definition of the header. [2:23:20p 2/6/10] Is there a good example of this? [2:23:31p 2/6/10] any controls page :) [2:23:44p 2/6/10] lemme take a look [2:23:51p 2/6/10] Well pick http://strategywiki.org/wiki/Dark_Messiah_of_Might_and_Magic/Controls as an example. [2:23:56p 2/6/10] Right, we're treating data as headers, not separating content from presentation. [2:24:09p 2/6/10] content from presentation is separating css from html [2:24:17p 2/6/10] i don't think it has so much to do with intent [2:24:22p 2/6/10] That one seems to do it correctly, does it not? [2:24:40p 2/6/10] It does it the current way we do it. [2:24:47p 2/6/10] http://strategywiki.org/wiki/User:Wanderer/Sandbox [2:24:49p 2/6/10] that's the proposal [2:25:26p 2/6/10] 12(Wanderer12): btw, i'm not a fan of the rowspans [2:25:39p 2/6/10] i don't think there's really a rule for "a button can only show up in one row" [2:25:56p 2/6/10] though that's debatable [2:25:58p 2/6/10] And the distinction there is that Wanderer's does not use headers to center the controls? [2:26:09p 2/6/10] It's more of a question if "WASD"/L-Stick is a header for something like Move... [2:26:30p 2/6/10] Right. It uses CSS for centering, like it should be. [2:26:47p 2/6/10] so what if we did this [2:26:57p 2/6/10] we label the description column as a header row [2:27:06p 2/6/10] and the controls columns as td [2:27:14p 2/6/10] and use a custom controls class in the header? [2:27:23p 2/6/10] would that satisfy the "separation" reasoning? [2:27:55p 2/6/10] Doesn't that just reverse the problem? [2:28:04p 2/6/10] not really [2:28:08p 2/6/10] The only "headers" are at the top. [2:28:15p 2/6/10] i would consider the descriptions as headers [2:28:21p 2/6/10] row headers [2:28:31p 2/6/10] I think Wanderer is right... [2:28:41p 2/6/10] That doesn't sound like a good idea... [2:28:56p 2/6/10] The descriptions and the controls all sound like data to me. [2:28:56p 2/6/10] it's a thought experiment [2:28:59p 2/6/10] not a suggestion ;) [2:29:20p 2/6/10] then that gets into an issue of personal opinion [2:29:48p 2/6/10] Yeah, but I agree with Wanderer's position . [2:29:48p 2/6/10] the description is what happens, and the cotnrols are how to cause it [2:30:08p 2/6/10] Wouldn't it make more sense if we came up with a centered-image template? [2:30:23p 2/6/10] it looses the simplicity [2:30:30p 2/6/10] Cuz I run into this problem a lot on other guides. [2:30:52p 2/6/10] it would have to be a table cell style centering [2:30:53p 2/6/10] We typically have multiple images and one description per row. [2:31:00p 2/6/10] Where I would like the images to be centered in a cell. [2:31:00p 2/6/10] it wouldn't be very applicable otherwise [2:32:08p 2/6/10] It'd be easier to apply any special markup to the description cells. [2:32:53p 2/6/10] hmm... -- Rocky has joined in the meeting. [2:33:41p 2/6/10] Well, is there any chance we will come to a consensus on this topic today? [2:33:52p 2/6/10] no [2:33:58p 2/6/10] We'd have to do a survey for it. [2:34:03p 2/6/10] ok [2:34:07p 2/6/10] survey's are lame [2:34:11p 2/6/10] Exactly. [2:34:20p 2/6/10] :( [2:34:50p 2/6/10] i still don't see the appeal of going to a more compilcated method [2:35:07p 2/6/10] It's not that much more complicated. [2:35:11p 2/6/10] At best, we could hope that other devices see it in the style of a multiplication table, but there's something that doesn't feel right about the different coloured background. [2:35:29p 2/6/10] 12(Sigma712): i actually like the different colours :) [2:35:30p 2/6/10] I agree with that. [2:35:35p 2/6/10] it shows that they're different kinds of data [2:35:37p 2/6/10] Really? [2:35:39p 2/6/10] And it's something I'd like to see addressed in the main MediaWiki/HTML markup. [2:35:59p 2/6/10] I dunno, maybe the color selection is simply TOO different. [2:36:14p 2/6/10] Maybe same background, different color text would be better. [2:36:22p 2/6/10] The current proposal is too distracting. [2:36:31p 2/6/10] If we want different background colors, that too can be implemented in the templates using CSS. [2:36:43p 2/6/10] that's cool. [2:36:45p 2/6/10] 12(Wanderer12): yes, but it still makes the markup more complicated [2:37:03p 2/6/10] Huh? If it's in the CSS, how would it get more complicated? [2:37:14p 2/6/10] cause you need to add classes to the cells [2:37:19p 2/6/10] or the whole table [2:37:23p 2/6/10] and then some of the cellls [2:37:24p 2/6/10] We should be able to bake all of those controls into a template, and obscure them from the average editor. [2:37:39p 2/6/10] impossible without column styles [2:37:45p 2/6/10] At some point, you have to trade simplicity for customization. [2:37:55p 2/6/10] Otherwise, you have the exact problem we have today. [2:38:02p 2/6/10] and simplicity allows greater customization per guide [2:38:10p 2/6/10] adding in templates restricts stuff [2:38:15p 2/6/10] With the templates, if we wanted to change the colors later, we need only rewrite the CSS in the templates. [2:38:29p 2/6/10] that's technically putting the css inline ;) [2:38:36p 2/6/10] True, but once one of us, or Naj, comes along and fixes it up, then all people have to do is follow the design to add to it. [2:38:46p 2/6/10] that's just relying on things to be cleaned up [2:38:57p 2/6/10] Yeah, but we do that all over the site. [2:39:16p 2/6/10] we should be helping users write guides, not cleaning up after everyone [2:39:17p 2/6/10] Not that that's a good thing, but still... [2:39:33p 2/6/10] Anyway, we're 40 minutes into the meeting, and we're bogged down in something we know we can't fix right now. [2:39:43p 2/6/10] heh [2:39:46p 2/6/10] well, we got some discussion in [2:39:49p 2/6/10] We should identify an action item for this topic, and move on. [2:39:59p 2/6/10] we will leave this further for the next meeting [2:40:10p 2/6/10] So no action item at all? [2:40:10p 2/6/10] people can bake on what's been discussed so far [2:40:13p 2/6/10] nope [2:40:30p 2/6/10] :( ok... [2:40:41p 2/6/10] well, then moving on to the next topic, [2:40:46p 2/6/10] which we were discussing earlier, [2:40:46p 2/6/10] next topic is from last march :) [2:40:51p 2/6/10] which is the 300x250 ads [2:40:54p 2/6/10] Moved it here: http://www.mediawiki.org/wiki/Project:Support_desk/Sections/Formatting#Applying_formatting_to_columns [2:41:13p 2/6/10] 12(Sigma712): please make a note in the thread :) [2:41:18p 2/6/10] The 300x250 ads look have this shape: http://imgur.com/E6NFA [2:41:27p 2/6/10] If the window is 1024x768: http://imgur.com/fPdXL [2:42:13p 2/6/10] If we were to implement those, [2:42:25p 2/6/10] It may be possible to place it automatically after the first header, floated left or right. [2:42:32p 2/6/10] I'd recommend a hint for that, though. [2:42:33p 2/6/10] we would have to have some predefined area for them, like in the header of the site. [2:42:36p 2/6/10] i think that's nasty :P [2:42:56p 2/6/10] i personally think there is no elegant way to integrate them into the current skin [2:43:01p 2/6/10] maybe on the front page [2:43:06p 2/6/10] Unless you move the Toolbox to the left. [2:43:13p 2/6/10] In considering these ads, I'm thinking primarily with respect to the SW 2.0 site redesign that Teddy is supposedly working on. [2:43:14p 2/6/10] even then, it's too wide [2:43:58p 2/6/10] Only for 800x600, but I'm not sure that's a popular resolution anymore. [2:44:10p 2/6/10] 1024x768 is the most popular [2:44:11p 2/6/10] I personally don't see how we can properly incorporate them into the current site design. [2:44:29p 2/6/10] putting ads into the content doesn't seem useful [2:44:31p 2/6/10] Not to mention how much reworking of existing guides we'd have to do if we DID incorporate them. [2:44:35p 2/6/10] and just gets in the way of the guide content [2:45:06p 2/6/10] Per Steam, 1280x1024 is the most popular, followed by 1680x1050, 1024x768, then 1440x900 [2:45:19p 2/6/10] Other (which would include 800x600, is only 3.21%. [2:45:28p 2/6/10] per our website [2:45:32p 2/6/10] I mean, the bottom line, is there are certain things the wiki layout can accommodate, and there are things which it can't. [2:45:33p 2/6/10] 1280x800 = 20% [2:45:38p 2/6/10] 1024x768 =20% [2:45:43p 2/6/10] 1280x1024 =20% [2:45:49p 2/6/10] er [2:45:52p 2/6/10] 12% [2:45:56p 2/6/10] for that last one [2:46:02p 2/6/10] What about 1360x768? [2:46:08p 2/6/10] 1440x900 =10% [2:46:30p 2/6/10] 1366x768 =6.5% [2:46:40p 2/6/10] I see [2:47:01p 2/6/10] Well, physical resolution aside, [2:47:15p 2/6/10] I simply don't see how we can successfully incorporate them into our existing layout. [2:47:22p 2/6/10] Even if we _wanted_ to. [2:47:30p 2/6/10] i say we can't except on the front page [2:47:31p 2/6/10] Which is a whole other discussion entirely. [2:47:45p 2/6/10] Yeah, that's true, I could see them on the front page possibly. [2:48:07p 2/6/10] But I still remember the headache we went through rearranging it the last time >_< [2:48:16p 2/6/10] :D [2:48:27p 2/6/10] that was a major reorganization [2:48:29p 2/6/10] this would be minor [2:48:42p 2/6/10] but do others agree with that? [2:48:46p 2/6/10] minor would be dropping it on the bottom, below the fold, where no one would see it. [2:48:50p 2/6/10] It could be autodetected... Between headers, if there's no floating element, it can float to the right. If there is, it floats on the opposite side. [2:48:50p 2/6/10] can we drop this in all cases except main page? -- Garrett has joined in the meeting. [2:49:13p 2/6/10] I think that's a safe call. [2:49:16p 2/6/10] Hey Garrett' [2:49:49p 2/6/10] Sigma: What exactly could be autodetected? [2:49:52p 2/6/10] 12(Sigma712): i don't think it's worth the effort [2:50:19p 2/6/10] I'd agree, especially since there's less width than other Wikis. [2:50:40p 2/6/10] Unless you simply tack it on after the end of article content. [2:50:46p 2/6/10] and the income we get off the current ads supports the site well enough that we don't need to start worrying too much yet [2:50:50p 2/6/10] Which isn't that useful. [2:50:57p 2/6/10] true [2:51:01p 2/6/10] 12(Sigma712): and ugly : [2:51:40p 2/6/10] as for the front page, we can leave it as an option if we ever feel the need to balance any other changes [2:51:48p 2/6/10] true [2:51:51p 2/6/10] but i'm going to suggest we just drop the square ads until we need them [2:51:54p 2/6/10] I like that idea. [2:52:29p 2/6/10] OK, then unless there's any other thoughts on the topic, let's jump to title disambigs. [2:52:40p 2/6/10] anyone disagreew ith that proposal? [2:52:53p 2/6/10] everyone agree? [2:53:35p 2/6/10] ok [2:53:38p 2/6/10] then next topic [2:53:45p 2/6/10] title disambiguation [2:53:52p 2/6/10] http://abxy.org/forums/viewtopic.php?f=20&t=267923 [2:53:55p 2/6/10] http://abxy.org/forums/viewtopic.php?f=20&t=26792 [2:54:53p 2/6/10] i'm saying we just drop the title disambig [2:54:59p 2/6/10] The thing about Melon's suggestion is, while it's a nice idea, it doesn't help at all when it comes to site navigation. [2:55:00p 2/6/10] no real use [2:55:02p 2/6/10] "Title (a.k.a. Title2)" works fine; the template is only required if a game has too many names. [2:55:17p 2/6/10] You _still_ have to make categorized redirect pages. [2:55:18p 2/6/10] in which case it can usually be redirected to a category [2:55:54p 2/6/10] I just had to do that for Starship Hector and Hector '87 [2:57:10p 2/6/10] so anyone want to discuss this further, or can we all agree to drop the template (or not bother creating it)? [2:57:13p 2/6/10] Alternate names (such as Gryzor and Probotector) get redirected to the main game name (Contra) without issue. [2:57:28p 2/6/10] As far as I know, the template isn't required under most cases. [2:57:37p 2/6/10] What I tend to do is just put both names in the infobox, like so: http://strategywiki.org/wiki/Hector_%2787 [2:58:02p 2/6/10] actually you should just pick one name [2:58:06p 2/6/10] and list it in the intro paragraph [2:58:07p 2/6/10] Or: http://strategywiki.org/wiki/Dragon_Slayer_IV_Drasle_Family [2:58:17p 2/6/10] Why? They're both applicable. [2:58:29p 2/6/10] http://strategywiki.org/wiki/Hitman_Triple_Pack [2:58:35p 2/6/10] something like that [2:59:09p 2/6/10] describe why it is referred to in more than one way [2:59:10p 2/6/10] Waaaaaait... [2:59:13p 2/6/10] but leave the infobox with one name [2:59:31p 2/6/10] If Hitman Trilogy came out 2 days before HTP, why isn't the page called Hitman Trilogy? [2:59:50p 2/6/10] and then I tend to remove your double infobox naming, so... >_> [3:00:01p 2/6/10] Oh... :( [3:00:04p 2/6/10] specific case is irrelevant :P [3:00:12p 2/6/10] Well, [3:00:14p 2/6/10] i couldn't think of another example at the moment [3:00:15p 2/6/10] I dunno... [3:00:33p 2/6/10] http://strategywiki.org/wiki/Mother_2 [3:00:37p 2/6/10] If nobody likes my approach, I'll stop doing it. [3:00:50p 2/6/10] i don't think it's as clear [3:01:39p 2/6/10] I'm not certain what's unclear about it though :o [3:01:46p 2/6/10] People know that some games have more than one name. [3:01:56p 2/6/10] It shouldn't come as a big surprise to people. [3:02:02p 2/6/10] but it doesn't go into why it has more than one name [3:02:18p 2/6/10] localization is usually the reason 99% of the time. [3:02:37p 2/6/10] but the infobox doesn't say that [3:02:40p 2/6/10] And the explination is typically provided in the introduction. [3:02:43p 2/6/10] ok [3:02:58p 2/6/10] the standard has been to only refer to the game by its most recognised name--i.e. the one chosen for the page title. [3:03:05p 2/6/10] It's not a big deal to me, I'll stop doubling up. it just felt like an elegant solution to me. [3:03:06p 2/6/10] so, can we drop any further title disambig templatification? [3:03:30p 2/6/10] if you agree please say so.... [3:03:33p 2/6/10] Er... wait [3:03:49p 2/6/10] I though the standard has always been to refer to the game by the first name it was published as. [3:03:57p 2/6/10] Otherwise, Green Beret should be Rush'N Attack. [3:04:08p 2/6/10] right, but that's a separate discussion [3:04:14p 2/6/10] But it came out as Green Beret first. [3:04:33p 2/6/10] Yeah, but Garrett said something different, so I wanted to clarify. [3:04:56p 2/6/10] we go with the ENGLISH name (if no English name, than whatever's closest). [3:04:59p 2/6/10] Technically, the Dragon Slayer IV guide could have been called the Legacy of the Wizard guide. [3:05:09p 2/6/10] :/ [3:05:11p 2/6/10] case in point: A Link to the Past vs Kamigami no Triforce [3:05:15p 2/6/10] infobox header has a proper name as compared to what is put in sw title string [3:05:24p 2/6/10] lets not get back into the full naming discussion here [3:05:29p 2/6/10] ugh... [3:05:34p 2/6/10] Prod: on the topic itself, I don't think the title disambig template as proposed is necessary. [3:05:41p 2/6/10] I agree [3:05:48p 2/6/10] other sagree? [3:05:57p 2/6/10] Sigma7, Rocky, Wanderer? [3:06:07p 2/6/10] ashley? [3:06:33p 2/6/10] Template isn't required, and there's already an acceptable alternative. [3:06:49p 2/6/10] Plus, the alternate titles are bolded anyway, making them visible. [3:06:57p 2/6/10] so, you agree? [3:07:03p 2/6/10] sure [3:07:16p 2/6/10] ok, no one against? [3:07:26p 2/6/10] great [3:07:34p 2/6/10] so the last topic for today is rating categories [3:07:42p 2/6/10] this will be purely a discussion [3:07:46p 2/6/10] as opposed ot a decision [3:07:48p 2/6/10] as in for ESRB and such? [3:07:50p 2/6/10] http://abxy.org/forums/viewtopic.php?f=20&t=26798 [3:07:51p 2/6/10] yes [3:08:12p 2/6/10] i believe the two options are these: [3:08:12p 2/6/10] http://abxy.org/forums/viewtopic.php?f=20&t=26798#p415437 [3:08:41p 2/6/10] how useful would this actually be though? [3:08:44p 2/6/10] implementation is fairly easy [3:08:45p 2/6/10] I'm all for it, don't see any reason why not. [3:08:51p 2/6/10] the question is exactly as garrett stated [3:09:00p 2/6/10] It may be useful to see which games are suitable for children... [3:09:11p 2/6/10] and the names i mentioned in that post would have to be modified to say they're ratings categories [3:09:14p 2/6/10] can't be that simple a name :) [3:09:48p 2/6/10] 12(Sigma712): i think it'll get too overpopulated for that [3:09:51p 2/6/10] with games that are really old [3:10:02p 2/6/10] What you really need to answer this question, is how popular ARE category pages? [3:10:08p 2/6/10] How often are they used to find content. [3:10:39p 2/6/10] series and company pages i find quite useful [3:11:22p 2/6/10] I agree with that. [3:11:44p 2/6/10] On my personal wiki, I use categories, but haven't visited them recently. [3:11:48p 2/6/10] but category pages overall account for less than 1% of our traffic [3:12:17p 2/6/10] 0.9% actually [3:12:25p 2/6/10] Their main benefit is from keeping track of games released by a given company or in a given series. [3:12:45p 2/6/10] finding games of a certain ratings category doesn't seem that sueful to me [3:12:46p 2/6/10] And for organizing completion stages of guides. [3:12:49p 2/6/10] but it's easy to implement [3:13:24p 2/6/10] unless people disagree with those two statements, i'd like to leave this discussion to continue at the next meeting [3:13:34p 2/6/10] Is there an upper limit to the number of categories on a page? [3:13:46p 2/6/10] 12(Sigma712): the amount people can easly look through :) [3:14:06p 2/6/10] the fewer more specific they are, the better [3:14:18p 2/6/10] lol [3:14:30p 2/6/10] more specific/useful [3:14:48p 2/6/10] So far, [3:14:49p 2/6/10] ok [3:15:08p 2/6/10] we put Games, Date, Publisher/Developer, genre, systems, and #players [3:15:22p 2/6/10] (and the players one seems the most useless of all to me...) [3:15:31p 2/6/10] i like coop games :) [3:15:41p 2/6/10] I'm also not fond of the date/month category [3:15:47p 2/6/10] Co-op may be the only useful category in the player quantity set. [3:15:59p 2/6/10] and justifies the rest :P [3:16:07p 2/6/10] I like'em too, but how often do you look at [[Category:Single player]]? [3:16:23p 2/6/10] Or Cat:Multi [3:16:24p 2/6/10] For that matter, it would be more useful to have a category of "not single player". [3:16:44p 2/6/10] Oh well. [3:16:45p 2/6/10] Cat:MMO for that... [3:16:56p 2/6/10] OK, I think we covered a good bit of stuff. [3:17:07p 2/6/10] For next month, I will make it a point to personally invite people to show up. [3:17:28p 2/6/10] But thank you Garrett, Sigma7, Wanderer, Rocky, and ashley for doing so. [3:17:36p 2/6/10] It's greatly appreciated, as always. [3:17:47p 2/6/10] Anything urgent on anyone's minds before we close? [3:18:05p 2/6/10] OK, I guess not. [3:18:08p 2/6/10] please post suggestions for the next meeting when the next announcement appears [3:18:15p 2/6/10] Thanks again guys, talk to you soon.