We need scrollable tables

Zorak

I’m green, I’m olive, I’m chartreuse
Poll Committee
Pronouns
He/him

While browsing the Mario Wiki as usual, I clicked on this page. My eyes nearly melted as the page became scrunched to the side. The problem? The tables are larger than Wario's butt and make the page extend to the sidelines, something that looks (quite honestly) terrible.
The solution? Scrollable tables.

Is this possible to implement on our Wiki or does it not work with our current Mediawiki version?
 
thing is, from using my computer, the tables already have left and right scrolls.

i think this page just needs to be better organized, we didn't realize that there will be this much amiibo support in hindsight.
 
Honestly? Not to sidestep the issue but the amiibo table is frankly horrendous and hasn't aged well at all. We've been using it since 2014 before amiibo launched and at that point there were only five games known to use them, but it just doesn't work anymore. While looking at the page I noticed several of glaring issues:
  • There's way too much information here to justify the horizontal we have right now, and it will only continue to get longer indefinitely for as long as Nintendo continues to support amiibo.
  • And frankly, a lot of the amiibo just don't need that much horizontal bloat. For reference, out of the 23 games currently on the table, a SSBU amiibo is used in 11 of them and unused in 12 of them. That's more space on the table being used to tell us that an amiibo isn't compatible with a game!
  • I don't know if any of these issues would be solved by implementing scrolling tables:
    • It's incredibly easy to lose track of information. Try scrolling down a bit and remembering which cells pertain to which games. Unless you're actively tracking a few of them, good luck with that. Same issue happens if you scroll horizontally, where you lose what amiibo the rest of the cells are referring to, but that would be fixed by scrolling tables, at least.
    • You can only scroll from the very bottom of the table, which is a problem for the long tables and may force the reader to make multiple trips back and forth depending on what they're looking for.
      • If you want an exercise in misery about how bad these issues in particular are, try finding the Smash Mario amiibo's compatibility with Bowser's Fury. I'll wait.
  • It suffers from abbreviation overload, and it's not immediately clear to the reader what games are actually being referenced here. (MSR16OG-3DS is an abomination)
  • The games aren't even in the correct release order. Since these tables are pretty long it would be a nightmare to get all the cells in their proper places.

I think the solution here is to just reformat how we handle game compatibility for amiibo completely. I've created a very rough concept for how this could work. It could use some work, ideally, the bullet lists would be split up so we don't create a new problem of excessively long columns, and I'd prefer if the lists weren't centered though I'm not entirely sure how to fix that. Either way, even this early version this fixes pretty much all of the issues that the amiibo table has and presents the information clearly.
 
thing is, from using my computer, the tables already have left and right scrolls.

i think this page just needs to be better organized, we didn't realize that there will be this much amiibo support in hindsight.
The edits were done at 3, so you probably already saw the scrollable tables before this thread.
 
I think the solution here is to just reformat how we handle game compatibility for amiibo completely. I've created a very rough concept for how this could work. It could use some work, ideally, the bullet lists would be split up so we don't create a new problem of excessively long columns, and I'd prefer if the lists weren't centered though I'm not entirely sure how to fix that. Either way, even this early version this fixes pretty much all of the issues that the amiibo table has and presents the information clearly.

What if the table flows entirely lengthwise?

Pros:
- removes the empty vertical spaces caused in most cells by the game list stretching the table up and down
- the way I've set up this amiibo figure's chart, its code takes a few bytes less (147) than the version in your sandbox. in the long run, an article with this setup could be tremendously economical

Cons:
-may be tedious to scroll through, particularly on mobile
 
What if the table flows entirely lengthwise?

Pros:
- removes the empty vertical spaces caused in most cells by the game list stretching the table up and down
- the way I've set up this amiibo figure's chart, its code takes a few bytes less (147) than the version in your sandbox. in the long run, an article with this setup could be tremendously economical

Cons:
-may be tedious to scroll through, particularly on mobile
It's probably a lot taller than it needs to be (it's not really getting rid of the excessive empty vertical space, just trading it for empty horizontal space instead), and I don't think it's correct for a table to be organized that way anyway. EDIT: It also renders it completely unsortable, which could be an issue.

However I was able to find the coding I wanted for this and was able to update my table accordingly so now it's what I originally envisioned. I suppose you could argue that this still displays the information vertically which could in the future be a problem, but it's easily fixed by just increasing the amount of games per column as necessary (and five is just an example I went with here since it's a nice number), as opposed to the current table which can't really be fixed at all without overhauling how it works.
 
Last edited:
It's probably a lot taller than it needs to be (it's not really getting rid of the excessive empty vertical space, just trading it for empty horizontal space instead), and I don't think it's correct for a table to be organized that way anyway.

