Forum:A meta-template for standardised navboxes

Forums: Index > The Labyrinth of Time > A meta-template for standardised navboxes

Hey guys;

As you can see here, I've created meta-template - basically a template of a template - to be used in the coding of navboxes. I created this because I feel the navboxes on the wiki are somewhat inadequate and limited, as well as slightly difficult to code. The navbox code I've created is flexible and can be used as the base for any navbox, be it one of the side or one at the bottom of pages. It allows for collaspible sections basically anywhere while still allowing to change colors based on the different game (the only issue I see is transferring some code that allows an easy way for it to recognize the different games, though I think that's certainly plausible with parser functions).

Essentially; an easier to code navbox, just as (if not more) flexible than the ones currently existing, not overly reliant on css and in my opinion easier to use. One key thing I'd like to point out; for instance with Template:navbox FFVI, if I'm on a page for Abilities (like, say, Tools), then naturally I want to navigate to other Abilities articles, like Blitz. However, first I have to open the navbox at the bottom of Tools, and then scroll down to find the abilities, which aren't instantly obvious. With this navbox, the Abilities part would appear shown by default (once the rest of the template is shown), while the rest would be hidden. It just makes more practical sense for navigation, and that's only one thing that it can do. It allows the navboxes to look prettier in general, though they don't have to.

So what does everyone think? Should this be made official?--Technobliterator 22:24, February 25, 2014 (UTC)

		Kaimi - "I've been asleep more than a thousand years of my life. I did the math. Technically, I think that makes me the oldest hag on the planet. Not that I'll ever act my age. Wouldn't be much fun." TALK - 22:46, February 25, 2014 (UTC)
		Just looking at, e.g.: {{User:Technobliterator/Sandbox |1 ={{{1|}}} |editlink =Navbox example |title =Title |optionsB =collapsible |blockA =Block A |groupA1 =Group A1 |contentA1 =Content A1 |contentA2 =Content A2 |groupA3 =Group A3 |contentA3 =Content A3 |headerB =Header B |blockB =Block B |groupB1 =Group B1 |contentB1 =Content B1 |groupB2 =Group B2 |contentB2 =Content B2 |groupB3 =Group B3 |contentB3 =Content B3 }} and its results is very overwhelming, at least for me. I wouldn't really like to work with this, and I'm actually okay with our current template, no matter how prehistoric they may be seen. Is there an article you think is of an exceptional quality? Vote for it here!

		22:58, February 25, 2014 (UTC) Technobliterator Talk
		I'll be clear first of all; this is a meta-template. Say if you were to use that in Template:navbox FFVI. Once you've put it there, you'll never need to use that again, and will still just be using {{FFVI}} in the articles like before.

		Catuse says at 05:32, February 28, 2014 (UTC) "Somewhere a zealous god threads these strings between the clouds and the earth, preparing for a symphony it fears impossible to play. And so it threads on, and on, delaying the raise of the conductor's baton."
		It really isn't *that* hard to figure out how to use, and the common user never has to touch it; my main concern is how much of an effect this will have on loading times on say, Cloud Strife, with its ten million navboxes. If this isn't an issue I'll gladly start implementing this metatemplate this weekend.

Maybe this would be easier to judge if you actually gave an applicable example use. Like taking an existing page's navs and then re-creating it with the meta-template to show just how it would work. JBed (talk) 15:51, February 28, 2014 (UTC)

		17:36, February 28, 2014 (UTC) Technobliterator Talk
		To Catuse; firstly, it wouldn't cause issues for that page, if anything it'd arguably benefit the page. The navbox could technically nest all of those directly on Cloud's page to make it easier to just collapse them all. That's, once again, all optional. As for the loading times; I'm fairly sure that any changes it makes would be negligible if coded right. Too many nestings and it might hurt a bit, but from looking at that, there shouldn't need to be many. Secondly, I can (and would like to) help implement it, so we should probably make this a group effort. To JBed; yeah you have a fair point, and I'm perfectly happy to create an example. The navbox page does include plenty of examples there so I just figured I'd done enough, but I'll gladly make an example of something specific if you want me to.

		15:34, March 1, 2014 (UTC) Technobliterator Talk
		Quick update; I've recreated Template:navbox FFVI using the navbox code twice for reference. The colors I've left using the placeholders, as I think I have a better idea for them which I can discuss later, involving creating multiple css classes. Anyway; one version, and an alternative. The former makes use of only a single instance of the navbox which may make loading quicker but looks different, while the latter uses nested navboxes (navboxes within navboxes, essentially), but looks closer to the original. These are just various ways of using it. I quite possibly could use a single instance of the navbox to create something like the original, but I've just made these for now to show two very different uses.

Ignoring that it looks inferior, to show the actual benefit of the template: Template:Navbox/FFVIalt Basically you can nest it inside a parent navbox.

/rant

The coding and CSS still needs quite a bit of retooling to fit in with the style of the wiki. I'm also not happy with the parameter names. I would far rather you designed the meta-template specifically around our style of navboxes. If there's one thing we can benefit from template-ising navboxes it is that we can change our navboxes style more easily; but not if the current parameter names being used actually convey specifically how it will be formatted. The resolution is templates within templates, and this is something we would rather avoid.

The coding is not actually simpler than the existing navboxes.

And a fundamental flaw is still being overlooked. Our current JS for collapsible tables does not allow for collapsibles within collapsibles. I can actually write JavaScript that would do that, in fact I have but due to reasons I had to revert it.

Navs are currently handled in CSS, and so if assigned an element that would wrap around navs with a specific id or class, we could make the style of the internal navs to change and actually nest. However when I thought about how this would work, I ran into a problem.

What the is even wrong with our current nav system? Why do we think the navboxes at the bottom of Cloud Strife look bad? And if we don't like that then how do we even want them to look? Does this look better?

Techno, create navs for Kefka in the alt-style (FFWiki-style). You can do your standard style too, but changing how navs display content is part of a separate discussion. Then transclude on here how you expect the nav to display on Kefka's page. Then I can make a better judgement on what amendments would need to be made or at least the problem we actually have. JBed (talk) 19:58, March 1, 2014 (UTC) {{Navbox |title =Kefka navigation |nestedplainA ={{Navbox/FFVIalt|nested}} |nestedplainB ={{Navbox/Dissidia|nested}} |nestedplainC ={{Navbox/Dissidia 012|nested}} }}

		20:37, March 1, 2014 (UTC) Technobliterator Talk
		Transcluded above. Again, not final by any means. It currently looks sub-optimal, but without the different classes for each game, that's to be expected. Also, I don't understand your concern about the parameter names - but if they're that bad, then at least that's one of the easiest concerns to fix with ease. One thing that I haven't included yet on the navbox; it should be able to switch class for the template depending on which game (ie switch between the FFVI and the Dissidia classes on that one). EDIT: Having transcluded that, I now understand your concern about not being able to have collapsibles within collapsibles. You said you've written one, so you can either re-add it, or I have working javascript that allows that on another wiki which I can easily fetch.

I'll work on the JavaScript now. JBed (talk) 21:31, March 1, 2014 (UTC)

Ta-da! JBed (talk) 14:58, March 2, 2014 (UTC)

		15:30, March 2, 2014 (UTC) Technobliterator Talk
		It works! Aw, sweet. What's next? Sorting out the classes for the different games/parts of the navbox and working out what we want? Or is there anything else in particular I've missed before this could become official?

		21:40, March 8, 2014 (UTC) Technobliterator Talk
		The navbox is now completely finished. It's now a case of how we implement it, and whether we should. What's everyone's thoughts?

		Jimcloud TALK - 23:09, March 10, 2014 (UTC)
		Okay, I could not even begin to work on altering this in a way that I would like, so I'll just list my problems with the specific design listed above. There are two. One, the collapsibles within collapsibles being collapsed by default seems to hinder navigation to me more than it really aids it. Instead of the current system, where you click once and have access to everything, here you would have to click and then mouse and click and mouse and click to get access to a portion of it. If you're just browsing around, that's a lot of clicking. The other thing is the color. The way you have things now, where they each have their own section, makes it so that there is a lot of the sub-color of a template, just a bit too much in my humble opinion. I like the idea of this, but I'm just not sure how much use it will really see in practice. :\

		22:07, March 11, 2014 (UTC) Technobliterator Talk
		Your issues are subjective, though certainly valid. Collapsibles are a complete non issue in truth; it's incredibly easy to just set the options to make things collapsed/uncollapsed by default. It would just depend on what everyone thinks when they are implemented. As for the colours; I've removed a bit of the color just to test the water and see what it's like without. I prefer it with color, but that's just me. Once again, that's also an issue that's incredibly easy to fix for every navbox with minimal effort if the general opinion changes.

		17:55, March 12, 2014 (UTC) Technobliterator Talk
		Quick update; I've recreated (identically) the Translations box using the metatemplate: here. I'm personally not a fan of the original, and I think it could be improved - which is very easy to do with this metatemplate - but I've made it stay true to the first version, as a demonstration.

Hang on, hang on. Before we make this a thing I would like my mind-settled on a few things.

First there is this:

"It allows for collaspible sections basically anywhere"

How do you think this will benefit people? If we used cookies to remember the state I could see it, but we're not going to do that.

The relevant-section-only-one-not-collapsed isn't in use, right? To clarify my position, I aim in the boat of "I'd prefer all the inner-things uncollapsed".

"Essentially; an easier to code navbox"

There is no evidence to suggest this. In this wiki tables are inevitability and almost everyone will learn the basics of how to use one. The Navs use this same coding so they are easier for people to use. They follow a logical structure that can be easily imagined, and aren't full of random parameter names.

"not overly reliant on css"

I don't know what that means. But that's the beauty of it. Everything is handled in CSS. One of the aims of this template is meant to be something like "change the template and you change them all", but that is demonstrably not true, or at least no more true than it is for the current system. You still have to input the game's class, you still have to input the name of the template.

Well, almost. I'll give you one thing, your template doesn't rely on cellpadding. But that one thing is all but lost when you know it uses dead columns and rows to produce the same result.

If this template truly allowed for a "change the template and you change them all" system it wouldn't rely on context-specific parameter names. There'd be "header#", "group#", and "content#". None of this "A1" "A2" stuff, because once you've done that you've stated the structure of the navbox.

And if this template was to change them all, then how comes we can't change the structure of the navboxes without editing them all? If I can't edit the template to turn [[Template:Navbox/FFVIalt|this format]] into [[Template:Navbox/FFVI|this format]] without having to edit every single navbox then this template simply does not deliver.

The other thing is the Kefka thing. Put navs in a collapsible. But there are few problems here. First: are we even going to use it? I still don't see the mass of navs on Cloud Strife as a problem, or at least not one solved by putting them in another collapsible. Second: CSS can solve the problem in the exact same way. Except with CSS there would be no need for the "nested" parameter to be added. And third: JS can solve it too! Detect how many navboxes are on the page, if more than x (and in mainspace) then wrap them in a navbox. It's not that hard, navboxes always go at the end of the article anyway, I can just create the new element, move the navboxes to that element, then append it at bottom of content.

So my problems:

1. I don't see benefit in the additional collapsibles.
2. I don't think it's easier to code.
3. I don't think it is any better for changing all navs at once.
4. We can do the nesting functionality without needing to edit a single navbox or article.

Don't get me wrong, there is benefit in meta-templates. If I was tasked to write one I would write mine differently. Not relying on a catch-all just so it can do Translations-style navs in the same template as footer-navs (better off with two). Giving /less/ flexibility in the transclusions (because we want uniformity, not flexibility), but /more/ flexibility in how the design can be changed.

So if we ever decide to change how our navboxes are created in the future, I would call on meta-templates. But not right now, I don't think we're making them easier and I don't think we're gaining anything in terms of a better structure.

Now I would like anyone (anyone!) to convince me that my points are wrong. Tell me the code would be easier to understand and write, tell me that there is benefit in the additional collapsibles, tell me where it could be used to change the appearance of navboxes where the current CSS system can't.

Because I don't see it. It looks like we're just gaining a few functions we're not going to use and be in no better position.

Also if we're going to go over to meta-template it might be wise to let someone write a RegEx script to handle it automatically. Or at least let someone try to write a RegEx script before they give up and let you do it manually.*(that someone would be me. unless someone else can)

/rant JBed (talk) 02:58, March 18, 2014 (UTC)

		{{{time}}} Technobliterator Talk
		Alright, thanks for stating your issues, before I went ahead and changed everything. I'll try and address them one by one, however, I do think that most of them are fairly subjective. First of all, the benefit in additional collapsibles. This issue is a very subjective one, some people like collapsibles, others don't. The collapsibles, like I said, are easy to manipulate, so really it would all go down to a general consensus on what collapsibles we need. I personally like being able to filter through navigation to pick the right thing I want. And no, the "relevant-section-only-one-not-collapsed" is not in use. It could be eventually, but I'm not changing the navboxes themselves here, just the code behind them. Secondly, do you see a downside in additional collapsibles? Because if there's no benefit or downside, then the only position you can retain is an indifferent one, meaning there is no issue. As for your second point. Once again, this is subjective. I don't personally see how mine can be seen as difficult to code. In fact, to me it seems to make more obvious sense to the average user than cellpadding, when the words themselves are clear. I'm fairly sure by looking at an navbox code one could understand how it functions without ever looking at the document for the navbox metatemplate at all. For me, certainly, it's much more user friendly. Once again, it is difficult to really make a proper case either way for this point, as it is so subjective. I would make a point that it'd take a lot less writing in AWB to change everything for this code than it would for the various cellpadding. That, and it's also much easier to copy paste to every page for this than it is for the other. There are also some changes that the navbox can handle - I'm not saying we will ever want to, but in the hypothetical scenario that we ever had to make new css classes the navbox had to use, or that we wanted to make the borders round, for instance, then the metatemplate can handle it. Yes, but is it as simple to do? Is it as easy as writing "|nested"? Because I highly doubt it is. Yes, it's doable, and I can see how it would work, but it doesn't seem as simple. The Kefka nav I made was just a prototype. Like I said, this isn't a discussion about changing the navboxes, it's changing what code creates the navboxes. If I wanted to make everything more like Navbox/FFVI, then I would make that a separate discussion. Are we going to use it? Maybe, it depends on what everone thinks. "If I can't edit the template to turn this format into this format without having to edit every single navbox then this template simply does not deliver." Except we can. It's a simple task that AWB and/or copypasting could handle with no major flaws. There's also no reason why you can't edit the template to change the formats, either. I just didn't want demonstrate that for the sake of demonstrating a possibility which should be fairly apparent anyway. Simply having the parameter names do different things in itself could solve that problem. Sure, the parameter names would probably become inappropriate for their function if that happened, meaning that AWB's involvement is inevitable, but it to me seems a far simpler process than what currently exists. As for metatemplating it all, I don't think a RegEx script is even necessary. I can edit everything just fine, it would just take a while. And I'm not sure I'd be the only one doing it. Overally; your issues seem mostly subjective and I think either you're demanding too much of the template, or I'm not delivering enough. The reason templates exist is so one doesn't have to put the same code on every page, it'd be like remaking an infobox bit by bit, cellpadding by cellpadding every page. That's why templates exist, so one does not have to do that. And similarly, this navbox metatemplate was created, for a similar reason. I'll conclude by stating that the template includes the possibilities, and whether we have any need for them or not, they are there and easier to implement should it be decided we want them, and I personally think that alone is a reason for adding it. My final reason would be that, if this doesn't affect the common user much in any way, then there's no harm being done.

You started talking about cellpadding and I got confused. The comment about cellpadding is related to the HTML attribute all tables have. They have a default of 2. And you can't simulate cellpadding in CSS (you can simulate cellpadding 0 which will override the default table amount). That is, unless you do what the meta-template does and add "dead cells", cells that contain no content but are set to a height or width. Which is a concept that I find offensive, probably more than I should.

"but in the hypothetical scenario that we ever had to make new css classes the navbox had to use, or that we wanted to make the borders round, for instance, then the metatemplate can handle it."

Yeah, right. That is my point. It has the same flexibility-in-terms-of-modifying-the-base as the solely CSS-managed system at the moment.

"Except we can. It's a simple task that AWB and/or copypasting could handle with no major flaws."

Right. Same story with the current system. But that's not important:

"There's also no reason why you can't edit the template to change the formats, either."

No, if we use the same meta-template for both the Translations nav and the footer nav you lose any possibility of doing that. You'd have to make further templates specific to both formats that would embed {{Navbox}}.

"As for metatemplating it all, I don't think a RegEx script is even necessary. I can edit everything just fine, it would just take a while."

*raises eyebrow*... and I can write a script in a shorter time and save you the long while it would take. Scripts and bots are never necessary. How can you say all this about AWB but then say that? AWB probably uses RegEx itself, or if the user doesn't see it then the user probably interacts with an interface that itself interacts with RegEx.

"Yes, but is it as simple to do? Is it as easy as writing "|nested"? Because I highly doubt it is. Yes, it's doable, and I can see how it would work, but it doesn't seem as simple."

... Yes. Because it doesn't require editing any pages bar Common.js (and a minor addition to Wikia.js to call it from the preview panel). I could write the script in five minutes.

Your comments about subjectivity... The meta-template is objectively better in only some small ways, while it is objectively worse in some ways that in the grand scheme of things are small. This is why I implored anyone to convince me otherwise. Almost everything is built upon subjectivity. If people are going to be using the system then I'd like to hear those people telling me which code style they prefer, and if anyone does see benefit in additional collapsibles. JBed (talk) 19:47, March 18, 2014 (UTC)

I did a benchmark test that suggests the meta-template takes 0.0265 seconds longer to load (per nav template). (I don't know how temporary these page are: [table+class], [meta-template+class]. I didn't do thorough tests, you could probably get a different result. ParserSpeed puts less than 6 seconds between them (4.174 s v. 10.043 s, so that's 0.06 per template).

Wildly different figures. ParserSpeed sometimes outputs random numbers so it could be put down to that. But I'm not sure how reliable WebPageTest is. JBed (talk) 20:17, March 18, 2014 (UTC)

		{{{time}}} Technobliterator Talk
		This is a lot to take in at the moment, but I'll try to reply to your points as best I can. Firstly, I wasn't 100% certain about your terminology here, and I just assumed you were using the term 'cellpadding' to refer to something completely different. I don't know why I thought that, being completely familiar with the term, but I did, so at least we're now on the same page, I suppose. Okay, so the flexibility, ease of change, I suppose that yes, they are both equal, which I realize myself. And there are simple tasks that bots and copypasting can solve in both cases, sure. But when you separate things by |groupA, B etc, then that's much easier to filter through than the table code that it currently is. I suppose that's not the main advantage of the metatemplate that I was putting across. The main one is a more unified code. As for nesting, no, that wasn't what I was getting it. The current navbox doesn't require any common.js editing. On the boxes themselves, it would likely take up more words overall than |nested would. Of course...come to think of it, the metatemplate takes up way more text in the code in general. So to call that a benefit of this template is hypocritical there :D Well...I guess there's the fact that the ability to nest comes with everything else. The navbox taking longer to load pages was a given, really. If anything I'd say those results are alright, as they're a bit better than I expected, taking all the nesting into consideration. Assuming by "per nav template" you mean in terms of "FFVIalt"; if you mean in terms of each nest, then they're about what I expected. WebPageTest mightn't be the most reliable source of information, but it's better than nothing. I guess if there are objective upsides and downsides both ways, and in the long run like you said people will get used to things anyway. It's just a case of, do we want some possibly options added and a unified code in return for making the navbox codes a little more complex (if easier to understand and filter), and a slight page load difference (which won't be too noticeable anyway)?

		Xenomic TALK - 22:29, March 23, 2014 (UTC)
		Truth be told, I'm not quite sure if I like this or not. It's organized yes, but it's also a bit more annoying to find things. I liked it better when I could just open a template and skim down the list to see what I want to find. Was a lot easier for me that way, but that's me.

		22:34, March 23, 2014 (UTC) Technobliterator Talk
		Are you talking about everything being hidden by default on the navbox? Because that's subject to changed (and can be changed easily).

		Monterossa - "This is my story." TALK - 20:56, March 24, 2014 (UTC)
		Yes, please make the sub-headers don't hide themselves by default and I'll like these new navbars more.

		Xenomic TALK - 04:08, April 3, 2014 (UTC)
		I'm not sure if this is a side effect of this project, but it seems on various Concept Art pages (I don't recall if the Translation pages are like this too) don't seem to want to hide the template at the top of the page (and you can see the (OnlyInclude) line on said page). Did something break??

		Arciel Spira - Total loser. Arciele Spira (talk) ∙ Talk ∙ Contributions
		I've been away. Someone please tell me why Template:FFXI looks fucking hideous and you can't collapse/hide shit in it (or say Template:navbox FFVI) anymore or I'm going to start Firaga spamming till they burn in hell. And whose bright idea was it to have them open by default?

		16:59, April 4, 2014 (UTC) Technobliterator Talk
		Thank you for providing the most constructive feedback in all of history. I have no idea why this forum is still open. Use Template:FFXI's talk page next time. I'll tell you why "you can't collapse/hide shit in it"; because it's bugged. Your idea of "spamming Firaga til I burn in hell" is clearly an inadequate solution considering that I could also be fixing the bug. I did just fix it, actually. "And whose bright idea was it to have them open by default?" Maybe this is a completely subjective thing and some people like them open by default? But regardless, once again, it is bugged. Or rather it was, as I now fixed it. So yeah. Bugs happened, bugs have been fixed.

most welcome. the XI template is still a total mess but this will have to do for now. ugh--Arciele Spira (talk) 17:45, April 4, 2014 (UTC)

Messes happen while editing is taking place. I apologise you weren't told absolutely everything new that had happened here during your absence, but the rest of the templates are shaping up nicely through Techno's work and with some tweaking I'm sure XI's will look just as good after it's been worked on. My warning on the template talk page stands though. Tia-Lewise 19:16, April 4, 2014 (UTC)

i'm actually disappointed that people think i'm genuinely pissed when i talk about spamming Firagas >_> on the bright side, if i didn't complain this way all the templates would still have been bugged.--Arciele Spira (talk) 19:31, April 4, 2014 (UTC)

		Monterossa - "This is my story." TALK - 16:06, April 5, 2014 (UTC)
		Since everything is not being hidden by default now, what's the point of these "hide/show" options anyway? I don't think anybody wants to click "hide" some part of the navbars just for fun. Hidden section in FFXI navbox makes sense but having hide/show options for every sections seem pointless.

		16:37, April 5, 2014 (UTC) Technobliterator Talk
		Because some people (ie me) like them? The basic compromise is that if we don't have everything hidden by default, we can at least have it shown with the option to hide it by default. You'd close off the things you don't want to navigate. If I'm looking at the FFVI nav, and I don't want to look at everything about Abilities, I'd hide them. In future, I would like to move the discussions to Template talk:Navbox or to my talk page in future, as I no longer use this forum. I feel like this forum can be archived.