# Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

## Wiki Discussion

### Organization discussion thread (everyone please weigh in) - Page 1

Previous Page

- 1
- 2
- 3
- 4

Next Page

#### Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-02 03:10:33
[size=20pt]TL;DR[/size]
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]
[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.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Parzival
Date: 2019-09-02 09:01:34
I'd love to see TVT-style/AR-styke folders here, tbh.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: coloradohugge
Date: 2019-09-02 10:13:06
I totally agree with the css question. There are some things that can sometimes be difficult to differenciate (such as links like you mentioned)
I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Torchickens
Date: 2019-09-02 11:49:15
Collapsible folders sound good!
I haven't read all of this properly yet sorry, but regarding the scope of the wiki, I relate with that how we cover not just glitches, but also data, terms, unused content, recently a little speedrunning content. If it was focused on just glitches/data with terms etc. in like an appendix page then I suppose that would organise the wiki better as most pages would be examples of glitches with a method or the database pages. At the same time (though no one has said it), it feels a shame to let them go, and it's a double-edged sword as you said.
The style has a lot of inconsistency yeah. A lot of it is my fault. Sometimes while perfection is overrated, it would be good to have a style convention not just for the Dex articles, so that most instances of hex: hex 0x $ etc. are kept under one notation.
I agree with cutting down on very similar pages and merging them (ItemDexES/RB:094 and ItemDex/RB:094), though otherwise disagree personally with "interesting" as it's subjective and there are various small but unique glitches (e.g. https://glitchcity.info/wiki/Ragon_Pok%C3%A9dex_entry ). However, these could be merged somewhere as well (like Bulbapedia's 'list of glitches in Generation I', we have list of natural glitches, and Ragon could be under a list in a different article list for non-natural glitches (I'm unsure though, I don't know how we would organise everything together?)) and we could set some criteria of which glitches get their own article) and we've had a pattern of keeping articles for very small glitches without any (known) additional uses (e.g. https://glitchcity.info/wiki/Stand_on_a_tree ), while Bulbapedia would just include them on a list of glitches page. However, some of Bulbapedia's list of glitches pages are quite long as well.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-02 12:41:10

> I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.

Can you elaborate on what you mean by a "dashboard"? Do you mean just like what is going on with the "major glitches" template (go to a page using that template to see it in action)? That could be nice if it is used on every page, but as of now, I think it may have too low a visibility.
(Honestly speaking, the "major glitches" template is currently a little of a mess, with some pages it links to (in the "'Core' glitch" column) not linking to it, but that's mainly because of an inherent problem with the category "major glitch": While many ways of categorizing a glitch is subjective, the definition of "major glitch" turns the subjectivity up to eleven. It can even be self-fulfilling because of the "well-known" clause.)
Actually, I have considered adding (multiple) navigation bars to every page, just like what is going on at the bottom of any random TVTropes page. Of course the order would have to be arbitrary (e.g. alphabetical order), but the point is just to give the reader a "tour" through pages in the same category. It would be more eye-catching than the collapsed "major glitches" template because it would have two page names to pique interest.

> Collapsible folders sound good!
> I haven't read all of this properly yet sorry, but regarding the scope of the wiki, I relate with that how we cover not just glitches, but also data, terms, unused content, recently a little speedrunning content. If it was focused on just glitches/data with terms etc. in like an appendix page then I suppose that would organise the wiki better as most pages would be examples of glitches with a method or the database pages. At the same time (though no one has said it), it feels a shame to let them go, and it's a double-edged sword as you said.
> The style has a lot of inconsistency yeah. A lot of it is my fault. Sometimes while perfection is overrated, it would be good to have a style convention not just for the Dex articles, so that most instances of hex: hex 0x $ etc. are kept under one notation.
> I agree with cutting down on very similar pages and merging them (ItemDexES/RB:094 and ItemDex/RB:094), though otherwise disagree personally with "interesting" as it's subjective and there are various small but unique glitches (e.g. https://glitchcity.info/wiki/Ragon_Pok%C3%A9dex_entry ). However, these could be merged somewhere as well (like Bulbapedia's 'list of glitches in Generation I', we have list of natural glitches, and Ragon could be under a list in a different article list for non-natural glitches (I'm unsure though, I don't know how we would organise everything together?)) and we could set some criteria of which glitches get their own article) and we've had a pattern of keeping articles for very small glitches without any (known) additional uses (e.g. https://glitchcity.info/wiki/Stand_on_a_tree ), while Bulbapedia would just include them on a list of glitches page. However, some of Bulbapedia's list of glitches pages are quite long as well.

