MarioWiki:Proposals/Archive/49

Use Lists for the Power Moons instead of Galleries
Porplemontage has indicated that for the Power Moons on the Kingdoms pages, we should use a GALLERY of images relating to the position of the moon, along with the name that links to either a TABLE, or to individual articles, which another proposal will be dealing with. I firmly believe we should use a LIST instead of these galleries, and here's why:
 * Easier to scroll through on mobile devices and desktop.
 * Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
 * On mobile the entire gallery is one column.
 * The human eye only needs to move up and down the list
 * The galleries require looking all over the screen and can disorient.
 * Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
 * The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
 * Having a single page open and being able to look back at it when needed is a huge help and time saver.

Proposer: Deadline: November 10, 2017, 23:59 GMT

Support

 * 1) per my proposal

Oppose

 * 1) See my comments.
 * 2) Having a redundant list on the main body article of, say, Cascade Kingdom is pointless (when things are more easily summed up with Header+Main template+Small paragraph explaining the moon count and other criteria) and unnecessary padding to the article when the information users are looking for is best explained in the list pages itself. The reason we even resorted to using tables in the first place is because some of the moons objectives are short enough to fit in there; we don't need a summary of a summary. Keep the listicle in the actual list article itself, and leave the worse, less useful, less informative list out of the main one. Another point I like to add is that the list also adds a ridiculous amount of redundant links that ALL lead to the main article: we need only one link and that's where the Main template comes in handy. If people REALLY wanted to search for a specific moon, that's why we have Ctrl + F in the first place. My position is to delete the small listings altogether and leave only a header + main template + small paragraph.
 * 3) Switch sides again, per Baby Luigi's comment.
 * 4) I have to agree with Baby Luigi. Having a list on the main Kingdom page is redundant since the table already displays the name and location of the Power Moons. The list also creates 60+ redundant links to the table, which is also linked at the top of the list. All we really need is one link to the table, and the list really isn't needed. People can just use [CTRL] + [F] to look up a Moon that they need. All in all, the Power Moons should just be listed on the table (and not on the main Kingdom page). (Although, I also think that the Regional Coins for each Kingdom should be displayed with a picture and description because that's how the blue coins were listed on the Super Mario Sunshine's level articles.) Anyways, that's what I think about the matter - Power Moons on a table (sub-page) and Regional Coins in a "gallery" (main Kingdom page).

Comments
The purpose of this is to determine which way is better for displaying the moons on the kingdom page. Whether they link to a table or article, there will be far more information on the linked page, including the images AND an in-depth description/walkthrough type thing for the power moon. The list will just take up far less space and provide an easy overview for readers.-- 15:33, 3 November 2017 (EDT)

