Organization discussion thread (everyone please weigh in)
Posted by: bbbbbbbbba
Date: 2019-09-02 03:10:33
The wiki needs better organization, and we need as much input as possible (especially "oldbies" who are more familiar with the site). Any form of discussion (reply, Discord, PM, wiki talk pages, etc.) is welcome. Below, I have outlined the main problem I see with the wiki (disagreement between "scientists", "artists", "technologists", and maybe "historians"), and I want your input on how we might solve this problem, or why this might not be a problem.
I have also proposed some solutions of my own, in the section titled "Proposals" (with four subsections, although now I think about it, only the first subsection is a direct answer to my own problem, and the other three are just organization ideas in general…), so if you want to see concrete proposals (instead of some abstract analysis), feel free to skip ahead.
[size=20pt]Introduction[/size]
After a long PM thread with Sherkel, I decided to make this public in the form of a forum thread. We both agree that the wiki is currently lacking in proper organization, a discussion is needed to decide what we should do to fix that, and that discussion should involve as many people as possible. Lack of organization is a serious problem, as it frustrates users and (potential) contributors alike. A new user — indeed, probably any single user — is powerless to fix a systematic problem, and that is why we need a public discussion, in order to come up with something most people would agree with.
One of the reasons that deterred me from doing this earlier is that I am not very comfortable with the GCL forum. Maybe the UI is not as friendly as could be, and maybe it is just me. But I suppose I might not be the only one who don't want to post on the forum for one reason or another. If you have anything to say, I encourage you to join the discussion in whatever form you are comfortable with. Ping me on the GCL Discord (I am suggesting a new channel for wiki discussion, but until then, #glitch-general should do), private message me, edit my user talk page, or any other talk page if appropriate.
[size=20pt]The problem with being a "catch-all" site[/size]
As Sherkel has said in a PM, GCL "has always been a 'catch all' for all forms of glitchology, much as Bulbapedia is to Pokémon." I think this is an ambitious goal. This approach surely has its advantage: We don't exactly have a large user base, so we want to retain as much of it as possible. However, I believe this approach also has an apparent problem. To quote myself:
The way I see it, there are at least three, maybe four, approaches to Pokémon glitching: as a science, as an art, as a technology, and maybe as a history. (In case you didn't notice, I'm firmly in the "science" camp.) Those approaches pull the site in different directions.
(To be clear, Sherkel's statement above is in response to my statement above, instead of vice versa.)
This is another reason why we want to hear as many different voices as possible!
This clash might show on multiple levels. I have analyzed this on the individual page level, specifically regarding the glitch pages (pages that document individual glitches) because I believe that is the most important component for a glitch site.
I think the first thing should be to figure out what we want our "Project Glitch" pages (pages that document individual glitches) to look like. And here we can already feel the tension. Even though everyone would agree that a glitch page needs an introduction, a procedure, and a result:
[li]The glitch scientist wants the procedure to be as general as possible, covering all the examples and exceptions to our best knowledge. There should usually be an explanation section — or explanations should accompany each step of the procedure, in the case of particularly complex glitches. If the desire for generality means that the result could only be stated in technical terms, so be it.[/li]
[li]The glitch artist wants to document all the cool results observed. That sometimes means documenting a lot of slightly different procedures individually. It doesn't matter if the results cannot be reproduced — it might be preferable if they cannot be reproduced.[/li]
[li]The glitch technologist wants it to be as easy as possible to use the glitch. That means concrete and detailed procedures that even a newbie can follow, preferably also optimized for simplicity (a 5-Pokémon setup should obsolete a 20-Pokémon one). Useful results are prioritized.[/li]
(My portrayal of the latter two attitudes are not necessarily accurate.)
My point is that those goals clash with each other on how to write the procedure and the result. It would be one thing, e.g., if I only wanted a separate section for explanation. But in an article describing a glitch, all the sections are related to the others. It's not like Bulbapedia Pokémon pages, where the "game data" section could be completed without even knowing what the rest of the page is going to look like.
And so this is a puzzle that needs to be solved.
To put it another way, the clash is between concrete and optimized procedure / general all-encompassing procedure / all the individual procedures.
(I.e. it's not simply that technologists want procedures, scientists want explanations, and artists want results.)
[size=20pt]Proposals[/size]
[size=14pt]Collapsibles ("folders")[/size]
The reason I wrote about the "clash" is because I felt it. There are long stretches of contents on the wiki that I don't want to see. Conversely, when I write about technical details, I often worry that they are long stretches of contents that other users might not want to see. Those long stretches of unwanted contents disrupt the flow of reading.
Maybe the problem can be solved by hiding them away, but only one click away. A link to another page can do that, but some things don't warrant creating a separate page, and having to click links is disruptive in its own way. I think collapsibles ("folders") is a better way of doing the same.
Collapsibles are boxes you can "expand" and "collapse". Template:Major glitches is an example. Apparently, they are a MediaWiki feature, but the wiki code for them is kind of difficult to understand. To make collapsibles something everyone can use, we need to make a template for them.
After we have the template, we need to begin editing existing pages to include them. This would sets up examples on how to use them, so that new contributors might be able to finish the job, and new pages would be able to catch on. Trainer escape glitch might be a good first page to try. It is a complex glitch with many moving parts, and as a result many sections that might benefit from being collapsible.
[size=14pt]Templates[/size]
Wiki templates are great. They make what would have been a complex mess of HTML code (or just a lot of text) easy to use, and easy to maintain, too. I believe if we use them correctly, they can make the wiki more friendly to new contributors, which is exactly what we want.
I'm not familiar with the MediaWiki framework, so I don't really know what can be templated. I do feel that it is difficult to make a table that looks good (like The Big HEX List), so if a template can help with that, that would be awesome. There might be things I am forgetting for now…
Edit: Let me just begin listing things I might want.
[li]"PK" and "MN" symbols that render like how they look in-game, and copy as something relatively unambiguous (e.g. "<PK>").[/li]
[li]A "glitch infobox" template.[/li]
[li]The existing YouTube template should allow an optional parameter for a timestamp. Furthermore, the visibility of that template could be improved (it can be difficult to see a small strip of text centered in a page, especially when it is the only thing in a section).[/li]
But more importantly, to make templates really work, we need to advertise them. I believe the MediaWiki allows a message to be displayed on the "edit page" UI. We should put some commonly used templates there so that new contributors would know to use them. That also saves contributors the trouble of finding them from other pages. That can also include things that are not strictly templates, but people might need to copy-paste from somewhere else anyway, like the word "Pokémon". (I got the idea from another wiki site (in Chinese). And yes, the idea of using collapsibles extensively also came from that site.)
[size=14pt]Style guide[/size]
We have a manual of style, but I feel that it can use some additions.
One problem that concerns me the most, the formatting of hexadecimals, has been brought up before (although I also want to unify the capitalization, and that thread didn't mention that "hex:E9" and "hex E9" are also used ). I disagree with the resolution:
Wow…such evenly spread votes all the way across the board. Ironically, after having starting this poll I'm leaning toward it not being important enough. A few reasons:
1. The opinions from what we can see of the userbase are so divided that a unilateral change would be disliked by most users, no matter what it ended up being.
2. There are a lot of articles on the wiki. Originally I thought it would be best to catch this and set a standard on it before the page count grew even higher, but for about 3,400 pages at the time of posting this, there'd need to be a very pressing reason. Speaking of standards…
3. The wiki doesn't have strict style standards and never has. We have the manual of style, but that's just enough to prevent it from looking like articles were thrown together by elementary schoolers in seconds. I haven't seen any violations of that thanks to the QC team, but pages are written in all manners of different writing and organizational styles. This includes aspects like notation. Information is our first priority; if we had an editor base of hundreds, we could strictly look over every page and edit even the slightest deviations from what we consider the most proper style, but that's not the case right now.
Oh well, maybe this was a bit needless. Or was it not? More input about the wiki is always welcome, in this thread or elsewhere.
My counterpoints:
1. The poll didn't have an option "anything, as long as it is consistent". I think it is rather likely that most people who voted on any of the first four options would be more OK with any of the other three than with the status quo.
2. Well, I am already proposing across-the-board changes. And we don't actually need to go over 3,400 pages. Simply put something in the manual of guide, and edit some major pages to establish the rule, maybe mass edit Dex pages with robots — I believe the rest will be brought in line in time.
3. We might not be able to look over every page, but we are able to look over every future edit. In this regard, our lack of wiki activity (especially new contributors) could actually be an advantage. We can put something above the edit area to the effect of: "We are serious about our style guide, but don't worry about it if you are new to the site. Our staff will review any edits and gladly fix any style problems for you!" I don't think that would be a deterrent to any new contributor.
Actually, I believe the status quo of inconsistency may be a deterrent to some new contributors. How so? Editing the wiki is mostly thankless work. I think most people do that because they believe they are creating something good. And inconsistency does not look good — at least to the conformists it doesn't. So those inconsistencies may be enough to make them think again about contributing.
It might be argued that there are more non-conformists out there than conformists. But even then, I don't think the approach of "feel free to edit, staff will catch problems" would alienate non-conformists. It might alienate anti-conformists, but I don't believe anti-conformists would be a significant portion of the crowd. Maybe we can also mention that we are open to exceptions, as long as there is a good reason — that can be determined on a case-by-case basis.
As a bonus, if we can make it a wiki task to fix the pages to adhere to a more strict style guide, it might well incentivize some lurkers to contribute! It isn't unthinkable that, having gotten comfortable with wiki editing, they go on to contribute in other ways, like bringing new information to the site, right?
Some other things that might be unified with a more strict style guide:
[li]Capitalization of X and Y (as in coordinates).[/li]
[li]Capitalization and formatting of register names. In particular, the register [tt]a[/tt] needs something to distinguish it from the English word "a".[/li]
[li]Really, capitalization of everything.[/li]
[li]Whether to use spaces around operators (+, =, <=, etc.).[/li]
[li]… Suggestions are welcome![/li]
Those are not exactly priorities, but I think we can begin by implementing some items where there are no strong arguments for inconsistency, and there are no strong arguments against every option. Those can be discussed in separate threads if necessary.
[size=14pt]CSS[/size]
I've brought up one problem with the CSS before, and I have since decided that other problems are also in need of fixing. The reason I decided to bring it up here is that I feel that CSS problems cause organization headaches:
[li]Bulleted lists are a useful tool for organization, but editors may be discouraged from using them because nested/multiline bulleted lists are ugly.
[li]Numbered lists are even more ugly (I've never seen a number followed by a bullet anywhere else).[/li]
[li]Different section headings are of the same size, making it hard to see the structure of a page from a glance.[/li]
[li]The color of links are almost indistinguishable from normal text. This discourages intelligent potholes and encourages cramming all the information in one page.[/li]
Currently, I use the Stylish plugin for Chrome to give myself a better viewing experience. But I would surely prefer those changes to be incorporated to the site's CSS. I am no expert of CSS, and I don't know whether those settings would look as good on mobile, or if they would break something else (as I mentioned, I don't use the forum often), so I would appreciate it if someone with experience in CSS could help to implement it.
P.S. I've already realized one potential problem: My bulleted list fix didn't take into account the font size, making bullet points in e.g. forum quotes slightly off. If anyone knows a more correct way to do this, please let me know.
/* Bulleted lists */
li {
background-position: left 5px;
}
/* Numbered lists */
ol > li {
background-image: none;
padding-left: 0;
}
/* Numbered lists on the forum */
ul[style="list-style-type: decimal;"] {
padding-left: 1.5em;
}
ul[style="list-style-type: decimal;"] > li {
background-image: none;
padding-left: 0;
}
/* Bulleted lists in the "Categories" line on the bottom of wiki pages */
.catlinks li:first-child {
padding-left: 0.6em;
}
.catlinks li {
padding-left: 0.6em;
}
/* Link color.
Not sure if this color works for everyone, but it is more distinguishable and also doesn't look out of place to me. */
a:not(.new) {
color: #778899;
}
/* Some links on other parts of the site shouldn't have the above applied */
.dropmenu a {
color: #000000;
}
.catbg a {
color: #FFFFFF;
}
.table_list .header td.catbg a {
color: #515151;
}
/* Section headings */
h2 {
font-size: 1.5em;
margin-top: 0.5em;
}
h3 {
font-size: 1.17em;
margin-top: 0.5em;
}
h1, h4, h5, h6 {
margin-top: 0.5em;
}
/* Code */
pre {
font-size: 130%;
}
code {
font-size: 130%;
}
[size=20pt]Beyond page-level[/size]
My above proposals are mainly about how to let users easily find information they need, and contribute information they have, on an individual page. They don't address the issue of how to let users find an interesting page in the first place. Part of the problem, again, is that different users find different pages interesting.
The problem of categorization has been brought up, too. That thread died down without a real conclusion, and I guess that was at least partly my fault. At that time, I already had some vague idea of the problem:
I think the advantage of your system is that it singles out the most interesting glitches to the average player (1B and 2A); however, the most interesting glitches to the average glitcher are probably different.
I didn't have the "science/art/technology/history" idea then, though. Now that I have a better idea of the problem, I want to ask for suggestions again. Maybe more than one categorization system co-existing is the way to go.
Actually, it doesn't seem like a bad idea to explicitly mention this "division" on the front page or the sidebar, and portray it in a positive light. It would help everyone find what they need, and also reinforce the idea that we are indeed a "catch-all" site for all aspects of glitching.
Other random ideas:
[li]A navigation bar on Dex pages, like the one Bulbapedia has on Pokémon pages, would be nice.[/li]
[li]The "Random page" button can be split into "Random (major) glitch", "Random glitch Pokémon", etc.[/li]
[li]Related to the above suggestion, I want to cut down on the number of uninteresting pages, even Dex pages. Would it be fine to, for example, make ItemDexES/RB:094 a redirect to ItemDex/RB:094? I believe they act identically except for the name, which can easily be acknowledged on the latter page. And yes, I don't see any problem with a page with multiple navigation bars either, as long as they are thin enough.[/li]
I will keep this section short, not because the problem of page visibility is not important, but only because I haven't been thinking about this part of the problem too much, and this post is getting long enough. Maybe I will expand on this section later, factoring in whatever input I get.
[size=20pt]Conclusions[/size]
To reorganize the wiki is going to be a huge project no matter what. I am willing to help, but only if I believe it would make more people here happy than not. Again, we need as much input as possible. Please let me know whether you agree or disagree with my interpretation of the problem and my proposals, and if you have different proposals. I hope that we can get to a consensus before taking any large-scale actions, which I believe is needed now.