Actually, I suppose MediaWiki has multiple ways to separate "primary" content and "secondary" content, such as subpages and namespaces. I haven't studied those mechanisms in detail, but I think it's likely that there exists a good way to move the "secondary" contents out of the way without actually letting them go. (Although it might be necessary to let them fall behind for a while, when we first sort out the organization for our "Project Glitch").
I agree that "interesting" is very subjective. There is another criteria that is still subjective, but maybe less so: On a page level (i.e. not considering the navigation problem), do we lose anything by merging those pages? Or maybe in contrary, we gain something by presenting the contents together? I strongly believe that ItemDexES/RB:094 and ItemDex/RB:094 are the latter case (we gain something by emphasizing the fact that international versions are generally similar to each other, including in terms of memory layouts, etc.).

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: GARYM9
Date: 2019-09-02 15:17:35
I will take more time to read this topic later today, but at a quick glance, the CSS problems are heavily tied to the archaic SMF 2.0 system and 2.1 is yet to release fully (but is in final release candidate stage). Graphical site work can be done after its release.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: coloradohugge
Date: 2019-09-03 00:53:57

> > I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.

> Can you elaborate on what you mean by a "dashboard"?

Tree Folder Structure

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Parzival
Date: 2019-09-03 10:26:21

> > I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.

> Can you elaborate on what you mean by a "dashboard"? Do you mean just like what is going on with the "major glitches" template (go to a page using that template to see it in action)? That could be nice if it is used on every page, but as of now, I think it may have too low a visibility.
> (Honestly speaking, the "major glitches" template is currently a little of a mess, with some pages it links to (in the "'Core' glitch" column) not linking to it, but that's mainly because of an inherent problem with the category "major glitch": While many ways of categorizing a glitch is subjective, the definition of "major glitch" turns the subjectivity up to eleven. It can even be self-fulfilling because of the "well-known" clause.)
> Actually, I have considered adding (multiple) navigation bars to every page, just like what is going on at the bottom of any random TVTropes page. Of course the order would have to be arbitrary (e.g. alphabetical order), but the point is just to give the reader a "tour" through pages in the same category. It would be more eye-catching than the collapsed "major glitches" template because it would have two page names to pique interest.

> > Collapsible folders sound good!
> > I haven't read all of this properly yet sorry, but regarding the scope of the wiki, I relate with that how we cover not just glitches, but also data, terms, unused content, recently a little speedrunning content. If it was focused on just glitches/data with terms etc. in like an appendix page then I suppose that would organise the wiki better as most pages would be examples of glitches with a method or the database pages. At the same time (though no one has said it), it feels a shame to let them go, and it's a double-edged sword as you said.
> > The style has a lot of inconsistency yeah. A lot of it is my fault. Sometimes while perfection is overrated, it would be good to have a style convention not just for the Dex articles, so that most instances of hex: hex 0x $ etc. are kept under one notation.
> > I agree with cutting down on very similar pages and merging them (ItemDexES/RB:094 and ItemDex/RB:094), though otherwise disagree personally with "interesting" as it's subjective and there are various small but unique glitches (e.g. https://glitchcity.info/wiki/Ragon_Pok%C3%A9dex_entry ). However, these could be merged somewhere as well (like Bulbapedia's 'list of glitches in Generation I', we have list of natural glitches, and Ragon could be under a list in a different article list for non-natural glitches (I'm unsure though, I don't know how we would organise everything together?)) and we could set some criteria of which glitches get their own article) and we've had a pattern of keeping articles for very small glitches without any (known) additional uses (e.g. https://glitchcity.info/wiki/Stand_on_a_tree ), while Bulbapedia would just include them on a list of glitches page. However, some of Bulbapedia's list of glitches pages are quite long as well.

> Actually, I suppose MediaWiki has multiple ways to separate "primary" content and "secondary" content, such as subpages and namespaces. I haven't studied those mechanisms in detail, but I think it's likely that there exists a good way to move the "secondary" contents out of the way without actually letting them go. (Although it might be necessary to let them fall behind for a while, when we first sort out the organization for our "Project Glitch").
> I agree that "interesting" is very subjective. There is another criteria that is still subjective, but maybe less so: On a page level (i.e. not considering the navigation problem), do we lose anything by merging those pages? Or maybe in contrary, we gain something by presenting the contents together? I strongly believe that ItemDexES/RB:094 and ItemDex/RB:094 are the latter case (we gain something by emphasizing the fact that international versions are generally similar to each other, including in terms of memory layouts, etc.).

Kinda like the one at the bottom of this page, maybe?

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-03 18:26:57

> Kinda like the one at the bottom of this page, maybe?

Yes, that's exactly what I mean.

> > > I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.

> > Can you elaborate on what you mean by a "dashboard"?

> Tree Folder Structure