I was going through your arguments, and decided to put my thoughts to them. Overall, I am not for having them as lists due reasons above. 15:49, 3 November 2017 (EDT)
 * Easier to scroll through on mobile devices and desktop.
 * Not by very much. And if you think about the about of time a section loads (at least on a 3DS (I having the 2DS)), not going to be much difference anyway. Galleries on mobile devices like Nintendo 3DS family in general take long to load, but they usually remain black if there is too many.
 * Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
 * I compared your mockup on Metro Kingdom layout (81 moons), and your talking about a whole length of the scroll bar on those pages, which is not a lot.
 * On mobile the entire gallery is one column.
 * On which mobile? I use a 2DS, and I don't remember seeing only 1. But that may be due to me using desktop on my 2DS. But, I checked on a desktop mobile view and I only saw one less image per column than in desktop.
 * The human eye only needs to move up and down the list
 * I hear that humans like looking at better looking things. But, it is also something to not overdue.
 * The galleries require looking all over the screen and can disorient.
 * There is still order in galleries. One can easily look at the system and find the one they are looking for.
 * Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
 * Actually, it's a little quicker finding the moon with a gallery than a list. With a list, readers are going to go to the general area and find it. With galleries, they do the exact same thing. The only difference is that it is found quicker due to there being length. Even in a 1 per column, there are less of the others when this option is done per screen.
 * The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
 * Just the moon names may be all they are looking for. I don't know how Talkatoo works exactly due to not having the game. Even still, we should provide the info. But, if they're not looking for the name, they will most likely not go to the kingdom page, no matter if the moons stay in another article or if they all become separated, but instead use the search bar to do it.
 * Having a single page open and being able to look back at it when needed is a huge help and time saver.
 * We already have another page for that. It can even be convinced to keep it even if all are given articles.
 * When I refer to mobile, I am talking about phones. If you're playing the game, it's less likely you have a computer/laptop open next to you looking at the wiki, and more likely you are on a phone. Talkatoo works by only revealing the name of the power moon, not the location, and he only gives you three at a time. If you only want the names to figure it out for yourself, you're fresh out of look with the galleries because you can't avoid seeing the picture. With list it's easier to not read the description. The list is also better suited as it's the exact same way the game itself displays the power moons, as a big numbered list with the names and a minimap to the side with icons indicating the positon on the map of each moon.-- 15:58, 3 November 2017 (EDT)
 * Oh, a phone. But, not everyone has a phone with the ability to look up stuff. You mention that it is hard not to see the image if it is galleries. There are times when galleries don't actually show the picture, but this seems to only happen if there's either low-broadband or takes a long time to load in general. And even if there is a picture, that picture can help them find the moon, but only if the person looking at the picture can tell where it is. They say a picture is worth a thousand words. Compared to descriptions, I have no idea. As for the last point, I don't know how to say something against it and still be in legal grounds. What I do know is that in-game, it shows a picture of the location if you found it. Is there a way to replicate that on the wiki? Or would that be too much? (both questions are only relevant if this passes.) (Scratch that point. I don't think there is especially for long lists. And it would be too much if we found a way to do it.) As of right now, the gallery seem to do the same thing, except in a different way. 16:20, 3 November 2017 (EDT)
 * I mentioned the use of a map to Steve but I didn't really understand his response so I didn't pursue it. Now, be reasonable, you're not looking up the power moons for Super Mario Odyssey if you don't have a switch or plan to get one, that information is useless, and if you have that kind of money, you have a smart phone, even if it's low end. A smart phone is a necessity for life at this point, not because of addiction or obsession, but because of work and family, especially work! Anyways, you would want to avoid the picture because the moment you see it, you'd recognize where that is, and you lose all the fun of working out where it is based on the name. I know we don't worry about spoiler's here, but it makes for a better presentation for people who need some help but don't want to be outright told where it is, and for those that do, we have that information too. Also keep in mind that there are 103 moons for Mushroom Kingdom, a page that has existed on the wiki since 2011 and serves a purpose for multiple games in the franchise. It would be completely overrun if the gallery were applied to it.-- 16:35, 3 November 2017 (EDT)
 * Galleries have visual aspects. This means that people generally find them more attracted. Lists usually have things pretty close to each other. The rest Porplemontage said for me. As for the last point, Mushroom Kingdom doesn't have either. But, it doesn't have a gallery either. But, if you're still not convinced, Porplemontage also mentions that have lists for longer articles. With this proposal, it removes the possibilities of galleries instead of list no matter what, even on shorter articles. 17:00, 3 November 2017 (EDT)
 * That's not how this works. This proposal is only for the power moon lists/galleries on the kingdom pages. The ruling wouldn't effect other situations.-- 17:02, 3 November 2017 (EDT)
 * That's your argument against what I put? Something I already know? If this passes, is guarantees lists for those articles. Since it is support or oppose, the oppose option doesn't necessary mean that we will stick with galleries for all of the articles that are going to be affected. It means that we won't stick with the lists for all of the articles that are going to be affected.
 * As for the point that I didn't cover in my previous comment, you explained it almost exactly as it is, but sometimes standards aren't always what some people do. But, it's hard to know due to preferences of others. So, generally speaking suits well. 17:21, 3 November 2017 (EDT)
 * I misunderstood what you meant. It sounded like you were suggesting that every article would have galleries replaced with lists, not just the kingdoms. My mistake.-- 17:27, 3 November 2017 (EDT)

