Forum:Split navboxes

Navboxes, such as {{Navbox blocks}}, {{Navbox items}}. {{Navbox tutorials}}, {{Navbox jokes}} and versions navboxes are too verbose and resource intensive. This has been a long-standing problem, and while the performance is no longer that much of a deal, the content remains and it gets worse, as in recent years, Mojang added many new entries, and soon the navbox will be longer than the page content.

Therefore, I propose splitting navboxes.

In this table, you can see how I would split them:

The main navbox will be used to link to meta pages (like for blocks, it will link to Natural blocks, Biota blocks,...). --TreeIsLife (talk) 13:06, 20 June 2024 (UTC)

Follow up: I've realized nobody knows what I meant with "meta navbox", so here is a page with all concepts. The one I've presented here is the concept 1, but I am open to more concepts/suggestions. --TreeIsLife (talk) 12:52, 21 June 2024 (UTC)

👁 Image
 Support As the proposer --TreeIsLife (talk) 13:06, 20 June 2024 (UTC)

👁 Image
 Support 100% support, the sections line up with groupings we already use. Mudscape (talk) 14:02, 20 June 2024 (UTC)

I did a little more research about performance - and its a much bigger deal than I thought. Template:Navbox items parses in 0.680 seconds and Template:Navbox blocks parses in 1.005 seconds At least one of these navboxes are present on every content page, adding between 6 tenths and an entire second to every editor preview. For context, on a relatively small page like Raw Salmon, the entire page as it currently is parses in 1.128 seconds. Removing just the Navbox items brings the parse time down to 0.513 seconds. Navbox items is 60% of the parse time for this page. That is a lot of reader, server, and editor time. Mudscape (talk) 15:56, 20 June 2024 (UTC)

👁 Image
 Strong oppose without hard data on exactly how readers use navboxes. Why?

1. Gut feelings: While some editors whom joined over from RSW have mentioned that "readers prefer smaller navboxes". They have only said this in a "it's probably how it works, that's how it's done on RSW. It'd be similar to MCW but we have no data on it since we haven't added the script/extension that would allow us to get this data". Why put editors through so much trouble for a "gut feeling" instead of actually getting this data first? Do readers actually prefer smaller navboxes/split articles or not? Anectodally I've heard "it's possible to get this data we just need to copy the scripts/extensions from RSW to MCW", but it never happened yet.
2. Almost non-existant performance problems vs. page size: "This has been a long-standing problem, and while the performance is no longer that much of a deal, the content remains and it gets worse, as in recent years, Mojang added many new entries, and soon the navbox will be longer than the page content."
   RSW is entirely built around updating 50,000 pages over a single template changing the wiki. Most navboxes on MCW are used on less than 1,000 pages. It would be even more less so if we didn't have dedicated articles on "acacia slab" or "red wool". Plus the only reason the navboxes are larger than the articles is because mini/tiny articles like "archer pottery sherd" and "tuff brick stairs" exist as independent articles, as they got split post-fork.
3. The proposed splits result in readers failing to find related articles: Desert temples and desert wells should absolutely be in the same navbox. Desert wells are terrain features and desert temples are generated structures, but both give the impression of being a "structure" in the world, even though the way they generate is different. The proposed splits would completely isolate them to different navboxes making it harder for readers to find related articles, unless they somehow find the single lone page where the parent navbox is loaded on.
4. The proposed splits would massively bloat the size of navboxes: Individual navboxes list each copper variant, tier of tool, every pottery sherd, etc. Linking them all in the parent navbox would make the navbox a lot much larger in size with too many links. Most of the features are identical and are generally fine to link the overview page only on the parent navbox and not the split pages on split navboxes. The same goes for items in multiple categories. Is "sandstone" a "nature block" or a "building block"? If it's both then we'd have duplicative links in the parent navbox when it should only be assigned a single tab. The search tab in Java Edition's Creative menu only lists blocks once, even if the split tabs on JE means the item appear twice or 3x, but it only does so in split tabs and not the parent "all" tab.
   In addition, it would massively bloat the size of MCW:Quick reference page and {{navbox see also}} with dozens and dozens of extra links and pages to link to. Both pages essentially function as a quick table of contents, and as a transcludable, visual, single-page index of the wiki.