The empty horizontal space is entirely dependent on the width of your device's screen, though. On mobile, it looks fine.

Otherwise, I guess it's always better to opt for a horizontal flow for each entry if it can be optimised properly--and you seem to have done well manipulating that list of games in a "table" format of their own.

On the topic of tables and their scrolly-ness, I'm looking for some feedback on this project I'm working on: a history of Mario Kart 8 Deluxe tournaments held by Nintendo themselves, organised into tables. Early on, I allotted each tournament a single horizontal chart in a table, intended to comprise data such as the tourney's name, code, period, and any other relevant stuff (see the section "Mario Kart North American Open", which has remained intact in this form). For a lot of entries, this kind of "relevant stuff" became a varying amount of information that bloated or would have bloated the table in all directions, particularly the related images and the ruleset of each event. Even making the table scrollable wouldn't have really solved the issue of those related images having to essentially occupy a full row of their own for each table entry, breaking the downward flow of the table (wasn't gonna shove them into a single table cell, neither did I fancy making a wholly separate gallery for them). Because listing this info widthways looked less viable than I was imagining, I resorted to reformatting the tables similarly to what I showed prior. (See "Mario Kart 8 Deluxe Seasonal Circuit" section.)

I now assume some may find this direction faulty. What's your opinion?
 
The empty horizontal space is entirely dependent on the width of your device's screen, though. On mobile, it looks fine.

Otherwise, I guess it's always better to opt for a horizontal flow for each entry if it can be optimised properly--and you seem to have done well manipulating that list of games in a "table" format of their own.

On the topic of tables and their scrolly-ness, I'm looking for some feedback on this project I'm working on: a history of Mario Kart 8 Deluxe tournaments held by Nintendo themselves, organised into tables. Early on, I allotted each tournament a single horizontal chart in a table, intended to comprise data such as the tourney's name, code, period, and any other relevant stuff (see the section "Mario Kart North American Open", which has remained intact in this form). For a lot of entries, this kind of "relevant stuff" became a varying amount of information that bloated or would have bloated the table in all directions, particularly the related images and the ruleset of each event. Even making the table scrollable wouldn't have really solved the issue of those related images having to essentially occupy a full row of their own for each table entry, breaking the downward flow of the table (wasn't gonna shove them into a single table cell, neither did I fancy making a wholly separate gallery for them). Because listing this info widthways looked less viable than I was imagining, I resorted to reformatting the tables similarly to what I showed prior. (See "Mario Kart 8 Deluxe Seasonal Circuit" section.)

I now assume some may find this direction faulty. What's your opinion?
My take on it would be that if there's so much information that trying to format it into a table becomes unruly, you're probably better off not trying to work with those constraints at all. If it were me, I'd try writing it normally, and using tables sparingly if they would be helpful.
 
At one point I too was thinking of ordering the information for these events in a generic list (unless you're referring to writing about them in prose, which would potentially just pad out the page); though, it seems like such a format would make said information also flow entirely downwards. Is there a benefit to this arrangement over a chart-like enclosure?
 
Why not make a "List of compatible amiibo by game" and list only the amiibo compatible for a certain game in a chart? Like, Mario Kart 8 Deluxe would have its own section with its compatible amiibo as would the other games.
 
At one point I too was thinking of ordering the information for these events in a generic list (unless you're referring to writing about them in prose, which would potentially just pad out the page); though, it seems like such a format would make said information also flow entirely downwards. Is there a benefit to this arrangement over a chart-like enclosure?
I was thinking prose, not necessarily for the entire thing (structure would probably be fine staying as a list, at least), I wouldn't really call it padding, in theory you could boil down basically everything to just being tables if that was taken too far. But that's just my opinion.

As far as list vs. table goes, there might be conventions on when or when not to use tables, but I'm not aware of them. I don't think turning it into a list would be much of an improvement, though.

Why not make a "List of compatible amiibo by game" and list only the amiibo compatible for a certain game in a chart? Like, Mario Kart 8 Deluxe would have its own section with its compatible amiibo as would the other games.
I think the problem is pretty much resolved now, just needs to be implemented. Getting things converted over will probably be my next project when I have the time and motivation.

Either way, I think it'd be better to keep the information alongside the amiibo themselves.
 
There would not be much information to cover for each game with just listing amiibos, and even that little amount would get repeated ad nauseam since compatibility for certain figures is a property shared by many games.

The "List of enemies by game" page works because that one serves to show what new enemies each game debuted. A list for amiibos with a similar premise can't have that scope; it would need to be as comprehensive as possible for each game.
 
Back