Re-implement infobox sections
On Fandom, our infoboxes had secondary headers (which I'll be referring to as sections) that split up information neatly. You can see these sections by going to any mob or biome page on Fandom.
I propose we re-implement these sections, as they were lost once we forked.
Notably, the section headers on Fandom were very tall, making infoboxes much longer than they needed to be if they had even just two section headers, so they need to be made much shorter in our implementation. I am sure other improvements could be made though, please suggest any you have in mind.
Sections in infoboxes neatly separate information and remove the risk of bloating infoboxes with too much information, infoboxes become a lot more digestible when information is sorted neatly with these sections.
Biome climate and color information could be their own sections, mob attack strength could be its own section, with the difficulties becoming rows below it, Legends mobs could have a dedicated cost section since mobs in Legends have about three different types of cost, block property information could be in its own section, seperating it from the more essential information at the top, block lists in structure infoboxes could instead be a collapsable section instead of a row with a show button, etc etc.
There's quite a few applications of sections that I think would improve infoboxes a lot. The entire purpose of infoboxes is to provide information quickly at a glance, so letting them do that more efficiently would be a great idea in my opinion. This is a feature we lost instead of consciously removed, so I am hoping we can get it back. - Harristic / Talk 👁 Image
14:33, 27 March 2024 (UTC)
- 👁 Image
Strong support as proposer.- Harristic / Talk 👁 Image
14:33, 27 March 2024 (UTC)
- 👁 Image
Support — 👁 Image
Delycache (Talk | Contributions) 14:59, 27 March 2024 (UTC)
- 👁 Image
Support subsection headings, collapsible subsection headings, simplifying the first-glance information by cleverly sorting content between subsections, and infobox title icons. I would even go as far as differentiating infoboxes by using unique colour schemes per type (e.g. green for biome, yellow for item, grey for block, etc), since that would help with content recognizability, which is an important element of UX design. - Jack McKalling (talk) 15:35, 27 March 2024 (UTC)
- Russian Minecraft Wiki actually has different header colors for subject types, but the problem is already existing header colors for spin-off namespaces. For example, our entity infobox has a roughly similar color to Minecraft Dungeons infoboxes on the English wiki. This is one of the obstacles for adopting the updated infobox design on RuMCW. — BabylonAS 15:49, 27 March 2024 (UTC)
- More specifically, this is our entire color palette (thanks to MakandIv for finding it out):
- Traincraft infobox is apparently an old experiment and not really used. The modpack infobox was created but modpack articles were not (currently, our notability guidelines neither allow nor forbid them).
- None colors are compatible with the dark theme, because they were implemented as inline CSS definitions instead of classes or variables. — BabylonAS 16:25, 27 March 2024 (UTC)
- I think I’d rather not have colour coded infoboxes. It kind of borders on over-design territory to me and could look messy, since of course most of the colours will clash with our existing theme. It could also be difficult deciding what the limit is for what kinds of feature get their own colour. Also also, we already colour code infoboxes based on namespace for the spin offs. I think sections will provide a great improvement to infobox readability already so I don’t think the messiness that colour coding may cause is worth it. - Harristic / Talk 👁 Image
08:31, 28 March 2024 (UTC)
- Not all players are interested in multiple Minecraft games at once, and those might benefit from color-coding infoboxes on specific aspects of their preferred game. It has also been argued on the Russian wiki that the namespace-specific skin variants are already differentiating enough. That said, some of the current colors are quite close to each other (basic Minecraft, Earth, and Legends on one side and Dungeons with Story Mode on the other side) which would greatly complicate finding a proper palette for each namespace. The Russian color coding was devised at a time when no spin-offs ever existed. — BabylonAS 07:00, 31 March 2024 (UTC)
- Whether or not you interact with the spin off namespaces, a red infobox on a green and blue coloured skin is ugly. EN’s infoboxes have more coloured elements than RU’s (the border), so the contrasting colour sticks out more. - Harristic / Talk 👁 Image
09:02, 31 March 2024 (UTC)
- That's why determining palettes is important. However, I can only think of three or maybe four primary colors each skin has: the sky, the grass, the dirt and the stony background. Determining four categories would be problematic, as we have blocks & items, entities, structures, status effects & enchantments, versions & development phases etc. That is indeed my main concern with any form of additional color coding. There might be only so few adequate colors that making a color coding scheme for the new infobox skin is just not worth it. Several Russian wiki users have voiced a wish to keep the subject-specific color coding, even if with some modifications; having to sacrifice that in favor of namespace-specific color coding would be quite unfortunate. — BabylonAS 10:13, 31 March 2024 (UTC)
- I don't think this is in the scope of this discussion, and it would better be an individual topic. GIM Dianliang233 T C 00:48, 11 April 2024 (UTC)
- Well, one could think that it’s better to implement multiple drastic changes to one thing at the same time, though I agree that this is a rather big topic on its own. And I’m quite interested in having it discussed, because, once again, the Russian wiki has its pre-existing infobox coloring scheme as a roadblock for adopting the updated visual design. BabylonAS 12:45, 12 April 2024 (UTC)
- 👁 Image
Support - restoring any changes that got lost unintentionally during the fork. Delvin4519 (talk) 15:39, 27 March 2024 (UTC)
👁 Image
Oppose —We are Fandom no more. We should not look at Fandom for inspirations, and we should not use or recreate their bloatware. PortableInfobox is an abomination that should have never been used on the wiki.
👁 Image
Support — Actually I was joking, except maybe the PortableInfobox part. The problem would be determining exact sections; for blocks it’s not quite obvious to me. — BabylonAS 15:49, 27 March 2024 (UTC)
- This topic should be about the exact specifics of the subsections we want. - Jack McKalling (talk) 15:53, 27 March 2024 (UTC)
- PortableInfobox has an open-source version and some wikis outside of Fandom migrated to it --TreeIsLife (talk) 19:49, 27 March 2024 (UTC)
- PortableInfobox was vetoed by Weird Gloop as it is apparently not compatible with some Parsoid shenanigans. We’re on our own. — BabylonAS 08:12, 28 March 2024 (UTC)
- I know people took that comment from 2022 too seriously and I understand why, but it was apparently fixed several months ago. --TreeIsLife (talk) 14:20, 28 March 2024 (UTC)
- 👁 Image
Neutral It would require some big technical changes to the infobox template, though not a bad idea --TreeIsLife (talk) 19:49, 27 March 2024 (UTC)
- Just as a wild guess, there is a way to make it simpler on the infobox end, at the expense of making it more complicated on the CSS/JS end. As I see it, Infobox would use a relatively simple subsection header row that however has a
collapsible-section-header class or something. For that one, our “collapsible” script would allow showing or hiding table rows that follow after the hidden subsection header, but not after any other headers even further. — BabylonAS 08:12, 28 March 2024 (UTC)
- Yeah, that's basically one of the solutions to collapsing. However, based on what Harri clarified on Discord, it seems like we'll only implement headers, not sections. On one hand, that is very easy to add, basically just this small code on Template:Infobox header
! class="infobox-header" colspan="2" | {{{1}}}
|-
- On the other hand, when inspecting our usage on Fandom, we used it mainly to collapse details on templates like
{{Biome}}, {{Structure}} and {{Entity}}. Basically, without the collapse function, this feature is not as useful as it should (if it is even useful at all) --TreeIsLife (talk) 14:20, 28 March 2024 (UTC)
- 👁 Image
Support 👁 Image
plighting_engineerd (talk) 12:54, 29 March 2024 (UTC)