5. The proposed splits would make the wiki much harder to explore: The blocks, items, jokes navboxes all generally link to overview pages and are split into categories that somewhat mimic those in Creative, or separate historical/split pages from current overview pages. Block and Item are terrible to explore the wiki IMO since "items with indirect world use"/"items with direct world use" is much more arbitrary than "tools", "combat", "food", or "ingredients". Plus navboxes make use of sprites as visual indicators and can be split into sub-sections, but categories lack such functionality and require navigating to dozens of different pages to access sub-categories. The current {{navbox world features}} template is currently the best way to get the visual overview of all world features, as other pages of the wiki that show this content are in giant tables in multiple different pages, which are harder to just get the quick list of world features.

I already have an issue with the move of all navboxes to the new naming system. User:Harristic hasn't finished updating interwiki for all navboxes after the dungeons navboxes (every navbox from {{navbox Earth}} to the meta navboxes {{navbox help}} is still not done). On Japanese wiki, editors there started the process of moving to the new naming system in waves because "English wiki did it, here's Harristic's proposal translated to Japanese". While JA editors updated JA interwikis for all languages in the first round, the work eventually proved too tedious to do. In the second round of moves on JA, editors only updated JA interwiki on English wiki only and not all 11 language wikis. On Portguese wiki, 2 editors carried out the move/renaming of hundreds of navbox pages with edit summaries literally translated as "moved because English wiki did it" and none of them ever updated the hundreds of PT interwikis that need updating on any of the 11+ language wikis. Interwiki bot doesn't support templates, so interwiki bot can't do this task for us. Yet this proposal calls for a massive expansion in navboxes with dozens of new splits, when editors across many language wikis literally aren't taking responsibility of their moves/renamings of pre-existing templates, and leaving behind entire afternoons/evenings of cleanup work for others to do later down the line. (I had previously spent multiple days in hours long sessions adding missing interwiki for all navboxes & categorizing/linking to orphaned navboxes across all language wikis. This took dozens and dozens of hours to do).

The amount of work this massive navbox split entails with all of it's issues, isn't worth a "gut feeling that readers probably perfer smaller navboxes, it's how it works on RSW and maybe it's similar on MCW". Get the actual data on split navboxes/articles first before we touch the status quo.

Delvin4519 (talk) 14:58, 20 June 2024 (UTC)

I really don't understand why you're ranting about my renaming proposal in a proposal that has absolutely zero relevance to interwikis. If we keep the main navboxes after the splits, interwikis don't need to be touched. If we get rid of them, five navboxes need interwiki updates, nothing. I also think the point about the quick reference page and navbox see also is irrelevant; if those pages prevent improvements to the wiki, they are the problem. - Harristic / Talk 👁 Image
15:21, 20 June 2024 (UTC)

The only reason I brought that topic up was since the earlier proposal of renaming all navboxes did not fulfill all responsibilities of updating all active links to point to the new navbox names. The original proposal before it was modified to keep redirects mentioned removing the old names altogether so no articles would use the old names, which would've meant any link not updated would then had become a broken link. The more templates to move, the more links to update.

We would still need a table of contents/index of the pages on MCW. Categories cannot have sprites attached to each article name, and subcategories require navigation to dozens of different pages. Search requires the reader to already know the exact name they are looking for unless we have a redirect for it. Random is limited to being a random page. MCW is not large enough to reach a point where categories are the only way to list everything like wikipedia, unless the goal is to split everything into articles on "acacia wood slab", "birch hanging sign", and "red wool"; with navboxes like "navbox dark oak", "navbox banner patterns", and "navbox yellow dye".

