Forum:Rethinking navboxes

From Minecraft Wiki

Latest comment: 19 December 2023 by Violine1101 in topic Rethinking navboxes

Rethinking navboxes

Latest comment: 19 December 20232 comments1 person in discussion

The following discussion is closed. Please do not modify it.

Consensus appears to be that navboxes should continue to use small icons like BlockSprite. A discussion about how to split up the larger navboxes should follow; see also MCW:Forum/A need to restore LoadBox for Navboxes. | violine1101 ^(talk) 00:40, 19 December 2023 (UTC)

A while ago, Mudscape proposed the concept of "thematic navboxes" in a topic on the community portal. A few of these thematic navboxes have now been implemented and can be found in Category:Thematic nav templates. In addition, a navbox for the next major update (1.21) has also been created: Template:Navbox update 1.21.

Now, when you look at these templates, you'll notice that some have larger icons in the style of in-game inventory items, and others have the usual smaller 16×16 sprites that show only the front texture of blocks. I personally quite like the larger icons as they make it much easier to see what an icon is meant to be and they als make it easier to click on the respective link.

However I've noticed that some have voiced concern that this makes the navboxes look inconsistent. In addition, there's currently no proper policy on this, and some users (most notably ThisNewWikiIsSoMuchBetter) are reverting the thematic navboxes to 16×16 sprites, so it does seem like a controversial change that needs to be discussed.

As such, I feel like we should come to some sort of consensus on what we want navboxes to look like in the future. | violine1101 ^(talk) 22:19, 7 November 2023 (UTC)

Options

[edit source]

Latest comment: 7 November 20231 comment1 person in discussion

Here are some of the options from my point of view, with some pros and cons I could think of (might have missed some though, and obviously I do have my own biases):

(1) Use large icons (InvSprite / icons scaled to 32px) everywhere

[edit source]

👁 Image
This would make navboxes more consistent
👁 Image
Makes icons easier to recognize
👁 Image
Makes icons easier to click on
👁 Image
Potential issues with inconsistent row size when some links / rows don't have an icon
👁 Image
Large navboxes become too cluttered

(2) Use small icons (BlockSprite) everywhere

[edit source]

👁 Image
Makes all navboxes consistent with each other
👁 Image
No unnecessary increase in size inside of navboxes
👁 Image
Small icons can be hard to recognize

(3) Keep small icons in large navboxes but have smaller navboxes use large icons (essentially the status quo)

[edit source]

👁 Image
Has both easier to navigate thematic navboxes but not too bloated (by images) large navboxes
👁 Image
What is a "too large" navbox? How do we define that?
👁 Image
Size of sprites in navboxes are seemingly inconsistent across the wiki

(4) Split up large navboxes

[edit source]

If you look at Template:Blocks for example, I cannot imagine someone actually using this template to find the next article to read. Do we really need to list all the blocks on any page about a block? For this reason, I think it might be worth it to explore splitting these templates in a more sensible manner, but this would be quite a change to the wiki as a whole, so I'm not sure if everyone's on board with it.

👁 Image
Smaller navboxes that make it easier to navigate
👁 Image
Less links from and to each page, cleaning up Special:WhatLinksHere
👁 Image
Wiki is more difficult to explore: Need to use the search bar to get to some unrelated block from a block page

Further considerations

[edit source]

Some navboxes don't really have link icons, for example Template:Version, and I don't think it's viable to add icons there. Should these stay as-is?
Navboxes on mobile are their own can of worms, and we should probably keep it in mind when discussing changes to navboxes. I believe Mudscape has been working on some improvements there, though I don't think they're ready yet.
RuneScape wiki has a gadget to add some tracking to links in navboxes to be able to judge which links people are more likely to click on. If we added this gadget temporarily, this could help with finding out how to organize navboxes properly.

| violine1101 ^(talk) 22:19, 7 November 2023 (UTC)

Discussion

[edit source]

Latest comment: 12 November 202315 comments8 people in discussion

I currently 👁 Image
support no# option 2: to use BlockSprite/ItemSprite (and equivalents) everywhere. We currently do not have 32x32 sprites for entities, biomesprites, envsprites, dungeonssprites, etc. to upscale other remaining navboxes. Upscaling biomesprite/envsprite/etc./etc., would be too much of a monumental task for a relatively small (but larger than average) wiki, that I would still consider to be "too small" to carry out such task. (We haven't upgraded LegendsSprites to the new sprite format after 5 weeks, when is that gonna occur?). In addition, smaller sprites allows more text to fit before wrapping to new lines occurs, meaning there is a higher screen space limit by using smaller sprites. (The fixed width gadget on MCW uses a very narrow setting by default, but can only be changed by those who know how to, or are willing to, tinker with CSS.)