Why is there no "use tables" option in this proposal? That's the option I'd want to vote for. 13:29, 6 November 2017 (EST)
 * Because they take up far too much space, even more than the galleries would, and are really not mobile friendly at all. Plus, three pages currently already link to a separate page when a table exists. Another proposal will be made soon to figure out how to handle articles for power moons, and I believe the default option is to link to a table.-- 14:23, 6 November 2017 (EST)
 * After looking through this again and understanding where you're going with this, why do we even need a redundant list in the main body Cascade Kingdom article itself? Just delete the list and let the List of Cascade Kingdom Moon article handle all of the work of describing the details of each Power Moon. 14:42, 6 November 2017 (EST)
 * Because we have to wait for the other proposal to go through first. We don't know if the List of Cascade Kingdom Moon article will stay or not. If the decision is to make an article for every power moon, which I now support, then that page will be deleted. The list on the kingdom page itself will not have an in-depth description of the moons, keeping it simple, because the in-depth part will be on the individual pages.-- 15:03, 6 November 2017 (EST)
 * Shouldn't you wait for the proposal to go through before starting another proposal about this matter first? Also, I still don't think a summary is necessary, considering some moons can be explained in only a few sentences, which is why we're even using the table format in the first place rather than giving them separate articles. 19:55, 6 November 2017 (EST)

One thing that confuses me: the way this proposal is worded doesn't say whether the gallery/list is its own page or part of the main page, but the way you were talking would imply that a gallery would have to be separate while a list would have to be part of the main article, which isn't true at all. Doc von Schmeltwick (talk) 17:12, 7 November 2017 (EST)
 * The list on the main page doesn't have to have an anchor link for every moon to the separate table. At some point someone added those in and I didn't question their existence. The reason this proposal exists before the other proposal is, to my understanding, due to the fact that the lists of power moons on the main pages have to be finished before the other proposal can be started.-- 10:04, 8 November 2017 (EST)
 * I think what happened was... When the list used to be a gallery, someone made each Moon link to the table because of how the gallery appeared on mobile (one picture per line). Then, the gallery was reverted back to a list, and the anchor links to the table just stuck around. --Legomariofanatic (talk) 19:09, 8 November 2017 (EST)

Make indenting comments during discussions an official rule
You know, when I was just discussing with my good friend Black Lightning when he reminded me to indent my comments, he told me that indenting comments during discussions was an unwritten rule that the wiki abided by. I started to think, why not make this an official rule? So that's the point of this proposal, why not make indenting comments during talk page discussions an official rule? The rule will state that all participants in a talk-page discussion must indent their comments, but after around five to seven colons have been used to indent comments, the bar will reset to zero, and the cycle goes on and on until the discussion ends. This would be a great rule to increase the efficiency and effectiveness of all talk-page discussions. However, unlike most rules, there will be no punishment for violating this rule, as it's more of an official guideline than an official rule, although very occasional reminders will be given. The official rule part is to make it so that all autoconfirmed users do it regularly and get in the habit of indenting their comments early on in their work on the wiki. Proposer: Deadline: November 11, 2017, 23:59 GMT

Support

 * 1) I'm sticking with my proposal.

Oppose

 * 1) 1) I strongly disagree with the cycle resetting to zero. It would be better if it just stopped and stayed at seven. 2) It wouldn't really increase the efficiency of talk pages since pretty much everybody follows it anyway. You can't solve a problem that isn't there. If it ain't broke, don't fix it. 3) "Good friend" is really stretching it. "Acquaintance" maybe. Nothing personal, but, as my page says, I don't do internet friends.
 * 2) No. This type of rule works best as a guideline rather than something users can get reminders and warnings for, and I think this veers almost on common sense at this point. To be frank, this isn't something major enough to be addressed, and as Ultimate Mr. L said, most people already abide by it anyway, so there's no point in making this a rule.
 * 3) Per all.
 * 4) - Per all. In most instances it's just common sense, and making not following it punishable with a reminder/warning does not sound like a good idea.
 * 5) - Just indent your discussions like people have been telling you. No need to shoot your foot off.