Back on topic, the proposed split is still bad for reader discovery. Why should desert wells be located in a completely different navbox from desert temples all because of a technical implementation of desert wells as a terrain feature and not a generated structure? A reader should not have to navigate to different navboxes to get from desert wells to desert temples, or read paragraphs in the desert article. The two are all related as structural features in a given world. The same goes for monster room, mineshaft, and trial chambers as all underground structures, yet monster room would be broken off into a different navbox from the rest even though all three are underground strutures one can find in a given world. It is reasonable to expect all structures to be in a single navbox listing all the structures. If they are listed in both the generated structures and the terrain features navbox, that would result in duplicated links in the parent navbox as they'd be listed twice being loaded from the child navboxes.

For blocks "natural blocks", "biota blocks" are much more arbitrary. Stone related blocks would wind up isolated into different navboxes even though they all share the same tab in Creative, and the same goes for natural blocks. If someone knows where to find blocks in Creative mode in-game, then they'd need to also remember the wiki would now use some different arbitrary categories from that used in the game. I'm not so sure it's possible to split the parent navbox into child navboxes that can be loaded into the parent navbox, aside from maybe an expansion of scope of standalone thematic navboxes independent of the parent navbox. They don't map cleanly to parent navboxes, and parent navboxes that don't have duplicated links today would then now have duplicated links.

Navboxes with multiple sub-sections are also already collapsed by default with only the relevant sub-section opened, so unrelated sub-sections are hidden by default.

Also, if we are actually concerned about performance, in the MCW discord it was mentioned that BlockLink is twice as slow as RSW's plink, so if BlockLink and the rest were to be optimized, performance would be improved 2x.

Delvin4519 (talk) 16:47, 20 June 2024 (UTC)

1. this proposal was not inspired by RSW. It was inspired by my experiences with navboxes.
2. the point is Mojang keeps adding more and more content. Nowadays, every version breaks some record for having most blocks, items, mobs,... Also, Joke updates are becoming too feature-rich. The 2024 AF snapshot is for example so big it warrants its own navbox and even if this proposal won't pass, it is something it should be implemented.
3. yes, but will get to this point in #5
4. I don't see any problem here. We will split it to smaller chunks and even though together they will make bigger navbox (although not by much), overall pages will have less navboxes
5. OK, here is the bit controversial point. And let's face it, yes, this will probably hurt discoverability of content. However, using the meta navboxes, we should be able to decrease the risk.

If there is any request to track navbox behavior, go for it. Or make a survey. I do not care. And if the results will show people are interested in this, then I am interested in redoing it again. Just I feel like you think we're trying to make MCW the new RSW, but that is not the case. For example, I heavily disagree with the removal of "read" button, cluttered personal menu and even the extension choices. The fact my proposal is similar to RSW is a complete coincidence. TreeIsLife (talk) 20:14, 20 June 2024 (UTC)

Mudscape has a script for that but only an admin can enable the script. Delvin4519 (talk) 20:16, 20 June 2024 (UTC)

👁 Image
 Neutral. I think either way, things would end up fine, so I'm not terribly bothered. If we split them, I'd like if we introduced more thematic navs too like a jungle or ocean nav. I don't like removing the ability to go from any block to any block, but smaller navs are easier to use, and thematic navs can extend to things that are related but not the same type of feature, which is good. If we don't split the navboxes completely I would at least like to split removed/unimplemented and joke features because I think even the biggest navboxes would be much more approachable with that bloat gone. For world features I'd like if we had a "Structure-like" row in the structures nav, because yeah, there's many world features that are essentially structures from a player's perspective. I'd help with implementing the final product of this proposal, I just don't want to argue about this right now. - Harristic / Talk 👁 Image
18:11, 20 June 2024 (UTC)

If parent navboxes are loading content from the child navboxes, there would be a duplicated entry for all the structure-like features appearing twice if they appear in both child navboxes, increasing navbox bloat. They should only appear once in the parent navbox. Delvin4519 (talk) 20:16, 20 June 2024 (UTC)

👁 Image
 Important - Navbox link tracking has been enabled. The gathered data should allow us all to make more insightful follow up comments. - Harristic / Talk 👁 Image
22:19, 30 June 2024 (UTC)