Regarding option no# 4, Template:Blocks and Template:Items are just so messy and disorganized that it's hard to find anything, but I am also very concerned about making parts of the wiki much harder to explore and discover. Category pages are not articles or templates, and do not have sprites in category pages. Search isn't a good tool to discover something new (it's only meant for knowing exactly what you want), nor is "random page" that good either. Limiting discoverability to "search", and "random page", is just a worse outcome IMO. In addition, splitting the current templates listing all blocks and items from the current structure, requires drawing arbitary lines on where to place a border between similar items, such as including player with mobs. vs. non-mob entities, or including ores with stone based blocks. This would just cause so much trouble of our quite small community of editors having conflicting ideas on how to split these templates into categories, meaning endless debates on categorization of blocks and items of the new split templates (are suspicious blocks "natural" or "utility"?, etc., etc., etc.).

Due to the disorganization of the aformentioned 2 templates, I currently use the Creative inventory section of the Inventory page (and other equivalent pages for older versions of the game) to navigate to various blocks and items across the wiki, of those that are obtainable in the Inventory. This is given that these use the in game order, which is more commonly based on having identical materials together. I previously cleaned up those particular pages and made dozens of adjustments for those pages to link to almost all blocks and items across the wiki, that are available in Creative. (I've also used the same format to upgrade pages like 2x2 grid, etc.) I've considered myself whether to have those lists loaded from a separate template/subpages, for a while, but at this time have opted to continue with the current format.

I would support the use of the RuneScape wiki's gadget being ported to MCW in order to figure out which links in navboxes are commonly used by readers.

Delvin4519 (talk) 23:57, 7 November 2023 (UTC)

👁 EnvSprite trial-chamber.png: Sprite image for trial-chamber in Minecraft
👁 EnvSprite trial-chamber.png: Sprite image for trial-chamber in Minecraft
👁 EnvSprite trial-chamber.png: Sprite image for trial-chamber in Minecraft
we don't need to scale the sprites, the browser already does that. Mudscape (talk) 00:36, 8 November 2023 (UTC)

We should implement the navbox click tracking gadget ASAP. We cannot make meaningful decisions about how to split up large navboxes without data. The code is simple, keeps all data in house, and is proven to work. One of the major benefits of being an independent wiki is we can get insight into this data like this and learn how readers actually use the wiki.

I strongly prefer the InvSprite icons, not only for their scale but for their accurate representation of the game. Blocksprite presents readers with a view of blocks that doesn't actually exist in the game, and by only showing one side of the block some blocks are indistinguishable from one another (logs vs wood is one example). Inconsistent row size can be easily fixed with css, if that does indeed become an issue. I think if a navbox is too large to be readable with 32px icons, the navbox is probably too large to be of much use to readers.

Regardless of whatever else happens we really do need to split the mega navboxes. They are so hard to use that I honestly disagree with the con stating that removing them would mean the "Wiki is more difficult to explore". I suspect they currently get nearly 0 use despite being on most pages, mainly due to their size and somewhat arbitrary organization. The only time I have personally used them I have had to use Ctrl+f to actually find what I'm looking for, which at that point I may as well search. Mudscape (talk) 00:32, 8 November 2023 (UTC)

I find the the list of items in Items to be just as hard to use as the list of items in Template:Items, and the same goes for the list in Blocks being almost as bad as Template:Blocks. The issue I with with those is that they are hard to use given their order is just arbitrary and some of the categorization is made up. For the point regarding "Wiki is more difficult to explore", even if most readers don't use the "everything" template, an "everything" list should still exist somewhere; and no, not categories. I'd prefer not to have 170 templates being added to MCW:Quick reference page, since there's already 45 or so in there. Delvin4519 (talk) 00:50, 8 November 2023 (UTC)

👁 Image
support #2 - I'm not usually looking at the sprites for detail, and the extra compactness feels better to me, but I don't have a strong opinion on this either way. Mobile would probably make good use of the extra size though. I do however 👁 Image
Oppose #4 - I've never found the navboxes that hard to use and they provide a really nice way to get an overview of what is on the wiki. I use them on a semi-frequent basis and would be sad to see them go :( I'll admit I don't really use the item navbox, and I think that might have to do with the fact that it does not have the collapsible categories like blocks do (the collapsible categories make it less intimidating ig). A good compromise could be to split the large navboxes into many more smaller categories (like with the thematic navboxes) and only by default show the relevant one. You could then open it up to show larger and larger groups if you wanted to, up until you could find everything still. The problem is then that there are likely many ways to organize the groups and that could spawn endless discussion - I'm not sure letting stuff get put into multiple groups would help either (since you would get duplicates when everything was expanded). Ishbosheth (talk) 03:50, 8 November 2023 (UTC)

The existing navboxes should probably be changed to use collapsible headers like Template:Blocks. I'm not sure why Template:Items doesn't use collapsible headers like Template:Blocks does. Delvin4519 (talk) 13:59, 8 November 2023 (UTC)

I also 👁 Image
support #2. – ThisNewWikiIsSoMuchBettertalk | contribs 11:59, 8 November 2023 (UTC)

👁 Image
Support #2 - The sprites don't need to be detailed, they just need to give a rough idea of what the item or block looks like. That's all the sprites need to be. They aren't elegant artworks, they aren't professional paintings by Leonardo Da Vinci himself. They're just sprites. --ThatOneWolf ^{(talk|contribs)} 13:38, 8 November 2023 (UTC)

Agreed. They're just sprites. The use of them in 16x16 format is that they fit nicely with common text size resolution of 10 - 12 px. 32px is far too large for that kind of text size. Delvin4519 (talk) 13:59, 8 November 2023 (UTC)

I personally am a very visual person, I use the sprites instead of the names as my first "visual search". Heres an example of the visual clarity differences, I invite everyone to see how quickly they can parse which block each image is representing.

Mudscape (talk) 15:11, 8 November 2023 (UTC)

The candles and banners are itemSprite (The list of itemSprites are shown in the Inventory page. Generally if an block used an item ID pre 1.13, or uses item texture in 1.13+, it's a blockitem and uses itemSprite.)

A problem with InvSprite is the pixelated diagonals of the InvSprite. Having diagonal textures means tha we need scaling since it can't be scaled directly like it is in game.

Note that the sprites are always used with the text. Having the text allows for easy Ctrl+F searching. The sprites shouldn't be more important than the text, as thats what blockSprite is used for in the navboxes. InvSprite is intended for crafting recipes/etc, while regular 16x16 sprites are intended as the visual aids for text links. Delvin4519 (talk) 15:31, 8 November 2023 (UTC)

👁 Image
Strong support option 3. There's just no reason to go fully one way or the other, different types of icons are going to work better for different sizes of navboxes. InvSprites are undeniably more clear than BlockSprites, but forcing InvSprite usage everywhere would prevent the existence of any navbox that is of decent size.

Additionally 👁 Image
Strong support 4, Blocks and Items navboxes are borderlines useless in my experience and are eyesores. - Harristic | Talk 👁 DungeonsEntitySprite penguin-onesie.png: Sprite image for penguin-onesie in Minecraft
22:21, 8 November 2023 (UTC)

👁 Image
Support option 2, its too cluttered looking having the images any larger than the sprite form. Option 4 should definitely be thought about too. Nixinova T C 04:41, 11 November 2023 (UTC)

👁 Image
Support option 2, I think it was argued that it might look unnatural compared to block renders, but renders don't look good at small scale IMO and it's easier to parse the texture of flat images. We should also look into splitting giant navboxes, but that seems like a separate discussion and I'd still prefer flat images for small navboxes. –Sonicwave ^talk 06:24, 11 November 2023 (UTC)

I'm confused what you're talking about with renders exactly, I'm not sure what warrants a comparison to renders as renders will never be in a navbox. Renders don't look good at small scale and we will never use them in a small scale. Considering invicons are literally what people see in the game and they are larger, I don't think it's farfetched to say they're easier to parse. - Harristic | Talk 👁 DungeonsEntitySprite penguin-onesie.png: Sprite image for penguin-onesie in Minecraft
11:03, 12 November 2023 (UTC)

Conclusion

[edit source]

Latest comment: 19 December 20231 comment1 person in discussion

It seems like the widely preferred option is #2, have all icons be small. When it comes to option 4, it seems like there's also support for that, so we should probably proceed with splitting up the larger navboxes to be a bit more useful. How exactly that should be done, I'm not sure, we should probably open a new forum post about that. I do now realize that me presenting it as one option out of four, while it was actually an orthogonal problem to the others, was somewhat counter-productive. | violine1101 ^(talk) 00:39, 19 December 2023 (UTC)

Retrieved from "https://minecraft.wiki/w/Forum:Rethinking_navboxes?oldid=2777242"

Categories:

URL: https://minecraft.wiki/w/Forum:Rethinking_navboxes