FANDOM


FFWiki forum logo
Forums: Index > The Labyrinth of Time > Navbox Overhaul 2018


Technobliterator

Votes

Proposal #1

  1. Support as proponent.--Magicite-ffvi-ios Technobliterator TC 03:13, April 13, 2018 (UTC)
  2. Aside from all the reasons mentioned, I have to approve of anything that reduces the need for designers to code in metatables (or did we drop that module already? Like I said it's been a while...) What are the disadvantages to exporting to devwiki? Do we lose control over some things, for example? So, tentative support. Cat (meowhunt) 06:45, April 13, 2018 (UTC)
  3. Support, load times are noticeably improved. My only concern is, what if Dev Wiki does an update we don't like? DrakeyC (talk) 09:34, April 13, 2018 (UTC)
  4. Support as proponent. DarthKitty (talk) 07:17, April 14, 2018 (UTC)
  5. Kaimi (999,999 CP/5 TP) ∙ 07:22, April 14, 2018 (UTC)

Proposal #2

  1. Support as proponent.--Magicite-ffvi-ios Technobliterator TC 03:13, April 13, 2018 (UTC)
  2. Essentially I agree with JBed: support as long as every navbox has the key links. {{navbox FFXIV}} is an abomination and it's only going to get worse. Cat (meowhunt) 06:45, April 13, 2018 (UTC)
  3. I think an XML solution that we used to automatically generate a navbox per-page based on where the page is linked to would be swell, but I guess this is quicker and simpler. Support. JBed (talk) 18:37, April 13, 2018 (UTC)
  4. Support. Smaller navboxes = less HTML = faster. As others have said, providing relevant links at the top (or bottom?) should be enough to prevent lock-out. DarthKitty (talk) 07:17, April 14, 2018 (UTC)
  5. Actually Aselia (Tales of Wiki) has two types of a template per game: one for characters and one for data, and I think it works pretty good there, so yeah, let's do it.—Kaimi (999,999 CP/5 TP) ∙ 07:22, April 14, 2018 (UTC)

Proposal #3

  1. Support as proponent.--Magicite-ffvi-ios Technobliterator TC 03:13, April 13, 2018 (UTC)
  2. Ironically I was going to oppose this on the grounds that the bot would have a hard time with the relinking... but then I realized that the only reason the bot might struggle is because the naming scheme is so bad. Making our code more machine-readable is an unconditional support from me. Cat (meowhunt) 06:45, April 13, 2018 (UTC)
  3. Support, this is long overdue.DrakeyC (talk) 09:34, April 13, 2018 (UTC)
  4. Support. I can't think of any downsides to this change. DarthKitty (talk) 07:17, April 14, 2018 (UTC)
  5. Kaimi (999,999 CP/5 TP) ∙ 07:22, April 14, 2018 (UTC)

Discussion

I support Proposal 2 as long as FFVI Characters still has links to the "upper" links, e.g. Allusions and Locations. JBed (talk) 03:52, April 13, 2018 (UTC)

Guessing this includes all the split navboxes, and not the FFVI characters box only. Not a problem, this was likely going to be the case regardless.--Magicite-ffvi-ios Technobliterator TC 06:07, April 13, 2018 (UTC)

I won't pretend like I understand how anything works anymore but Techno summoned me from the grave so I guess I'll comment. Cat (meowhunt) 06:45, April 13, 2018 (UTC)

My concern with proposal 2 is how it can affect navigation negatively. Terra's page gets FF6 Characters, but what if someone who is browsing FF6 in general wants to check out the location nav? I agree reducing the number of visible links to avoid overwhelming visitors is fine, but it seems that setting the subsections that exist in the current version to be collapsed by default could solve that. DrakeyC (talk) 09:37, April 13, 2018 (UTC)

Normally, someone checking Terra's page would either find a link to the location they want in the body of the text itself, or the navbox would still give them a link to the list of locations page, which they could use to find what they wanted. If they're browsing FFVI generally, they may be more likely to use the base page to do that though. As for why we don't just collapse other sections: it's possible, but studies suggest adding more options does not benefit performance. see link 3 for more on this.
As for Dev Wiki making a change we don't like, their navbox is already pretty stable and the only changes they could make would be to add features (which wouldn't affect us unless we requested them), and the fact that other wikis use it plus us means that they're less likely to screw us over.--Magicite-ffvi-ios Technobliterator TC 10:16, April 13, 2018 (UTC)
Also, Dev is still a wiki, in case of emergency we can just grab an old revision - or if that fucks up too, restore the version we currently use - and switch to local code. -- Some Color Mage ~ (Talk) 10:21, April 13, 2018 (UTC)

I posted an example of split navboxes. If anyone would like to make any adjustment to these in particular, please let me know! Also, let me know if we should go with the split "locations" and "setting" or just combine them.--Magicite-ffvi-ios Technobliterator TC 21:50, April 13, 2018 (UTC)

An idea; what if there were some convenient way to switch between subnavs on a page without having to leave the page? Like if the infoboxes were each in their own tab (though let's definitely not do tabs). DrakeyC (talk) 22:23, April 13, 2018 (UTC)
I see what you mean, like a kind of tab button to select which one displays? Don't see the problem with this in terms of design, even if I don't know how we'd do it in practice.--Magicite-ffvi-ios Technobliterator TC 22:29, April 13, 2018 (UTC)
Isn't that effectively the same as collapsibles but only making the relevant ones open by default (e.g. Characters on Terra Branford)? JBed (talk) 23:44, April 13, 2018 (UTC)
I made a demonstration of auto-collapsing sections, to see how well that'd work. While it does an okay job of reducing choice paralysis, it's worse off in two other areas:
  1. Complexity: as Techno and Cat already mentioned, Template:navbox FFXIV is huge. Rather than alleviating the problem, this would actually make it worse, by adding {{#if:}} and {{#ifeq:}} expressions all over the place. It would also introduce a parameter to every navbox, in order to signal which section should be expanded by default.
  2. Performance: this would generate about the same amount of HTML as before, so it would be significantly slower. Furthermore, the expressions and parameter I mentioned above would increase the amount of time it takes to parse each navbox.
All in all, I'm 👎 on the idea. DarthKitty (talk) 07:17, April 14, 2018 (UTC)

Looks like most were in favor of the plan, so I've now implemented it. Few tweaks were made in Discord on some specifics. Piloted at Template:Navbox FFVI, Template:Navbox characters FFVI, Template:Navbox setting FFVI and Template:Navbox abilities FFVI. I will move all navboxes to this new format hopefully, and once navboxes are split, will then rename infoboxes.--Magicite-ffvi-ios Technobliterator TC 18:12, April 28, 2018 (UTC)

Conclusion

Technobliterator
Community content is available under CC-BY-SA unless otherwise noted.