Comments
THANK YOU! It FINALLY did what I wanted it to do, which is show up as a black header and not a bunch of code. Anyway, you don't need to apologize, Black Lightning. We've all got our opinions, and no one can take them away from us, even if their life depended on it. In the end, that's all that matters. And by the way, I meant "good friend" as in quite literally, "good friend". I didn't mean to use the specific Internet term. 22:56, 4 November 2017 (EDT)
 * Not sure what's with that glitch, it seems to happen every other time a new proposal is made. Encountered it at my first proposal and its shown up form time to time ever since. It fixes itself as long as there some code under the section. As for the friend thing, I mean I haven't met you face-to-face and therefore do not consider you a friend. But this really isn't the place for this conversation.
 * 23:00, 4 November 2017 (EDT)

Help:List <- Closest thing to a written "rule" I can find. 22:04, 5 November 2017 (EST)
 * By the way, I should point out that while not indenting comments is not currently a warnable offense, it is equally minor as forgetting italics, which is as it is detailed on this user's talk page. Drawing from that user's example, if not indenting comments were to become a warnable offense at all, it should only get serious after the user in question is reminded about it more than ten or so times. 16:28, 7 November 2017 (EST)
 * The difference is, I think user space dealing with formatting are lot more lenient on formatting than writing formatting stuff on actual articles. For example, we encourage people to not copy paste raw signature coding all over the people's talk pages whenever they sign, but that rule is not enforced all that often...indenting is even more minor than that, I say. 21:26, 7 November 2017 (EST)
 * @Toadette the Achiever Non-italicizing is something that shows up on articles random people read, while indenting is a talk page thing. I'm not sure how I can explain it any better.
 * 21:44, 7 November 2017 (EST)

Oh, come on, can I ever get any proposal I make to get off the ground and start running? I always seem to epically fail with every proposal I make. Anyway, don't mind me here, I'm just being good old me. 21:45, 7 November 2017 (EST)
 * Complaining isn't going to help you, if anything it will make you look bad. Sometimes proposals just don't go in your favor. One of the points of a proposal is to see what others think, and this is what they think. 21:47, 7 November 2017 (EST)
 * Proposals pass if they are well-thought out and have a decent point to make. Most of the ones you proposed are usually neither. 22:42, 7 November 2017 (EST)
 * I admit that it's difficult to come up with good proposals every now and then, and let's be honest, it's ESPECIALLY difficult to come up with flaws and counterarguments that could be presented to the proposer when they already made their proposal. Just take the commentary as advice, and it'll flow smoothly. 23:25, 7 November 2017 (EST)
 * Well, that's why I usually discuss things in forums or in Discord chat before I enact anything major. 23:28, 7 November 2017 (EST)

Create a template for proposer and deadline parameters
Yet another measure intended to improve how proposals are added to pages. You can find the details here. Basically, my proposal is that we change the parameters for the "Proposer:" and "Deadline:" parameters from hardcoding into a template. This will also (quite obviously) mean that previous archives must be temporarily unprotected to enforce these changes. Proposals like these have received near-unanimous support in the past; we have all of these, to name a few, so how does this fare?

Proposer: Deadline: November 14, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Templates are for reducing redundant and common markup into an easy-to-use code. We went through it once before.

Oppose

 * 1) Why? This just seems like it unnecessarily complicates the whole process. It's perfectly readable as-is and doesn't take up a notable amount of space.
 * 2) - Per Time Turner. This seems to be trying to solve a problem that doesn't exist.
 * 3) Templates are annoying to use as-is, and what I saw when I viewed the source of that example didn't make me particularly welcoming of this idea. It's just easier to do it the way we've been doing it.
 * 4) Per all. I don't see how this makes things any easier.
 * 5) Per all.
 * 6) - Per all.
 * 7) - Thought about it, and nah, current markup is already simple. Really the only thing you need to remember is the   code.
 * 8) The proposal markup is right there, above the TOC. Copying and pasting is not difficult, and it's not like the markup is complicated to begin with.
 * 9) Per all
 * 10) Per all.