Oh. I think whether this works will depend on the solution to the categorization problem; for example, I suspect it might not work well with a multi-aspect categorization system.
I probably should first give my own input on the categorization system, then. I realize that my proposal last time is probably too complex to implement. So this is my attempt to capture the "scientist" perspective in a simple and clear way:

[li]Pages with explanations.[/li]

[li]Pages with incomplete explanations.[/li]

[li]Pages that need an explanation (AKA: explanation_request).[/li]
[li]Pages that don't need an explanation. (Those can be just left out of this classification system; I just want to emphasize that those page exists, in no small volume, and that is a healthy thing because glitchology is not just for scientists.)[/li]

Incidentally, I am thinking about adding a glossary page, for some recurring concepts that may not be intuitive for the average player, like "0-based", "jump table", "save clear", etc. Those concepts are exactly what would be "not interesting enough" for an individual page, but would benefit from having a brief description to link to, instead of having to either be explained in-line or left unexplained.
Edit: I got the glossary page started. Everyone is welcome to edit that page (as is any other page under my user page, which I clarified on my user page just now). Although I am faced with a technical problem right now: It seems that the items on the Glossary page are not anchored (i.e. a "[[#count byte|count byte]]" would not jump to the corresponding item), and I would have to do it manually like this or this. Is there a better way, or is there an advantage in using explicit anchors for every term that I'm not seeing?

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Ryccardo
Date: 2019-09-04 08:24:54
Too long of a post delving into different points!! :P
Anyway:
Fully agree that the current (vertically centered) bullet points are an eyesore as is the trashy strolling - and while we're talking about theme edits, yes a bigger visual difference between heading levels woild be better both in general and for my next point;
Not a big fan of hard-stuffing "core" content into click-to-expand blocks (but I find reasonable the Wikipedia/Bulbapedia system of folding each ==h2 heading== section into its own collapsible element on mobile themes);
I don't see how the "different personalities" in your example would be conflicting - surely there can be sections for a beginner-friendly explaination, one for a technical one*, an "academical" use, and examples of results/applications - plus of course* notes on the discovery, historical use, etc?
(The ones marked * are my personal interests, by the way :) )
An example could be an hypothetical edit of the old man glitch to remove duplication of the information found at "Left-facing shore tile glitch", splitting off the "traditional Missingno glitch" to a separate article (with historical notes, but referring to the two glitches it combines for further information), while providing a link to this new page as application examples?
As for hexadecimal style, could it be possible to have some markup/template around a number that the server would process into an user-selectable style, like with dates? (My personal choice would be "nothing at all if it's obvious from context, like having letters in it or being in an appropriate table column, anything goes if it needs to be called out")

> Although I am faced with a technical problem right now: It seems that the items on the Glossary page are not anchored (i.e. a "[[#count byte|count byte]]" would not jump to the corresponding item), and I would have to do it manually like this or this. Is there a better way, or is there an advantage in using explicit anchors for every term that I'm not seeing?

I don't have an answer about the cause, but I think the automatic heading-to-anchor system of mediawiki is problematic - it unsurprisingly breaks down when a title is edited, it fails when a title is repeated multiple times (as seen in our "text errors" page), … so I'd say that you can't go wrong by doing it manually :)

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-04 14:33:33

> Not a big fan of hard-stuffing "core" content into click-to-expand blocks (but I find reasonable the Wikipedia/Bulbapedia system of folding each ==h2 heading== section into its own collapsible element on mobile themes);

Ideally the content folded away would not be "core" (although I'm not sure what you actually mean with this term), but just some details that are considered important by at least one type of glitcher.
The way I see it, collapsible sections serve the same function as a table of content. It can be a fine system if there is a way to design the sections so that everyone can find what they need by section headings. I think that might be difficult (see below).
Incidentally, there is another kind of collapsible element: the "note"s of TVTropes that expand in-line (example; search for "note"). They may be more convenient depending on the exact circumstances, so it would be nice if we can implement those, too.

> I don't see how the "different personalities" in your example would be conflicting - surely there can be sections for a beginner-friendly explaination, one for a technical one*, an "academical" use, and examples of results/applications - plus of course* notes on the discovery, historical use, etc?
> (The ones marked * are my personal interests, by the way :) )

The problem, as I see it, is that each personality wants an entire narrative, not just a section. For example, not only do we need a "beginner-friendly explanation", we also need a "beginner-friendly procedure" (that is not described in technical terms) to go for it. Burying all those sections in a lot of technical stuff is not beginner-friendly. It may be better if we keep those sections consecutive, but at that point, we might as well have several different pages.
Splitting every glitch page into several different pages is actually something I've seriously considered. Like how Wikipedia has "Introduction to ..." pages, or how TVTropes has "Funny", "Heartwarming", "NightmareFuel", "TearJerker" subpages for works, this might be a viable approach to solve the problem of too much information (also known as TMI). Ultimately I didn't propose it because it seems like even more work than collapsibles across the board.

