Work Has Begun on the Supper Mario Broth Database

Hello!

Thank you once again so much for your continued support! I hope that the things I have done since returning to work have been to your liking! Here is a brief summary:
-I have begun writing long-form articles again. The last one was a week ago, with the next one coming later this week, and more every week of November until December, where they will become even more frequent. In addition, this month's long-form podcast is in the process of being written, with the projected release being the week between the 18th and 24th of November.
-All public Supper Mario Broth sites are updating regularly at previous levels with me making occasional extra posts to slowly ramp up the rate of regular content.
-I have been posting experimental content like a character commonality quiz, with several more experimental posts being planned for this month. I welcome all suggestions for more types of experimental content! 
-I have adopted accessibility enhancements and better sourcing for my non-Tumblr posts (as the Tumblr ones already had clickable links and selectable text on all posts). Now Twitter posts have a reply linking to the original post, and Bluesky posts have selectable links in the alt text.
-My first livestream (Super Mario 64, as decided by a poll of my readers) will take place later this week!
And this is just the beginning!

However, one very large project I have been talking about in my previous posts is one that I am particularly glad to announce:

The Supper Mario Broth Database will be a site that contains summaries of, previews for, and links to all Supper Mario Broth posts that have ever been, or will ever be made, all collected in pages separated by topic and content category. In other words, the Supper Mario Broth Database will be a way to truly see every finding I have ever posted on a topic all at once without needing to manually search through several different web sites with unreliable filtering algorithms. This project will transform Supper Mario Broth from a mere Mario variety blog into a true repository of useful Mario knowledge.

From the day that I was able to announce that I would be working on Supper Mario Broth full-time thanks to your incredible support, readers began voicing their desire for such a database. I, too, have wanted to make a site like this for many years, but I was unable to gather the time and energy for the formidable investment of effort such a project would require - until now!

This article will be split into the following sections, detailing the project:
1. The vision behind the database, and long-term plans
2. Who I am working with on the project
3. Details about Iteration 1 and a preview
4. How you will be notified of updates

A summary of this is the following: I have a vision for an iterative, result-oriented design that will prioritize getting the database functional and content-complete as soon as possible before adding more features. I will be collaborating with renowned Mii expert and Mii database creator HEYimHeroic for the first iteration of the site. The launch of the site will be widely announced on all Supper Mario Broth accounts and then the site itself will contain information on its own update status.

Now, if you would like to read about these in detail, here is the full post:

1. The Vision Behind the Supper Mario Broth Database

Currently, the Supper Mario Broth Tumblr contains 7,600 posts, the Twitter contain 5,200 posts, and the Small Mario Findings blog contains 7,400 posts. While a percentage of these are replies, announcements, and other types of post that are not content that would need to be indexed in a database, the order of magnitude here is still 20,000 posts, which are all mostly about different findings and as such feature very little overlap. In fact, I have in the past deleted previous posts whenever I posted updated versions just so there is no overlap (a practice I have stopped when I adopted my current "no deleting a post if it is factual" policy; as it is better for an old external link to link to factual information that may have received additional context, than to link to a deleted post).

(The next section deals with basics of databases. If you are familiar with them, please feel free to skip to the next underlined section further down.)

With any body of knowledge this large, the question arises of how to organize it. There are two main ways of organizing any body of knowledge (while countless others also exist, these two are the most common and will be the subject of this discussion): hierarchical and tagged systems.

A hierarchical system is best suited for information where every piece can be clearly identified as uniquely belonging to a specific set, with each such set belonging to a larger "higher-order" set, and so on until the top-level set containing every other set. A practical example: imagine a database containing demographic information for every single settlement in the world. Clearly, the most logical way to navigate such a database is to start by selecting a country, then a province/state/region of that country, then a county/district of that region, and finally the settlement - because each settlement belongs only to one specific county, which belongs to one specific state, which belong to one specific country.

If a hierarchical system can be used at all, it should be used because it is logical, easy to navigate, and most importantly, unambiguous. If you know a certain town is in a certain county, then navigating to that county and not seeing that town can only mean that the town is not in the database. It cannot be possibly "hiding" in a different county somewhere else in the database if it is accurate. You may think that this is a silly concern to bring up if you have only had to deal with this type of database in your life, but my point is to contrast it with the other prevalent type: the tagged system.

Tagged systems are used for collections of information that cannot be arranged in any hierarchical manner that would be useful. Everything can be subjected to some hierarchy: after all, simply ordering something alphabetically is a hierarchy all by itself. But some information simply does not benefit from being arranged alphabetically, or by creation date, or by any other such simple metric.

A practical example is a large collection of artwork. You might have encountered this yourself in the form of art repositories on the Internet, often called a "booru". Artwork can be sorted by the name of the artist, or by the time of its creation, but it would be disingenuous to claim that such a form of presentation is useful to a person looking for specific artwork. Instead, artwork needs to be categorized by subject. The big problem here is that subjects are extremely varied; as time goes on, new subjects appear that did not even exist when the database was formed. Trying to have a hierarchical list of subjects also presents an unsolvable problem: what if some artwork has multiple subjects, which applies to a majority of it? Under what category would it go? Who decides what subject is the most important in an image?