Comments
@MrConcreteDonkey: The problem is that I have seen countless poorly formatted proposer/deadline parameters. 17:30, 7 November 2017 (EST)
 * I haven't noticed anything like that, and even still it's much less hassle to just fix them separately, rather than editing every proposal in every archive. 17:39, 7 November 2017 (EST)
 * Your argument is still flawed; all of these, to name a few. 17:52, 7 November 2017 (EST)
 * But this doesn't make things any more convenient, and it doesn't provide any added insight for future readers. How is this better than manually inputting it? 18:24, 7 November 2017 (EST)
 * It's been fixed. 18:44, 7 November 2017 (EST)
 * It has not. Doc von Schmeltwick (talk) 18:53, 7 November 2017 (EST)
 * You've only added the list from your most recent comment to the proposal, and haven't addressed our concerns. How is introducing more complicated formatting going to combat poor formatting? 19:46, 7 November 2017 (EST)

Somewhat related, but I have had a way to streamline calculating proposal deadlines 1 or 2 weeks in advance, but no one responded: MarioWiki talk:Proposals/Header It won't go into the template, but it will replace, found in  (/Header). --

@Wildgoosespeeder: Is our current system not easy-to-use? 09:43, 8 November 2017 (EST)
 * Replacing text is kind of a hassle because trying to preserve formatting. That's why I proposed the template a while ago. Also don't forget . -- 00:32, 9 November 2017 (EST)
 * What text is being replaced? 22:45, 9 November 2017 (EST)
 * This is what is looking to replace with User:Toadette the Achiever/PParameter as a sandbox template.
 * Test:
 * Test:


 * Seems to be working OK. -- 00:19, 10 November 2017 (EST)
 * But is too complicated for the purpose it's trying to fill. The current formula can at least be realistically remembered without copypasting from a different tab. Doc von Schmeltwick (talk) 00:21, 10 November 2017 (EST)
 * But the parameters still need to be explained. Nothing is actually being replaced here. 00:21, 10 November 2017 (EST)
 * Too complicated? Does that mean that and  are too complicated as well ? It's not hard. The sandbox template has documentation how to use . If you want the code to be   instead of , just let  know. Also the name of the template can change later. -- 00:27, 10 November 2017 (EST)
 * It's complicated because there's like 3-4 separate blanks on there, which in my opinion is too many. And again, there is no point to it. Doc von Schmeltwick (talk) 00:34, 10 November 2017 (EST)
 * Template coding is possible to make two of the four parameters optional to specify (proposer and deadline mandatory, start and withdrawn optional). I think that the template is like that already. Only thing left to do is to simplify the code by using,  , etc.. See  or  for exact code how things are achieved. -- 00:56, 10 November 2017 (EST)
 * It doesn't matter what's possible for the system what matters is human limitation for a thing that gets used like 3 times per week. And again, it is completely unnecessary. Doc von Schmeltwick (talk) 01:11, 10 November 2017 (EST)
 * I think you are making it more complicated than it actually is. What you will be typing is  (if the template is coded to use ,  , etc. instead). The proposed template page doesn't make it clear what the effects are compared to what I did when  was first proposed. Maybe that is what you are concerned about? -- 01:24, 10 November 2017 (EST)
 * And this is simpler than what we have in place currently how? And why on earth would it be "PParameter?" Doc von Schmeltwick (talk) 01:25, 10 November 2017 (EST)
 * Replacing text of the hard-coded copypasta version is a hassle. That's why templates are a thing. Also templates formalize and standardize things. For the name, I said that it can be changed later. Nothing is absolute. That's what a proposal is for. What would you call this template? -- 01:34, 10 November 2017 (EST)