| Latest revision |
Your text |
| Line 717: |
Line 717: |
| :::::It's definitely fixed now, as I've turned it back into a singular table (but with the squishability included). I've moved the ghost data out and rearranged the remainder of the table to make the best use of space, how does it look now? [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:05, July 5, 2024 (EDT) | | :::::It's definitely fixed now, as I've turned it back into a singular table (but with the squishability included). I've moved the ghost data out and rearranged the remainder of the table to make the best use of space, how does it look now? [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 00:05, July 5, 2024 (EDT) |
| :::::OK, I have ensured every one of this type of table I have made during this project can appear with its entire width on the screen on any screen size, and have split the staff ghost information to new tables again with the added icons. (As a bonus, for Wii, the banners appear as the largest icon on phone size, which is neat lol.) At this point, I see no possible benefits of the horizontal-based course listings for anyone these unless they ''really'' like omegasquished images on thinner screens and large amounts of whitespace on wider screens, which is generally considered poor design. (Granted, the other type looks ''mildly OK'' on tablet resolution, though the columns are still so inconsistently sized it drives me crazy. Mine looks good -in my opinion- at PC (two columns, full size), tablet (one column, full size), or phone size (one column, slightly shrunk).) Granted, mine would be thinner if whoever uploaded the course previews hadn't gone with widescreen; the idea is they're tall enough to go alongside the maps at their size. I guess I can shrink the screenshots a bit further, leaving some whitespace above and beneath while making them an easier fit for smaller PC screens, if need be. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:48, July 5, 2024 (EDT) | | :::::OK, I have ensured every one of this type of table I have made during this project can appear with its entire width on the screen on any screen size, and have split the staff ghost information to new tables again with the added icons. (As a bonus, for Wii, the banners appear as the largest icon on phone size, which is neat lol.) At this point, I see no possible benefits of the horizontal-based course listings for anyone these unless they ''really'' like omegasquished images on thinner screens and large amounts of whitespace on wider screens, which is generally considered poor design. (Granted, the other type looks ''mildly OK'' on tablet resolution, though the columns are still so inconsistently sized it drives me crazy. Mine looks good -in my opinion- at PC (two columns, full size), tablet (one column, full size), or phone size (one column, slightly shrunk).) Granted, mine would be thinner if whoever uploaded the course previews hadn't gone with widescreen; the idea is they're tall enough to go alongside the maps at their size. I guess I can shrink the screenshots a bit further, leaving some whitespace above and beneath while making them an easier fit for smaller PC screens, if need be. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:48, July 5, 2024 (EDT) |
|
| |
| This isn't course-related but the vehicle section I also think should use improvement. The models themselves are a bit too large but my biggest issue is the bar graphs for the stats, they contrast very poorly with the white background and while they do take inspiration from the in-game aesthetics, those are meant to go with a darker background. I also think we don't need a black border around them, it makes it look too busy. Plus, I think bikes and karts should be grouped together since that is also how the game splits them too, especially according to cc where the vehicle type is restricted. {{User:Ray Trace/sig}} 11:45, July 24, 2024 (EDT)
| |
| :I'll admit, I was very unsure of how to order the vehicles, I just decided to go with how our gallery page orders them. Personally, I kinda like them big enough to see the polygons, but obviously that's just my preference and I can shrink them just fine if it's deemed over-the-top (and it probably is, especially for the small vehicles). As for the bars, the outlines are mainly to tell where the "yes" part ends and the "no" part begins if that makes sense, while the outline around the while part is mainly for ensuring consistent size. That all said, I made the bars be a template ({{tem|Bar meter}}), so they can be edited all at once through that if need be (and I was thinking about adding a color parameter for the "yes" part as well). I just wanted to not use the bar graphs seen on the vehicle pages, because personally I find the colors they use kinda ugly. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:31, July 24, 2024 (EDT)
| |
|
| |
| ==Decide how to present courses==
| |
| {{Settled TPP}}
| |
| {{proposal outcome|passed|2-1-19-4|revert to original design}}
| |
| About a month ago, I started overhauling the course tables after discussions with several community members who were unhappy with their current state. I only completed the new courses before getting pushback, so I left it alone in the hopes that discussion would give a general consensus on what we should go with. As far as I can tell, no consensus has emerged and that discussion has stalled for several weeks. In the meantime, the course listing is split in half between two designs which isn't ideal, especially for a featured article. I think it's about time we just go to a proposal and pick one.
| |
|
| |
| For simplicity, I'm going to refer to these as the "'''[https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4307169#Wii_Grand_Prix Nitro option]'''" (my design) and the "'''[https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4308233#Retro_Grand_Prix Retro option]'''" (Doc's design) (link updated to reflect changes during proposal) based on the current split. I've also seen several users say that they would prefer [https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4277027#Courses reverting back to the original tables from before any changes were made], so this is also an option. I haven't included an option to try a different solution entirely because this is mostly just meant to solve things short-term. The winning design can still be adjusted as necessary and possibly replaced in the future.
| |
|
| |
| This proposal is not necessarily binding on the articles for other Mario Kart games, but they should probably be consistent with each other.
| |
|
| |
| '''Proposer''': {{User|Waluigi Time}}<br>
| |
| '''Deadline''': August 6, 2024, 23:59 GMT
| |
|
| |
| ===Nitro option===
| |
| #{{User|Waluigi Time}} Secondary option. The Retro tables take up too much space for the amount of information they convey I'm just not a fan of the design in general.
| |
| #{{User|Arend}} Secondary option. I get what Doc is going for, but they made everything so big that you can only have one course fit on a single screen (at least on iPad), defeating the whole purpose of the <code>display:inline-block</code> style (alas, their criticism on the old style includes things "being too tiny to tell what anything is", so I guess we'll never see them be shrunk down). Something about the triple-border thing also seems unnecessary and clashing to me... anyway, if the tables and images are too big to fit on a screen and get <code>display:inline-block</code> work as intended, I guess it's better to have something that intentionally lists things vertically without taking up too much space.
| |
|
| |
| ===Retro option===
| |
| #{{user|Doc von Schmeltwick}} - Obviously I'm going to vote for my designs; note I have taken criticisms into account and have changed their functionality immensely since this was last discussed, so they no longer have any trouble on smaller screens and don't shrink the images to an infuriating degree (like the originals were by default) either way. Plus, it's nice having the music and the visuals together, it adds to it more. And while looking on respective pages is valid, this allows for much easier comparison between the different aspects without requiring loading new pages each time - and you cannot convince me that not having the course maps to represent them for a ''racing game'' is "too much." Also... from what I can tell, at least, my tables look better on both wider screens and smaller screens, as it leaves less dead space in the former and doesn't require side-scrolling in the latter, unlike the other designs. If you think that is an "information overload," I invite you to instead look at [https://www.mariowiki.com/Mario_Kart_Wii#Vehicles.27_stats this table on the same page] and see if you still think so.
| |
|
| |
| ===Revert to the original tables===
| |
| #{{User|Waluigi Time}} My preferred option. I'd like it if these ran from left-to-right instead of top-to-bottom, but this is a clean way to present all of the courses. We lose out on the map layouts, but I'm not sure how important that is to readers anyway.
| |
| #{{User|Meta Knight|Meta}} This is simple which in this case is a good thing. If I want to learn more about a particular course I can just click the link where there would be extra info, yet all the time trial data is in a convenient list below that I can scroll to if I wanted them all in one place.
| |
| #{{User|Ray Trace}} In this case, less is more, and the table here looks much more presentable and readable while occupying far less space. Information such as time trials times, map, (why is file name information even necessary, leave that to wiki.tockdom instead where that information can actually be useful), and music should all remain in the course article.
| |
| #{{User|Shy Guy on Wheels}} This worked fine and the attempts to change it have been rather disastrous, so I think it's best to stick with what has worked for ages now.
| |
| #{{User|Camwoodstock}} Per all. We think in this case, simpler is better, and while having the course minimaps is nice, it honestly doesn't feel worth it when it kneecaps the ease of navigation.
| |
| #{{User|Arend}} Preferred option. Nothing wrong with it, fits on the screen nicely whether it's on a 16:9 or a 4:3 screen, and it also matches with the course sections on ''[[Mario Kart 8]]'' and ''[[Mario Kart 8 Deluxe]]''.
| |
| #{{User|Tails777}} Honestly, the simpler view works better in my opinion. Arguably, it's not as consistent with how other game articles layout the courses, but I dunno, I just feel this looks fine.
| |
| #{{User|Nintendo101}} I know a lot of work was put into the Retro tables and a lot of technical competency is apparent with them. They are impressive in that sense. I also know work was done to try to address other folks' issues with the Retro tables, and that is legitimately appreciated. However, in terms of relaying information to readers, I really think the original tables still work better, both visually and in display. Retro in particular looks poor on desktop by the size of the assets within it, demanding an unwarranted amount of attention with the information imparted. The outcome of this proposal gives room for users to experiment with what specific pieces of information to display (i.e. course maps, etc.), but in terms of the raw table infrastructure, I think this remains superior to the other options available. One may feel the display of screenshots in the original table is too small for their liking. However, I think it is perfectly fine to adjust the sizes of in-game assets (like course maps) for the purposes of conveying information, and I encourage those who feel otherwise to scrutinize why they personally feel that is intrinsically inappropriate. For example, if the purpose of including something like a course map in a table is to convey the shape of the course to readers, than seeing that asset at its in-game scale in the table directly is probably not necessary and may needlessly stretch the table (as apparent in the Retro tables). (Additionally, because ''Mario Kart Wii'' is a "Featured article", I really don't think it should be left with such widely different tables in every other subsection. Looks messy. If folks wanted to continue experimenting with tables, I recommend trying things out in their sandboxes first and asking other users for feedback before rolling them out like this.)
| |
| #{{User|TheUndescribableGhost}} Simplicity isn't always bad thing. I'd very much prefer to see things instantly, rather than scroll down.
| |
| #{{User|Mario}} More straightforward. "Retro" is just overloaded with information. WT's advantage is that it's better for table of contents, but it leaves behind a lot of empty space.
| |
| #{{User|Sdman213}} Per all.
| |
| #{{User|SmokedChili}} Per all. I think Doc's arguments on screens are exaggerated because you can still click/tap them if you want to view them in closer detail.
| |
| #{{User|Koopa con Carne}} [[User talk:Koopa con Carne#Regarding courses|Copy/paste of my comment]] (originally about the Mario Kart DS page, but applicable here nonetheless): "I maintain that this design riddles the list with visual and informational clutter, which makes it look less like a useful chart and more like a collection of infoboxes. It looks bad regardless of display size, in addition to filling up the page with tens of thousands of bytes, all in the name of a moderate attempt at centralizing information on each course. [...]<br>I'll agree that overhead maps present essential information about a race course and deserve to be somehow incorporated into the list (it seemed to work well enough when you worked on the [[Golf]] page), though that is not something I can state about music samples, the file names, and the staff ghosts. Readers looking to quickly navigate through a list of courses shouldn't be bombarded with information all at once. The concern that it's inconveniently scattered across many articles is something I'd consider to be unfounded given the solution of a Staff Ghost section (formerly on the same page) and the dedicated media list (just one click away).<br>I also fail to see the inspiration from Nintendo101's work on the articles for Super Mario Galaxy and Super Mario 3D World; his approach to course listing is actually very elegant and concise, with a reasonable amount of negative space between content as to make navigation comfortable, and not packed with superfluous stuff like audio files or galaxy icons that are not immediately important to someone looking for a chart of levels. That's not to mention the cautious use of images and color coding employed to illustrate each set of levels."
| |
| #{{User|YoYo}} per all
| |
| #{{User|Lakituthequick}} These tables do not need all the things, as the 2010 meme goes. I will go into more detail about some design considerations in a comment below, but the main thing here is that tables should not be used for layout and the tables here should just list the courses. I do suggest rotating the table such that there is a row per cup instead of columns.
| |
| #{{User|Shoey}} Per all.
| |
| #{{User|Yook Bab-imba}} Per Koopa con Carne. I find this option too basic-looking, and I like the idea of having the map, but the way it's been implemented is not visually appealing. The audio files for each one is too much.
| |
| #{{User|Ahemtoday}} I'll be honest, adding in the music, having headers for different cups, even trying to squeeze the course maps alongside images of the courses — I just don't think the ''game'' article is the place to do all this when users could just click on the link.
| |
| #{{User|Bro Hammer}} - Per all.
| |
|
| |
| ===Do nothing (no binding decision, allow further options/discussion)===
| |
| #{{user|Doc von Schmeltwick}} - This is a fluid project, and I do not believe that table structure is the sort of thing that ''should'' be decided via proposal. Ideas come and go, some good, some bad, some middling but requiring some polish. This should be done through discussion alone, not a rule-binding proposal.
| |
| #{{User|Hewer}} Per Doc, I think all three of these designs have merits. Still not really sure if this option is necessary since the wording in the proposal suggests that the decision won't be binding anyway, but I agree with the sentiment. (By the way this is a bit off-topic but can we do something about the course list on [[Mario Kart 8 Deluxe – Booster Course Pass]]? It gets cut off on my phone screen.)
| |
| #{{User|Super Mario RPG}} I gave this some thought and hadn't made a conclusive decision, but all of the discussion in the comments makes me think that it is possible for both sides to reach a compromise.
| |
| #{{User|Lakituthequick}} Per my vote above, but I would prefer that the listing uses a <nowiki><gallery></nowiki> instead of tables altogether, so I will split my vote.
| |
|
| |
| ===Comments===
| |
| @Arend Speaking personally here, I prefer more scrolling and consistently sized table cells over microscopic might-as-well-not-be-there-at-all images and inconsistently sized cells that bump their size up and down from text wrapping. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:45, July 23, 2024 (EDT)
| |
| :I mean yeah, they're small, but not ''microscopic''. They're 150px wide, perhaps only a tad bit smaller than wiki thumbnail images by default. Even then, I think that 400px wide is a bit overkill. I mean, images in our infoboxes aren't this wide. {{User:Arend/sig}} 16:11, July 23, 2024 (EDT)
| |
| ::To be blunt, it's not about the width, it's about the height (specifically, to be consistent with the maximum height of the maps). If we had images representing the same shots of the course intros that ''weren't'' taken at widescreen display, I'd happily prioritize those and save on a bunch of space. As it is, only those were uploaded. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:23, July 23, 2024 (EDT)
| |
| ::EDIT: I went ahead and removed the screenshots in favor of just using the banners. What do you think? [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:42, July 23, 2024 (EDT)
| |
| :::I suppose that looks a bit better? I'm not sure how I feel about the course maps looking ''enormous'' compared to the course banners, but at least more than one course can fit on my iPad screen. I think I still prefer my design though. (Side note: are the internal file names for these courses necessary, too?) {{User:Arend/sig}} 17:11, July 23, 2024 (EDT)
| |
| ::::I suppose they're not necessary, but I'm not sure what other context they can be put in where they can be compared to each other within the same list on the same page. Because easy comparison's the entire reason I added them. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:14, July 23, 2024 (EDT)
| |
| :::::I personally really like the idea of including the course maps. That is a good idea, and having the option to compare them is also great. But I don't think they need to be displayed at their in-game resolution. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 17:17, July 23, 2024 (EDT)
| |
| ::::::Technically, there is no "in-game resolution" for these as they are postprocessed models. The way I have them is at a consistent screen size, but the actual file dimensions are inconsistent - making resizing them consistently a hassle. I'll try, though. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:20, July 23, 2024 (EDT)
| |
| ::::::EDIT: The dark deed you have requested is done. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:34, July 23, 2024 (EDT)
| |
| :::::::I appreciate your willingness to modify your tables based on user feedback.
| |
| :::::::I whipped up a little [[User:Nintendo101/community garden|table example myself]], and I am curious to know what you (and others) think of it. It does not include music, banners, or in-file names for courses, but it has breathing room for other information if one choses to include it. It retains screenshots and course maps. Colors are not finalized or anything like that. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 18:44, July 23, 2024 (EDT)
| |
| ::::::::No music? <s>You describe a world I do not wish to live in.</s> I think audio cues are just as important as visual ones, and shouldn't just be left to languish on the media list pages. That's why I put them on these when they're available. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:48, July 23, 2024 (EDT)
| |
| :::::::::They aren't languishing on the media lists, they're in the infoboxes on each course page. The only information from these tables not on the individual course pages is the internal names, which absolutely ought to be added (some other courses in the series have them already, e.g. [[Squeaky Clean Sprint]]). {{User:Hewer/sig}} 19:36, July 23, 2024 (EDT)
| |
| ::::::::::Precisely where you can only compare them with tracks from other games, rather than ones from the same game - and remember, I said they're just as important as visual cues, so they should get equal wait. I fail to see how putting them here is a detriment in ''any'' way; an added small black rectangle is ''not'' going to cause an "information overload" to anyone - particularly when this very page already has that insane "internal statistics" table. I get that most people aren't used to it, but it doesn't harm anything, but adds another layer of depth and understanding - I can't see any reason to complain about it other than being uneasy about new ideas - having a more "old-fashioned" mindset, so to speak. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:09, July 23, 2024 (EDT)
| |
| :::::::::::To clarify, I'm not strongly for or against any option, just wanted to point out that your implication that the media lists are the only other place with the music is incorrect. {{User:Hewer/sig}} 20:29, July 23, 2024 (EDT)
| |
| :::::To be fair, I did relent on including the course maps on my battle map table design, and I think it made the thing look better in general. But I shrunk mine down to the height of the screenshots, since I placed the shot and the map horizontally. Waluigi Time did the same thing with his Nitro course tables. {{User:Arend/sig}} 17:25, July 23, 2024 (EDT)
| |
| ::::::To me, it's about consistency for each image type, not for each row, as that often leads to inconsistent rows; note how the map columns in WT's tables are all over the place in width. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:50, July 23, 2024 (EDT)
| |
| :::::::I feel like this proposal is more so about "table structure" and less about what specific information is covered in them. While I do not necessarily think music needs to be included in the table I whipped up, I can see it being included underneath the description rows. (Though I more strongly agree with Ray Trace that internal file names should not be in the tables for main game articles. But again, I view that as tangential to table structure.) - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 20:20, July 23, 2024 (EDT)
| |
| ::::::::Well, I care less about the shape and more about the content. It needs ''either'' the screenshot or the banner, plus the map, plus the music. Plus the title, of course. <small>To be frank, anything that gives an excuse to put the Wii Rainbow Road theme on more pages is enough justification in and of itself.</small> [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:26, July 23, 2024 (EDT)
| |
|
| |
| @Waluigi Time rather than adopt strict adherences to what is covered in the tables, could one say, build off of the original table's structure if they wanted to incorporate other bits of information they thought was potentially useful? I do prefer them over the other two, but I do think users should feel like they have some freedom to at least experiment with how information is to be displayed and what to include.
| |
|
| |
| Also, would this proposal have ramifications for the character and kart tables on the page, which are structed similarly to the Retro option? - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 15:59, July 23, 2024 (EDT)
| |
| :I don't have any issue with making further changes, this is more about settling on a basic design than anything. I don't really like the character/kart tables either, but those are out of the scope of this proposal. They might warrant future discussion. --{{User:Waluigi Time/sig}} 16:25, July 23, 2024 (EDT)
| |
| ::I dislike them for the same reasons as I do for the course setup. It's a lot of table, image and space usage doesn't really justify the kind of information being shown. {{User:Mario/sig}} 20:34, July 23, 2024 (EDT)
| |
| :::Problem with the other way is having tall columns full of numbers for each attribute means which column is which gets lost the lower down you go. And the sides get cut off. This way, they don't. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:22, July 23, 2024 (EDT)
| |
|
| |
| [[Mario Kart Wii#Battle stages|I made a bit of an experiment of my own, too, this time w/ the battle stages]]. It makes better use of the <code>display:inline-block</code> style by removing some of the unneeded code, shrinking the images a bit and getting rid of the more superficial stuff, so it can fit all courses of a cup on widescreen. Granted, only 4 of each course can fit on a 4:3 display, so when it comes to battle courses, it still looks a bit weird on iPad, but I prefer this over Doc's take. {{User:Arend/sig}} 16:11, July 23, 2024 (EDT)
| |
| :I still don't like hypershrunk screenshots and lack of maps. Contrast with the mildly similar course tables I made for ''[[Super Mario Kart]]'', which are small only due to the small resolution of the original screenshots and ''do'' contain the entire layout. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:14, July 23, 2024 (EDT)
| |
| ::I don't feel like the screenshots are """hypershrunk""", these are just a tad bigger than how an image is typically embedded on an article, and I feel they're just right in this case. Wonder what other users think of it, though. Anyway, I decided to throw in the minimaps and make them evenly sized with the screenshots. I made sure so five courses can still fit on widescreen, <s>but now 3 fit on a 4:3 iPad screen (making that look better on there for the battle maps, but probably not so much for the race courses... sizes might need to increase for those then, but the battle courses look fine for me).</s> apparently I was mistaken, 2 courses can fit on a 4:3 iPad screen now, so that renders the issue of the race courses probably not looking good on iPad moot. {{User:Arend/sig}} 17:11, July 23, 2024 (EDT)
| |
|
| |
| <big>'''RETRO OPTION'S EFFECT IS ALTERED.'''</big> It now looks like [https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4308233#Retro_Grand_Prix this]. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:42, July 23, 2024 (EDT)
| |
|
| |
| Can we not have internal names? Thanks. {{User:Ray Trace/sig}} 20:14, July 23, 2024 (EDT)
| |
| :Well I want them listed somewhere for easy comparison with each other, but ''I guess'' in the most long-suffering inflection ever that I could put that also in a separate list, as with the time trial stuff. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:26, July 23, 2024 (EDT)
| |
| :I don't agree with or really understand the idea they shouldn't be on the wiki at all ([[MarioWiki:Proposals/Archive/58#Add an Internal Name syntax to Template:Foreign names|there was a whole proposal about how to make note of them]]), but yeah I agree that it doesn't really make sense putting them on tables on the game's page rather than on the course's own pages, since although it's valid information, it's pretty trivial and not even shown to the player. {{User:Hewer/sig}} 20:29, July 23, 2024 (EDT)
| |
| ::Is there any particular reasons courses get to have file names listed underneath them while every other element (items, characters, vehicles, course objects, etc.) don't? It's unnecessary information for a game article, this kind of thing is best for individual articles and I already think it slightly breaches coverage that is best left better for wikis specialized in this, explicitly [https://wiki.tockdom.com/wiki/Main_Page Custom Mario Kart] wiki. Listing character filenames would be also very terrible because there is no "BbLuigi.szs" (it might be in Driver.szs, been a while since I modded Mario Kart Wii), every single character technically is merged with their vehicle so you get "sa_bike-blg.szs" which means Baby Luigi on a Bullet Bike (and there is -2 and -3 variants of them which are lod model files should we include those too?). {{User:Ray Trace/sig}} 20:31, July 23, 2024 (EDT)
| |
| :::Well, the blunt reason is they're the ones I could get from noclip.website. As for putting them exclusively on their own pages, that removes the ability to compare, and map models tend to be more... consistent in that regard anyway. Also, the "internal statistics" pages for MK7 and MK8 ''do'' list the internal names for their items. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:46, July 23, 2024 (EDT)
| |
| ::::That's where the filenames *should* go, not in the game articles themselves. {{User:Ray Trace/sig}} 01:11, July 24, 2024 (EDT)
| |
| :::::-shrug- Well, MKW doesn't have a sub article like that, so I do what I can. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 01:20, July 24, 2024 (EDT)
| |
| ::::Why do filenames need to be "compared" so badly anyway, to the point that having them on the individual pages isn't enough? {{User:Hewer/sig}} 06:52, July 24, 2024 (EDT)
| |
| :::::Because otherwise, for instance, Daisy Circuit being "Senior Course" doesn't make any sense until you realize that it's meant to be the counterpart to Luigi Circuit being the "Beginner Course." I had to scratch my head for a few minutes on that one when I first saw it on noclip, but it makes more sense when they're shown together. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 11:41, July 24, 2024 (EDT)
| |
|
| |
| Y'all may wonder why I'm taking this so personally. As it happens, web design is my primary occupational skill. By saying that a small, inconsistently celled, poorly ordered table that was probably made in 5 minutes and conveys very little information is better than the nested table I spent hours ensuring would look perfect on any screen size is, to be blunt, a rather harsh insult to the main thing I'm good at, so naturally I'm not going to take very kindly to it. Nintendo101, imagine if someone took issue with in-depth taxonomy being used for categories and sought to restrict it to the level of what a 5-year-old's picture book on animals would convey. That's about as insulting as this is, if not slightly less (and I'm a taxonomy nut too, so I can relate through that, even if I didn't pursue biology at an occupational level due to my squeamishness). Trace, imagine if someone decided to get rid of all the model renders from the site because screenshots are more in-game accurate - and in the meantime, start calling them "sprites" because "it doesn't matter." Hell, LGM, imagine if someone launched a campaign to have all ''Mario Party'' images feature Wario ''winning'', either in apathy or direct antipathy towards the beloved running gag you've built up these past several years. And I take issue with the "simplicity" argument: we are a wiki, it is not our job to "simplify" things, it's our job to document and convey them. If you want things "simplified," there's a million patronizing-voiced YouTubers who can do that much better. As it is, you're just making me feel unwanted :\ [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:48, July 23, 2024 (EDT)
| |
| :I'm not particularly fond of calling tables I see here "made in 5 minutes" ([https://www.mariowiki.com/index.php?title=Mario_Superstar_Baseball&diff=802980&oldid=802226 for example, I've worked on Mario Superstars Baseball's character table a verrrryyy long time ago], prior to your current revamps, let me tell straight that no way these were hastily done in 5 minutes and that a lot of thought was indeed put into them). None of us here are saying that you didn't put any effort, nor did we insinuate that you've purposely done design decisions that we don't agree with. Honestly, if there was a compelling argument that models are bad because screenshots are better and we should delete all models on the wiki, and that said proposal passes, then yeah sure I'd be peeved at first but eventually, I just realize it's really not worth getting fussy about. I've had plenty of proposals that didn't go the way I want, and it is frustrating to get people who feel like they don't agree with you or read your points, but ultimately, none of this is a personal attack, it's a disagreement. I also strongly disagree with your assertion that we're simplifying things just for the sake of it and it...kinda is our job to simplify: we're simplifying things for the sake of accessibility or readability, you know, function. There's a reason we limit color usage in tables or we make tables occupy a reasonable amount of space without requiring readers to scroll through text too much, and if simplifying things makes it better for the browsing experience, then so be it, but like all things, it's all case-by-case. I prefer tables over plain bullets (like in the Mario Superstar Baseball article that's why I revamped it like that and it stayed that way for quite some time) but there is such thing as too much formatting and clutter which makes things much tougher for readers to navigate. {{User:Ray Trace/sig}} 01:06, July 24, 2024 (EDT)
| |
| ::I'm aware it's not a personal attack, and I too have had many proposals that have gone counter to what I want, but this particular case is so entrenched with what it is I ''do'', and indeed [https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4285578 started with an ''actual'' verbal attack against me], that I cannot help but be defensive on it. All that said, I've done my darndest to appease everyone, and I still don't know what the problem is, particularly why one that doesn't even show the course maps (a paramount representation for '''race tracks''') would be more popular - and I see no "compelling argument" for that. The current design I have is just as simple, but not as ''cryptic'' as the "how it was before" one. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 01:20, July 24, 2024 (EDT)
| |
| :::I'm open to ideas of better organization, I'm always looking for improvements to presentation ([[Mario Sports Superstars]] can use one, it's a bit of a mess lol), but as of currently, in my opinion, there's too many images and they're too big (it's somewhat of a headache to browse over them). I do appreciate the attempts to give them a little bit more flair than prior ones (when it comes to tables like these, I'm just a bit more old fashioned because that's what I'm used to) ([[Mario Kart Arcade GP 2]] before the revamp I actually liked but now, I think I've outgrown how and colorful tacky it used to look lol). I don't agree with adding mini maps to the course overview mostly because most Mario Kart games don't do that and just show an overview of the course, so I personally don't deem it as necessary as the track overview). I do agree that Koopa Con Carne should be a lot less abrasive undoing your edits however, because ultimately, we're not here to shit on each other but to improve browsing experience for users. {{User:Ray Trace/sig}} 01:26, July 24, 2024 (EDT)
| |
| ::::I mean, the maps ultimately tell more about the course than a screenshot of any size (unless it was like {{file link|MKDD MushroomCity.png|this screenshot}}, but that's obviously not a native angle). And while they don't represent on the course select screen, they are constantly on the screen during the race itself. I'd just as soon prioritize the maps over the screenshots, but I'd prefer both were there in some capacity. And if Swoop's article can get a soundbyte of a parrot chirping embedded in its history section, then these items can get their music tracks on here for the trifecta of representation: a visual, a layout, and an audio. Nothing left out, not taking up much space (more space is taken up by the sheer size of the cup icons now lol), and not shrunk into oblivion when on a smaller screen - the entire reason I made these "automatically sorting" tables is because I was tired of things shrinking into near-nonexistence when the screen was small, and especially the ones many character tables had where, due to the images' inconsistent base sizes, they tended to shrink in weird inconsistent ways leaving some tiny and others normal. I merely wanted that weird side effect to stop. Buuuuut I'm rambling now. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 01:40, July 24, 2024 (EDT)
| |
| ::::@Ray Trace, criticizing someone's work is "shitting on it" now? All I did was calling Doc's design "bad" and "extremely hectic and crammed", which most people in this proposal, ''yourself included'', are in agreement with. I didn't make fun of it, I didn't put it in BJAODN, and I didn't insult the person who developed it. (If Doc took that as a "verbal attack against her", that's on her.) You can't accuse me of bad faith. You have lobbed similar criticisms to other users' works in the past and you're frankly no stranger to using much nastier language. Being blunt is not being discourteous. {{User:Koopa con Carne/Sig}} 06:21, July 24, 2024 (EDT)
| |
| :::::I don't know if the word-or-its-counterpart is softer in Romanian, but calling something "bad, simple as" is about as insulting as you can get (possibly even worse than profanity) - and it tells me ''nothing'' I could do to improve it, so it's not a "legitimate criticism." That should be obvious - and again, as my primary occupational skill, an insult like that towards it is also an insult towards me, because that's what I ''do''. (Also, most people really aren't acknowledging the "[https://www.mariowiki.com/index.php?title=Mario_Kart_Wii&oldid=4308233#Retro_Grand_Prix current]" iteration, where I've actually taken people's ''actual, constructive'' criticisms into account to make everyone happy, but I guess it's pointless if people aren't gonna check and offer any further critique...) [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 09:48, July 24, 2024 (EDT)
| |
| ::::::There's nothing insulting in calling someone's work "bad". The author is a separate entity from their own creation, which, if deemed of low quality, grants an invitation to the author to learn and grow. Sometimes the criticism is in bad faith, or indeed seeps into ad hominems, but I'm doubting the likelihood of that being the case here when 13 people so far have spoken out against these changes, quite civilly at that. Your continuous appeal to emotion has no place here; frankly nobody cares how passionate you are about something if you're unwilling to actually listen to the feedback you're given. Your current iteration, whether acknowledged or not, still bloats the page significantly, harming the ease of navigation and loading up the storage just so you could have everything and the kitchen sink in one restricted spot.<br>I'd also like if people stopped assuming I'm applying meanings and connotations from my native language into English. I'm pretty sure I write in this language at a comfortably native-like level, and the qualifier I gave to your work is, in fact, appropriate. If you're really curious how the word for "bad", as in "low quality", translates into Romanian, [[wiktionary:prost#Romanian|it's the same word as the one for "stupid"]]--and believe me when I say that not once did I endeavor to attack your intelligence in my criticism. {{User:Koopa con Carne/Sig}} 10:27, July 24, 2024 (EDT)
| |
| :::::::I'm not trying to "appeal" to emotion, I'm stating how I feel so there's no ambiguity as to why I feel offended by this, even if it's misplaced. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 11:00, July 24, 2024 (EDT)
| |
| ::::::::Koopa con Carne, if someone takes offense to your use of language, regardless if you mean it or not, then yes, your language is way too direct and abrasive, and people will find your blunt wording offensive; people will react to criticism differently. Maybe the usage of the word "bad" you think isn't offensive, but your edit summary calling out Doc von Schmeltwick directly telling her to "stop being so protective of your edits, you don't own the material shown here" absolutely is, there is no way to go around what your intent of writing is. Also, this isn't about me and my usage of language in the past, regardless of how direct I was, it's about your behavior. I also strongly disagree that there is "nothing insulting in calling someone's work bad" or telling someone that "nobody cares how passionate you are", those are, by definition an ad hominen, and yes, it is an insult on someone personally, even if it purely directed at the work itself and not the author, there isn't a total disconnect from someone's work. {{User:Ray Trace/sig}} 11:27, July 24, 2024 (EDT)
| |
| :::::::::I would like to point out how Nintendo101 also is supporting moving back to the original, but their comments have been nothing but supportive of experimentation, and they have given constructive ideas on what I should do with my designs to make them work better (shrinking the maps and all that). [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 11:43, July 24, 2024 (EDT)
| |
| :::::::::@Ray Trace, I take it you changed your stance on [https://www.marioboards.com/threads/38172/#post-1916073 this], then?<br>"There's no need to internalize criticisms of your writing; we aren't attacking anyone personally when we say that the writing is sub-standard."<br>If you no longer associate with that statement, and you now truly believe that calling someone's work "poor" or "bad" is offensive and a personal attack, then what do you have to say regarding this point in [[MarioWiki:Courtesy]]:<br>"There is no need to be nasty when you undo an edit or clean up someone else's work. For example, if you're fixing someone's bad grammar, just say "fixing grammar" or "'''<u>bad</u> grammar'''""<br>What about the time I, myself, got overprotective over my own edits and a bureaucrat told me [[User_talk:Koopa_con_Carne/Archive_2#Warning|the following]]:<br>"As a final note, remember that this is a ''wiki''. <u>Anyone</u> can come along and modify what you have written. Any work you submit here is [[MarioWiki:General disclaimer|not owned by you]], and you cannot become pretentious or hostile towards users who ''validly'' change something."<br>Correct me if I'm wrong, but isn't this exactly how Doc has conducted herself so far with the edits to these pages? I only reverted her edits twice, once as I was expressing my distaste for the new table design, and another time when she [[Special:Diff/4285573|nonchalantly undid Waluigi Time's own work]], enforcing her own vision, which is discourteous. For the record, the reason I'm dredging up those messages from years ago is to show ''exactly'' the kind of philosophy I employed to develop myself as an editor of this wiki; and whilst I still don't agree with the way my contributions were sometimes derided, I was very much going down a wrong path, which these reminders helped correct. To find that you are suddenly backpedaling on these notions is disconcerting and I'm seriously starting to call into question the good faith of the people I'm talking with here. Try to be consistent. I take the liberty of reciprocating a person's criticisms if they, themselves, act inconsistently. {{User:Koopa con Carne/Sig}} 12:18, July 24, 2024 (EDT)
| |
| ::::::::::The difference is when I initially reverted, I didn't call WT's work "bad," I apologized and explained what issues I saw in it (and if he had done the whole thing instead of just one section, I wouldn't have the kneejerk response; I prefer mainspace edits avoid "construction" time unless it's a truly herculean effort to change, and more of the course table edits I've made have been all in one go - often across multiple days of being in the editing mode before submitting). [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:22, July 24, 2024 (EDT)
| |
|
| |
| By the way, is the "no binding decision" option that Doc added necessary? The proposal already suggests that it's not trying to be binding ("the winning design can still be adjusted as necessary and possibly replaced in the future"). {{User:Hewer/sig}} 12:12, July 24, 2024 (EDT)
| |
| :I'm not entirely sure, proposal rules do require a status quo option unless the status quo violates policy. In this case, doing nothing would leave a featured article in a very messy state indefinitely until someone makes a new design that we can agree on, which doesn't exactly seem supported by policy. A big part of this proposal is cleaning up the mess, whether we want to come up with a different solution down the road is a mostly separate issue. (That being said, I do like the layout Nintendo101 came up with much better as far as including more information goes.) --{{User:Waluigi Time/sig}} 13:02, July 24, 2024 (EDT)
| |
| ::It's less "leave it how it is" and more "don't make a binding decision that could age poorly and would require another proposal to change." As it previously was, all three were that kind of option, and, well - to quote Obi-Wan - ''only a Sith deals in absolutes'' <s>as hilariously hypocritical that quote is</s>. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:19, July 24, 2024 (EDT)
| |
| :::What if we reverted to the original tables just to keep the display consistent on a featured article, and then worked on new ones together in a sandbox until we got to something we all liked? - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 16:45, July 24, 2024 (EDT)
| |
| ::::That could work! [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:41, July 24, 2024 (EDT)
| |
|
| |
| @Hewer I might get to that monstrosity of a track collection at some point depending on how this goes, though I'll probably stay far away from Tour's, I'm not brave enough to try anything with a list of that sheer size yet. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:14, July 24, 2024 (EDT)
| |
|
| |
| Doc von Schmeltwick: if it means anything, if I have suggestions for ideas and whatnot, I'll suggest them, so as long as my part time work schedule allows for it. For instance, I bring up that rawsize gallery proposal.[https://www.mariowiki.com/MarioWiki:Proposals/Archive/68#Expand_use_of_.22rawsize.22_gallery_class] It wasn't going anywhere at the time, and I opposed it, but I dropped a comment asking about additional parameters that would address voter concerns, which is including size parameters. You did this and I changed my vote to support. However, I waited a bit to see if you're going to amend the proposal to call attention to the new parameters, but at the time, I waited a while. And then I finally noticed the deadline was the next day, and there were more oppposes than supports, which I then tried to call attention to the new parameters you and Steve made, thru our Discord server and a comment in the proposal and people did change their votes in time. I was really concerned the proposal was going to fail despite the provisions being updated; it would be very disappointing for you despite what you've tried to do, so I tried my best to call back to it before deadline. Now, the proposal passed and I thought you must've been relieved and quite satisfied people changed votes.
| |
|
| |
| So anyway, my criticisms here are that, just criticisms. I really didn't expect them to upset you, as I was under impression you were already aware that I've criticized your tables in the [[Talk:Mario Strikers Charged]] page. That wasn't my intent, so I'm sorry for that. To explain my problems: there are several bedrock issues I have. First, what is wrong with the tables and why do they need fixing? I didn't quite understand why the original tables were so bad. Second, is table really the ideal solution for organizing the information? From all the coding and fretting over displays and how images look, I was left wondering if inline formatting is so fundamentally flawed and limited that it simply isn't the appropriate task to carry this out. Additionally, from my understanding, tables is not recommended for layout, and Wikipedia recommends using css classes due to their ability to adapt to different sorts of displays.[https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Tables#Appropriate_use] I understand we are not Wikipedia, but MarioWiki doesn't have a comprehensive guide for using CSS on MediaWiki projects to their fullest potential, so I have to rely on what older wikis with a much bigger userbase (and a web design expert being more likely to have written the guidelines or gave suggestions for 'em) have to say. I also understand that the tables you've worked on are not the only offenders in the wiki, so this advice should extend to general practices on the wiki. However I cannot articulate much more what "CSS class" entails in. You should know better since you did say you have experience in this. All my CSS experience was really just editing the interface of the wiki as well as making custom layouts in Acmlmboard-style forums. So, you'll have to do a little more exploring into what that does, maybe work out something with Steve here, experiment with CSS and stuff, I'm sure you might find a cool thing or two. {{User:Mario/sig}} 22:08, July 24, 2024 (EDT)
| |
| :Ultimately, my problems with the original come down to two things: the lack of information coming off as less "simple" and more "cryptic," and there being a lot of wasted space on wider screens (as well as the cups being sorted by column, which bothers me a lot more than it probably should - I expect left-to-right, not top-to-bottom). Difficulty in finding the proper parameter led to using nested tables, while learning how it looked on smaller screens is what gave me the idea for the inline-block. If screen sizes were more consistent, this of course wouldn't be a problem, but such is the world we live in. The inline-block is the only way to make it so it doesn't look awkward on at least one of the screen types, provided enough work goes into it. On that subject, how I handled the character and vehicle tables: in the horizontal-based previous versions, if you were looking at an item near the bottom of the list, you can no longer tell which column represents what, since it's far up offscreen, and the numbers tend to blur together anyway. This is also why I've taken to using bar meters and color-coded star meters, it makes it clear what is numerically represented without having to focus in a sea of tiny black numbers - if information can be gleaned to someone with unfocused eyes, then as far as I'm concerned it's become more accessible. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:23, July 24, 2024 (EDT)
| |
| ::Yeah, not hugely a fan of cups being sorted by column but I understand the possible justification: courses are ordered from top-down in the game. By the way the cup display in Vector 2022 (which I use; it's a narrow desktop display similar to Wikipedia's current narrow design) is uneven, but that's probably able to be fixed. As for lack of information, the article is big enough already and I feel the bgm is the most dispensable kind of information to have. You brought up the Swoop's cockatiel clip, but it's not common practice in the wiki overall, and it was a leftover part of a trivia point being incorporated (the audio clip supports a trivia point in the end; the course bgm just seems more of bonus information). This is the same case for filename, which I think belongs more in the main article than Mario Kart Wii (and try to imagine this being extended to other articles; should Mario's information in [[Super Mario Odyssey]] include his szs file? Should Sand Kingdom also have its szs file accompanying its name?). I could see a case of the file instead being linked in the body text rather than be a thumbnail clip. Finally, those stat bars. They're not easy to read. It may owe to just how the coding is designed to be, but it's really thin and small (bordered by a nesting table) and doesn't contrast well with the wiki's interface. As for nesting tables? I believe these are to be used very sparingly (doesn't translate to screen reading very well?) and I don't think this is an instance where they should be used. The discussion is getting lengthy and while I know I should try to address them all, I just want to focus on a couple of things before it turns into a gish gallop sort of thing. {{User:Mario/sig}} 22:41, July 24, 2024 (EDT)
| |
| :::I did move the filenames to the course pages earlier today, actually. I don't think that the BGM tracks can hurt anything by being present; visually, they're a small thin black rectangle, and don't even load the .oga unless clicked on directly. And, to be frank, I ''really like'' having them there, having relevant music available is a treat IMO. In regards to the nested tables, I really don't see where the issue is coming from; the most awkward look the current version of my course tables can have is three-across, which IMO still looks preferable to the previous one if only because if internal layout (and I can fix that anyway by giving it a clear separator - so it automatically shrinks from four across to two across, that's just getting a little bit too recursive IMO. I just like the ability for it to fill horizontally no matter the screen size without, say, shrinking Waluigi to near-nothing while Donkey Kong gets bloated up. Because before I started implementing the nesting, that happened. A lot. Plus, it makes it easier to tell which number goes to which stat/character when editing, because without that, they tend to blur together. As for the bar meters, I find them more useful than numbers alone, especially in cases where the maximum possible values differ; any issues with their formatting can be fixed easily, I created a template specifically for it. I'll admit, the tight white-and-black outline is definitely a personal appeal of mind (resembling stat bars and health meters in many games), though it's also useful in cases where the background isn't already solid white - which is a case I prefer to deal with ahead of time rather than later. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:54, July 24, 2024 (EDT)
| |
| ::::The biggest reason I'm opposed to relevant music there is mostly because, while I do agree it's important information, I think it's unnecessary in a game article, where I think the information becomes relatively extraneous. I'll argue here that sound effects such as voices are around as important, but that doesn't mean we should integrate format character select voice clips for the character gallery. Plus, I'd apply this consistency to every other game article on the wiki and frankly having music underneath every time we mention a location or describe it gets very cumbersome. {{User:Ray Trace/sig}} 16:48, July 25, 2024 (EDT)
| |
| :::::The main difference between this and every other game is that the ''Mario Kart'' games generally have one theme (all unique with occasional exceptions for similar courses) per location (with occasional variations, like with Koopa Cape), while levels in platforming games can have many different music tracks, most non-unique - for instance, SMB having fairly consistent music for locales and SMG music shifting often mid-mission. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:42, July 25, 2024 (EDT)
| |
| ::::::Yes, but also take account into RPGs, Mario Party, Mario Sports games, and other Mario spinoffs as well. I just think having consistent application of it across game articles would be very messy. {{User:Ray Trace/sig}} 18:40, July 25, 2024 (EDT)
| |
| ::::::I agree that music is probably better served off of the main game articles. I honestly think the media lists associated with game articles have potential to be a lot more robust than they currently are, as thorough articles about game music that folks would enjoy reading. But that is an idea to explore some other time. Ultimately, I think the main articles are primarily meant to be read, so text and visual information is more important.
| |
| ::::::But regardless, just to get a sense of how audio files ''could'' be included in tables without it taking up too much real estate on the article, I have incorporated them '''[[User:Nintendo101/community garden|here]] in a collaborative sandbox that anyone and everyone is welcomed to edit'''. I put this together in response to Doc's openness to working on tables as a group. While I do think the original tables on the article are serviceable, I understand if others feel like they could put together something different, and I think it's nice to have a space where folks could experiment with peers. The infrastructure of the table in this sandbox was something I put together, but others can swap that out with something else if they feel they are better. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 20:25, July 25, 2024 (EDT)
| |
|
| |
| Some design considerations for tables and lists and the combination thereof that I think are important, and which are ''very'' commonly violated on this wiki, including in the tables concerned in this proposal:
| |
|
| |
| *Tables should be used for tabular data. Tables should not be used for layout.
| |
| *Nesting tables is a no-go. This usually implies that they're used for layout, for which I refer to the preceding point.
| |
| *Vertical scrolling for a table on smaller screens is not so bad if said table is displaying tabular data. While it is true that small screens present issues for layout when layout is the target, for data tables this is fine and not something worth "solving". The internal kart statistics elsewhere on this article are an example of such.
| |
| *If layout is a goal, then tables are not the solution and one should look into semantically laying out the right HTML and sprinkle the right CSS over it. This, I'm aware, may scare people who are not proficient in coding beyond the simplified layer wiki coding provides, which is why at that point templates developed by people who are proficient in this matter can be interesting, which are more usable by the average editor. This is not a thing I have seen a lot on the wiki before though.
| |
| **There are a few templates around which do abstract complex coding away as such, but those I've seen ironically use tables for such layout.
| |
|
| |
| Up for taste:
| |
|
| |
| *I don't think music and internal names are worth adding to the course overviews. Maps... maybe, but I would prefer a screenshot or render. For more information I will visit the wiki page about the course I'm interested in.
| |
| *For visualising numbers beyond a plain number, it is possible to use simple styling to colour text or background of cells. In the case of bars such as used in the vehicle stats (which, that table should be entirely revamped to be tabular anyway as per the above), that bar can be stylistically added to the background, for example.
| |
|
| |
| In regards to "adjustments to the winning design" and the option I voted, to expand on my suggestion there: Imagine, if you will, you read the table aloud as if you are reading a book. You will hear: "Mushroom Cup. Flower Cup. Star Cup. Special Cup. Luigi Circuit. Mario Circuit. Daisy Circuit. Dry Dry Ruins. Moo Moo Meadows." et cetera. This is confusing!<br>
| |
| The argument that the game lists them this way is not valid, that would turn this into a table-for-layout, which is not good.
| |
|
| |
| Other tables on this article showcase much the same issues as the course ones, but I'll leave those out of this for now as they are outside the scope of this proposal and I much would like to go to bed now. {{User:Lakituthequick/sig}} 00:45, 27 July 2024 (UTC)
| |
|
| |
| :"Table-for-layout" is ''not'' bad, though, it's a basic function of wikitext - and while yes, HTML would work for that, the native wikitext makes more sense to use for consistency with how other structures are built. I don't know why you're against it, but it being "bad" is wholly subjective. Personally, I dislike galleries being used that way; by default, the images tend to be much too small and the items have a ridiculous amount of padding with no barrier around the textual portion. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 22:47, July 26, 2024 (EDT)
| |
|
| |
| ::Wiki formatting is just an abstraction layer over HTML to make it easier to use, this does not affect the function and purpose of tables and other markup. I'll cite a few sources:
| |
| ::*[https://html.spec.whatwg.org/multipage/tables.html Tabular data (HTML Standard)]
| |
| ::**"The table element represents data with more than one dimension, in the form of a table."
| |
| ::**"Tables must not be used as layout aids. Historically, some web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results. In particular, users of accessibility tools like screen readers are likely to find it very difficult to navigate pages with tables used for layout."
| |
| ::*[https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table <nowiki><table></nowiki>: The Table element (MDN Web Docs)]
| |
| ::**"The <nowiki><table></nowiki> HTML element represents tabular data—that is, information presented in a two-dimensional table comprised of rows and columns of cells containing data."
| |
| ::*[https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Basics HTML table basics (MDN Web Docs)]
| |
| ::**"A table is a structured set of data made up of rows and columns (tabular data). A table allows you to quickly and easily look up values that indicate some kind of connection between different types of data, for example a person and their age, or a day of the week, or the timetable for a local swimming pool."
| |
| ::**"HTML tables should be used for tabular data — this is what they are designed for. Unfortunately, a lot of people used to use HTML tables to lay out web pages, e.g. one row to contain the header, one row to contain the content columns, one row to contain the footer, etc. [...] This was commonly used because CSS support across browsers used to be terrible; table layouts are much less common nowadays, but you might still see them in some corners of the web." (this section continues [https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Basics#when_should_you_not_use_html_tables with more points])
| |
| ::Use of galleries is indeed subjective, however, for the issues you raise, there are a few display modes for galleries as listed in [https://www.mediawiki.org/wiki/Help:Images#mode_parameter the MediaWiki docs]. Especially <code>mode="packed"</code> is of interest in course galleries, and attributes such as <code>widths</code> and <code>heights</code> exist to make images larger. {{User:Lakituthequick/sig}} 16:04, 27 July 2024 (UTC)
| |
| :::Dedicated layout elements in HTML tend to be a bit more squirrelly to use than table elements (and I did attempt using divs at first, but the result was so poor it didn't make it past the edit preview phase). Taking advantage of easy-to-use elements in creative ways is ''not'' bad, in spite of what their original purpose was. And yeah, I know about those gallery tags, and use them often on gallery pages; they still don't look as good as tables do on mainspace pages, and I prefer to keep gallery elements exclusive to dedicated gallery sections and pages whenever possible. A page interrupted by a table is normal; a page interrupted by a gallery just looks ''off''. And yes, that too is subjective, but I'm not saying it should be disallowed completely. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 12:49, July 27, 2024 (EDT)
| |
| ::::I'm going to have to question your claim that "web design is my primary occupational skill". Do you know CSS or not? To be frank and honest, your replies to LTQ's comment is not lending credence to your claims. {{User:Mario/sig}} 15:20, July 27, 2024 (EDT)
| |
| :::::Yes, I do (and have many examples on the very computer I am using made in Visual Studio; if you need proof, I can DM you a github link), but some CSS functions do not work within HTML tags (even within the 'style="..."' portions, which if you look at my edits you will see I use extensively), and for wiki pages, the only way to use these remaining ones are through pages such as "[wikiname].common.css," which are rather outside the scope of what a non-sysop should be editing. I can't just put a <nowiki><style> or <script></nowiki> section on an ordinary wiki page, it won't do anything. Granted, .CSS pages can be made for template-specific ones, but I generally prefer to save making a new template for extreme cases as I do not like their overuse since they become too rigid in how they format things (and become highly difficult to preview changes on when there are multiple together). Now, I have had Porple's help in implementing certain CSS functions that require that (such as the rotating item icon for Petey and King Boo on the Double Dash page), but in general I prefer to limit myself to what tools can be done without deep changes to the wiki's functionality. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:32, July 27, 2024 (EDT)
| |
|
| |
| I've noticed people bringing up "consistency with MK7 and MK8 pages" as a reason to revert, which I find rather baffling - I've been doing these in release order, so I ''hadn't gotten to them yet''. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:16, July 26, 2024 (EDT)
| |
| :First, I for the life of me cannot find who even ''mentioned'' Mario Kart 7 in this conversation at all but you, and definitely not in regards of consistency (in fact, my vote is the only one which mentions the old tables match that of MK8 and MK8D). Second, you doing these in release order and thus having applied this style on more games than not, doesn't necessarily mean the argument is invalid. The point is that ''most people liked the old style better'', and your style had been applied ''only by yourself'' without much discussion, if any. If people don't like the new style only you have a (large) hand in, it doesn't exactly matter whether your style is the more consistent one. That's like if I alone were redesigning the tables in all the ''Mario Party'' games by release order, and by the time I got to ''Mario Party 10'', someone told me that they liked the old tables better and likened the old style to those in ''Mario Party Superstars'', and I'd say "Yeah but ''my'' tables are the more consistent one now, and I'm doing them in release order, so it doesn't matter if they should be more consistent with the ''Mario Party Superstars'' ones since I haven't gotten to that one yet". The reason why people are only now saying something about it is that your course tables on Mario Kart Wii are by far the most egregious example, and it looked actually kinda alright on the prior Mario Kart pages (even if they still include some unnecessary things like internal filenames and course BGM, and there wasn't necessarily anything wrong with the old tables there either - hello ''[[Mario Kart DS#Courses|Mario K]][[Special:Diff/4253367#Courses|art DS]]''). {{User:Arend/sig}} 13:51, July 27, 2024 (EDT)
| |
| ::Well, on this page, I think they were brought up on other ones, and I mostly remembered people saying "later ones" (which would include it) and "Mario Kart [number]." And to be fair, I fixed the glaring issues brought by MKW's widescreen screenshots to this style by removing them, and also removed the internal names for it; look at the "retro" section on the page now, it looks a lot better than it did when this proposal was initially made. MKDS's main issue, admittedly, was the battle courses being in a different section entirely; to the point that at first, I thought they were outright missing from the page, their location was so counter-intuitive. And I will metaphorically die on the hill that while the BGM may not be "necessary," it does not hurt anything but ''does'' add more to it, so it's better there than not there by sheer measure of enrichment. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 15:01, July 27, 2024 (EDT)
| |
| :::You still haven't addressed my comment about requiring to include sound effects in item sections, voice files into character sections, vehicle engine sounds in vehicle sections, which are all as equally important, adds more to the article, and as enriching as BGM. {{User:Ray Trace/sig}} 03:20, July 29, 2024 (EDT)
| |
| ::::We don't -have- files for most of those, and sound effects are different from music - mainly because they almost always have more than one per entity. That being said, I'd have no problem with including the select character voice clip, or the engine noises (note that I did include the character-based unqiue victory themes on the SMK character table); most of the items don't really have a distinct audial cue (let alone in a consistent context), though. And apologies for not answering this one sooner, I legitimately did not see it. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 09:53, July 29, 2024 (EDT)
| |