We should aim for at least 4 full months of full data, bare minimum, before moving forward with any split proposals. Too short of a data collection timeframe could lead to limited data to work with. Since navbox data tracking only went live after midnight UTC July 1st, 2024, that would put us well into November 2024 before we can review the data and decide the next steps for discussing splitting navboxes. We should not be cutting corners just because the data collection for navbox links was delayed and not activated for several months. Per Lakejason's comments below, 👁 Image
 Oppose any major split discussion or major split actions for navboxes before enough data is collected. Delvin4519 (talk) 18:33, 1 July 2024 (UTC)

4 months is too excessive. 1-2 months should be enough. TreeIsLife (talk) 18:36, 1 July 2024 (UTC)

Minecraft updates release on an annual update cycle. 4 months allows us to hopefully hit the next snapshot cycle after Minecon Live if 2024 is a repeat of 2023. 6 weeks is too short, and will probably even miss the next minor dot release, as minor dot releases seem to be more on the order of a few months versus 4 - 6 weeks. Minecraft 1.19.2 to 1.19.3 had 4 months in between, and 4.5 months between 1.20.4 and 1.20.5. We can not cut corners just because activation of the navbox tracking gadget was delayed. We have to wait the full time it takes to get necessary tracking data, and recognize the length it takes for Mojang to go through an update cycle to get the full tracking data. Delvin4519 (talk) 15:36, 2 July 2024 (UTC)

4 months is ridiculously long. The fact it gets one update per year doesn't affect us. We are solving user behaviour during regular times.

Keep in mind analyzing and implementing this will take at least another month. TreeIsLife (talk) 20:00, 2 July 2024 (UTC)

Re: The entire "how long" discussion. Throwing out time tables at this point isn't helpful because we have no clue how much data we are getting, how volatile it is, how it changes over time, etc. The admins will check on the data periodically and when the data seems comprehensive we can take up the discussion again. Mudscape (talk) 20:09, 2 July 2024 (UTC)

ZH had done a similar organization (not splitting though) on navboxes. In general for zh:Template:blocks and zh:Template:items we've done it in a way that "feels like in-game inventory while being not fully dependent".

Thus for Blocks, as an example, it's Building blocks (subnav-ed by best tools; The Pickaxe subnav got additional subnavs for Stones-like, Ores, Blocks of minerals, Bricks), Decorative blocks (subnav-ed by Biota Blocks (refers to plants and mushrooms, since their not being mobs results in not "living"), Utility Blocks, Misc), Redstone blocks, Others (including fluids, air, blocks without item forms, admin items, in EE, not used, removed, jokes). I still don't feel we should split them like too much; we could split subnavs to subpages for code maintainability...? and still showing these as a whole IMO.

ZH's Blocks navbox doesn't have so many links however, due to April Fools section being links to the Block section of the article, not listing them as individual links (editors on ZH feels reluctant to split those April Fools pages afaik).

Another reason for 👁 Image
 opposing the split before knowing the actual data gathering is, IMO, only showing one section of the navbox by default is not that long to the readers. And like world features just doesn't have that much entries, alongside that the distinctions between features and terrain features just aren't that big. Still, I would prefer knowing the actual reader data and opinions on this, so 👁 Image
 neutral for now. -- Lakejason0 (Talk • Contribs) 14:56, 1 July 2024 (UTC)

And yeah, English words are generally much wider in display length than the equivalent words in Chinese, so that's probably a reason of why ZH won't consider a split, aside from the fact that ZH doesn't have individual April fools joke blocks/... pages. But sorting some of the interested blocks in best tools sounds really great to me. -- Lakejason0 (Talk • Contribs) 15:04, 1 July 2024 (UTC)

More notes: providing infos on how ZH does this is solely for reference purposes. ZH nowadays has a quite different structure than EN now, and that knowing each other is great, yet we don't have to follow everything from each other. -- Lakejason0 (Talk • Contribs) 15:08, 1 July 2024 (UTC)(edited at 18:09, 1 July 2024 (UTC))

👁 Image
 Neutral per Harristic. Nerdyguy2000 (talk) 17:56, 7 July 2024 (UTC)

👁 Image
 Oppose splitting 👁 Image
Miner(👁 Image
talk 👁 Image
contributions) 11:30, 5 October 2024 (UTC)