This is solved with tags. Tags are information attached to each entry in the database that allow each entry to have as many of them as required to fully describe the entry. Instead of browsing such a database through category pages, it is browsed via tag queries. The user searches for a tag, or a combination of tags, and receives a dynamic search result page containing only the entries that match those tags. Tags are extremely useful if, and only if, the people running the database can make sure that the entries are tagged with all tags that apply to them, and that every time a new tag is added, all old entries to which the tag would now apply actually receive that tag. Otherwise, tags become less and less useful the less accurate and more ambiguous they are. In this system, a settlement can in fact be "hiding in a different county" by simply not being tagged with the tag the user understands to be the correct one. The entry is there, but the users can never find it unless they know the correct tag.

Compare the level of effort required to correctly insert an entry into a hierachical database:
1. Think about what category would apply to the entry.
2. Place it in that category. Done.
compared to the level of effort required to correctly insert an entry into a tagged database:
1. Analyze the entry, then go through the list of all tags that would apply to it and tag it with all of them.
2. Done? No. You are never done, because every time a new tag is added, every old entry must be analyzed again to make sure the new tag would apply to it. If this step is skipped, then only new entries will receive the tag, making it deficient in its ability to retrieve all the correct information in a query.

As such, it should come as no surprise that many tagged systems are crowdsourced. With a large amount of people donating their time and effort, one can hope that all entries are eventually tagged correctly, but hope is truly the maximum result one can expect to get. There is never any certainty that a given entry will have all the appropriate tags, so this system is great for databases that are supposed to work "well enough, to a degree" but not be expected to truly return all applicable entries. (Note that in corporate settings and with a much smaller and less-mutable number of possible tags, these systems can reach a level of working perfectly, but I hope my examples show why it is very difficult for a single person to keep up with this level of work.)

(This is the end of the explanation on databases.)

As such, I have decided that the first iteration of the Supper Mario Broth Database will be hierarchical. I do wish to add tags in a later iteration, but please understand that they will always remain supplementary and never be the main means by which users are expected to navigate the database. I will go into the exact nature of the hierarchy and categories in the next section, but first, let me elaborate on what I mean when I say "iteration".

As I am sure many of you are sadly familiar with, projects on the Internet are often delayed, stalled, and even abandoned completely due to a well-meaning, but ultimately counterproductive desire on part of the creators to make them "perfect". So many developers and designers working on websites, programs and games chase a vision of making the very foundation of the project as optimal as possible from the beginning. However, the foundation - the backend of a website, the framework of a program, and the engine of a game - is supposed to be just the beginning. The content can only begin getting added once the foundation is ready, and if it is not ready, then there can not be any content.

I believe that it is better for me to provide content as early as possible and then improve the foundation later, rather than concentrate so much on the perfect foundation that there is no content actually available for anyone. I realize that this is not a rule that can be applied to other projects - many of the games in the Mario series specifically went against this, e.g. Super Mario 64's development was spent mostly on the engine before the vast majority of content was added relatively hastily towards the end - however, I believe their goal of "creating a masterpiece" was different from my goal of "providing content". I hope you understand that I wish to simply provide you the database as quickly as I can so that you have something you can use, and improve upon it once the entries are complete.

Thus, I will be making iterations on the database. The first iteration will contain only the most basic features, with the goal being to have a working and complete database in the first place. Then, once that is accomplished, subsequent iterations will add other useful features one at a time, so that years from now, you will be able to have a deluxe feature-rich experience, but that you can actually start browsing through all posts merely months from now.

Here are some example goals I have in mind for Iteration 2 and beyond:
-The addition of an optional tag system
-Automatically-retrieved information from the original posts such as posting time, amount of engagement with the post, and source link. This will allow you to see which posts were the most popular right from the database, or be able to skip my post entirely and to go to the source for my information directly
-And finally, eventually, the ability for me to automate the process of adding posts to the database so that by simply creating an additional summary, I can send a post both to the site it will be published on and to the database simultaneously, greatly streamlining my work and allowing me to concentrate on providing more content.

Now, let us get into the details. While I will be providing the content for the database, I do not have any experience as a programmer. As much as I want to learn programming over the coming years - as it would tremendously help me in uncovering more Mario information - I cannot learn it quickly enough to be able to start working on the database myself within a reasonable timeframe, so I have decided to collaborate with...

2. Who I am Working With on the Project

...renowned Mii expert HEYimHeroic. You may not be an avid fan of Miis or a member of the Mii community, but I am willing to bet that many of you have seen this post, as it was covered very widely by a variety of mainstream gaming journalism outlets:

That is correct - it is through HEYimHeroic's datamining work that we now know that the two mainline The Legend of Zelda series games on the Nintendo Switch use a Mii-based system for their NPCs. And the discoveries do not stop there. We have collaborated on many Mario-related Mii posts in the past, such as this one:

or this one:

As you can see, HEYimHeroic's contributions to Mii research have been invaluable. However, the most important one and the one that led me to this collaboration is the Mii Library, a database that aims to document every single official Mii ever made:

(Note that this screenshot is from a work-in-progress new version of the site that I had private access to. The publicly available site is using a different framework, but will be replaced with this version once it is completed.)

HEYimHeroic and I share a passion for simple, clean web design harkening back to the golden age of personal websites, where basic functionality with a clear goal was prioritized in favor of the unnecessarily complex, social media-focused websites that dominate the landscape today. We still remember the days when a specific question led you to a dedicated website made to answer just that question or solve just that problem, and we want that feeling of the old Internet without (Super) Bells and (Warp) Whistles to remain alive in the Supper Mario Broth Database.

And while I do eventually want to add functionality to the database that would make it more dynamic, the underlying vision is to keep it as simple to use, visually clean, and free of clutter as possible, so e.g.
-No ads, social media integration, comment sections, dynamically-loaded suggestions etc.
-No unnecessary dynamic elements such as infinite scrolling
-No cookies or other types of information stored about you on the website. The website will always respect your privacy fully and never store anything about you.

We are currently in the pre-implementation stages of the project, with some parts of the code already being written and a host already chosen. Once the site goes live and I am able to put up a starting sample of a few hundred posts, I will make a public announcement that it is open, and update it regularly from that moment on until it catches up with the blogs.

In the future, I would also like to collaborate with other programmers for features in Iteration 2, Iteration 3, and so on. I will make posts requesting contact information and rates (all work will be paid) when the project reaches the point when they can begin to be implemented!

3. Iteration 1 in More Detail

Now, it is time to show you what the site will look like. Please keep in mind that this is just a mock-up and any of the details are subject to change, but this is the basic vision for Iteration 1:

As you can see, the basic building block of the page is a rectangular element that contains an image preview of the post (chosen specially by me; I will make sure to try to convey as much information about the nature of the post as I can and choose the most recognizable preview possible) alongside a custom summary of the most important information in the post. Clicking on the image will then lead you to the actual post on the site it was made on, where you can see the detailed image, description and source attribution.

Over time, with Iterations 2 and beyond, I aim to integrate as much of that information as possible into the page itself, such as displaying a preview with the source when clicking on a small icon provided in each rectangle, etc. However, I hope that for Iteration 1, this presentation will provide what is hopefully the main reason readers would visit the Supper Mario Broth Database for: a categorized, easily assessable at a glance collection of all posts I have made on a specific topic.

The majority of the category pages will each be dedicated to a specific game. This is the reason why I believe that my content is suitable for a hierarchical database to begin with: since most of it directly relates to a game, it makes the most sense to sort it that way. Here are typical subcategories one will be able to expect from a game's page:

Game Title
-Unused content
-Pre-release content
-Easter Eggs/obscure content
-Glitches and exploits
-Print content
-Promotional content

Of course, once a subcategory becomes large enough, it will be split into sub-subcategories (with each subheading becoming smaller in size). For example, a large enough "print content" section may become split into "print ads", "magazine coverage", "manga appearances", and so on.

Unfortunately, there are also downsides with this approach when it comes to posts that reference two or more games. While the long-term plan is to be able to find them with the eventual tagging system later, the Iteration 1 way of handling these is by including the post on the pages for both games, creating a duplicate entry. Please keep in mind that this is only a temporary solution and will be implemented in a more elegant way later; the goal at the moment is to simply catalogue all posts.

Outside of game pages, other pages will include non-game topics like merchandise (each page containing one type of merchandise [e.g. plushes] which is then subcategorized by subject) or Mario references in non-Mario media. New pages will be created gradually as they become required for the database.

I hope you find this implementation of the first iteration satisfactory! Again, all concerns about the optimization of finding specific content are going to be addressed in subsequent iterations.

4. How you will be notified of updates

When the Supper Mario Broth Database goes live, I will first add a small amount (around 200-300) posts to it before announcing its release, so that readers can see a preview of how the site will look when it is fully populated with all posts. Then, the top of the main page (URL to be announced) will feature a highlighted "Updates" section that will show when the database was last updated, and which posts from the Supper Mario Broth sites are currently already entered. (E.g. "Supper Mario Broth Tumblr - Complete up to November 2016, Small Mario Findings - Complete up to January 2019, Supper Mario Broth Twitter - Complete up to May 2018.")

From then on, all you have to do is to bookmark the main database page on your computer or smart device and keep checking in to see how far it is progressing! Once all posts are entered, I will also make a separate big announcement on all Supper Mario Broth sites, so you can simply wait until that moment if you only wish to see the database in a content-complete state. After that, work will commence on the next iteration, and so on.

Thank you very much for reading! I hope this project will be useful to everyone who is interested in delving deeper into obscure content on any Mario topic! I am looking forward to announcing the launch of the database soon!