> An example could be an hypothetical edit of the old man glitch to remove duplication of the information found at "Left-facing shore tile glitch", splitting off the "traditional Missingno glitch" to a separate article (with historical notes, but referring to the two glitches it combines for further information), while providing a link to this new page as application examples?

That is not just a hypothetical (potential) edit! Now that you brought it up, the page seems super messed up. This seems more like a case of stuffing all "beginner-friendly" related information into one page, even though they don't really belong, because how is a beginner supposed to know which link to click?
Kudos for bringing up a concrete example, though. I have avoided examples because I think the potential use cases of collapsibles would be many, and I don't think I can list them all, but a concrete example can surely help evaluating the proposal better. Maybe I will try it on Trainer escape glitch and see how it goes.
(And maybe you can also bring up or create an example of a page where all the "sections for a beginner-friendly explanation, one for a technical one*, an 'academical' use, and examples of results/applications - plus of course* notes on the discovery, historical use" coexists in harmony. I cannot think of such an example, but that doesn't mean they don't exist.)

> As for hexadecimal style, could it be possible to have some markup/template around a number that the server would process into an user-selectable style, like with dates? (My personal choice would be "nothing at all if it's obvious from context, like having letters in it or being in an appropriate table column, anything goes if it needs to be called out")

I believe that should be possible (not a MediaWiki person though), but that might be slightly more work than fixing everything according to a single guideline, and would be more confusing to new contributors, too.
The "obvious from context" point can be a little subtle (what is 8F? :P), but I agree that in certain environments, like table columns and maybe long byte strings, a marker is not necessary.

> > Although I am faced with a technical problem right now: It seems that the items on the Glossary page are not anchored (i.e. a "[[#count byte|count byte]]" would not jump to the corresponding item), and I would have to do it manually like this or this. Is there a better way, or is there an advantage in using explicit anchors for every term that I'm not seeing?

> I don't have an answer about the cause, but I think the automatic heading-to-anchor system of mediawiki is problematic - it unsurprisingly breaks down when a title is edited, it fails when a title is repeated multiple times (as seen in our "text errors" page), … so I'd say that you can't go wrong by doing it manually :)

You can go wrong by, for example, spelling the anchor incorrectly! Or worse, overwriting another anchor because you copied the entire thing and forgot to change the anchor. When a title is edited, you always have the option of keeping the old anchor (by explicitly adding one if the default is implicit), but in my opinion that is not a good state to be in anyway. My suggestion would be only to link to titles that are unlikely to change, which terms in the glossary are.
Maybe from a practical viewpoint, explicit anchors cause less headache in the long run (discounting the fact that having to type every term twice is already a headache). But I hate code duplication with passion!

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Ryccardo
Date: 2019-09-04 16:19:00

> The way I see it, collapsible sections serve the same function as a table of content. […] TVTropes […] [notes]

Oh right, it's been so many years since I visited their website (vastly preferred the unofficial Android client "Lampshade", now broken) that I forgot they have an "open all" button - I'd be more than fine with that (or a preference to just disable them); and the "inline long comment" use also seems reasonable!

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-05 16:03:41
Incidentally, I'll mention that one consequence of different people enjoying different parts of a page is that the "don't link a term more than once" policy is not necessarily appropriate. We can refer to Bulbapedia's manual of style:

> Also, only link to an article once within a given portion of text; if you say "Ash" more than once in a paragraph, only link it the first time. Instances further apart may be linked to more than once, it is up to you how far apart to place repeated links. For consistency, if most elements of a list are links, then link to an article as many times as needed in that list.

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: Sherkel
Date: 2019-09-05 22:39:58
Thanks very much for making this post. Your efforts are invaluable, some of which are also visible under the recent changes section. Most of what I've said thus far seems to just be agreeing with your suggestions, but like Photon I'll be looking over each part of this with more detail to see if I come up with anything to add.
EDIT: On a quick editing spree at the moment, but don't take that as an indicator of me being ready to process things in depth. :P

#### Re: Organization discussion thread (everyone please weigh in)

Posted by: bbbbbbbbba
Date: 2019-09-08 21:09:05

> EDIT: On a quick editing spree at the moment, but don't take that as an indicator of me being ready to process things in depth. :P

I have been also been doing many wiki edits, but don't take that as an indicator of me having enough energy to keep this discussion alive. I know what I should do is to clean up the Trainer escape glitch page to have an example on how to use collapsibles, but that in itself is a huge task…
Previous Page

- 1
- 2
- 3
- 4

Next Page