Talk:Request for Comment -- (Item property) template design / structure / naming policy

Forums: Index > Help desk > Request for Comment -- (Item property) template design / structure / naming policy

I been thinking a lot about the templates being built / refactored for item modification descriptors. I think the direction we need to be moving with these particular templates is to have them be more specific, and less bloated. The pros of having a single template handle multiple descriptions is that there is a single point of maintenance. Changes need to be made in only one place. The cost is that the code is complex, and difficult to maintain. ( a side effect to the code being more complex is that the templates require protection to keep the average editor from breaking the template accidentally )

The benefits of flattening out ( more templates, less complex ) the item modification templates outweigh the benefit of having fewer / more dynamic / smarter templates.

Point 1) If a template is more specific, it wont need the extra logic that is required for more complex templates that do a lot of decision making to determine what to display. Meaning it will be cleaner and easier to modify.

Point 2) There will be a performance increase with the reduction of logic processed by bulky templates. ( You mentioned load times and core processing being a concern before, more templates and less logic will definitely work towards that goal )

Point 3) If the templates do less, and are cleaner, that means it doesnt take a high skill level to create or update templates. There will be less of a need to protect the templates so they could be unprotected and the community can play a more active role in updating the site.

CounterPoint 1) Flattening out some of the complex templates means more templates ... LOTS more templates. A template for each value for each variable means an exponential explosion in the count of templates to build. It's a hard pill to swallow, but if done right ( thinking multiple tiers // cascading templates with single variables, minimal (if any) switch and if statements ) it can be designed to where changes cascade and can be done in one place to reduce duplication.

I think a template coding guidelines / policy needs to be created. I'll try and put a first draft together over the next couple days, unless you already have something tucked away somewhere.

Joenuts (Contributions • Message) 23:09, February 28, 2013 (EST)

I'm not sold at all on having more templates. Let's start with this question: what templates exactly do you think need to be broken down?

I want you to think about this carefully. Keep in mind, of the editors that know anything about creating templates, "most" do not want to work on templates.

Understanding how to successfully build templates is a looong slow learning curve. Take for example inclusion tags... There is a fine line difference between an onlyinclude and an includeonly, and requires a bit of time to sit and learn the difference. Then there are parser functions, string functions, variables, loops, magic words, substitution, number formating, and the list goes on...

At this time on this wiki, the people that are currently active that I know have tried creating templates (of which most of I had to fix or do most of the building for them) are; Backley (Contribs • Message • Email), Bladedge (Contribs • Message • Email), Cru121 (Contribs • Message • Email), Mjoll (Contribs • Message • Email), Yawgmoth (Contribs • Message • Email), and you. I know that Yoko5000 (Contribs • Message • Email) has also made some very basic templates back in the beginning but is not fond of the process at all and that was before I had Xevo (Contribs • Message • Email) add three more template logic adding extensions.

The rules for template protection that I have been trying to set into place are:

1. If the template is in Meta templates  - it is fully protected.
2. If the template is more than two edit windows long (using the system default, which I have set my personal to 2x) - it is fully protected.
3. If the template uses more than two extensions, or uses the loops extension - it is fully protected.
4. ALL other templates - semi-protected.

ShoeMaker (Contributions • Message) 08:16, March 1, 2013 (EST)

I've created an example structure of what I had envisioned using the first item description template on the list, Template:Absorption.

{{#if:{{{3|}}}|{{#switch:{{lc:{{{2}}}}}|0|{{long popup|[[Absorption|{{#switch:{{lc:{{{1}}}}}|negative|negative energy=Negative Energy|#default={{ucfirst:{{lc:{{{1}}}}}}}}} Absorption]] ({{{3}}} charges{{#switch:{{lc:{{{4|{{{3}}}}}}}}|0|no|none=|#default=, Recharged/Day:{{{4|{{{3}}}}}}}})|'''[[Absorption|{{#switch:{{lc:{{{1}}}}}|negative|negative energy=Negative Energy|#default={{ucfirst:{{lc:{{{1}}}}}}}}} Absorption]]''': This effect absorbs {{#switch:{{lc:{{{1}}}}}|spell=harmful spells targeted at the wearer.|negative|negative energy=negative energy and energy drain effects.|whirlwind=air elementals knockdown attack.|#default=undefined}}}}}}|{{long popup|[[Absorption|{{#switch:{{lc:{{{1}}}}}|negative|negative energy=Negative Energy|electric|lightning=Electrical|#default={{ucfirst:{{lc:{{{1}}}}}}}}} Absorption {{{2}}}%]]|'''{{#switch:{{lc:{{{1}}}}}|negative|negative energy=Negative Energy|electric|lightning=Electrical|#default={{ucfirst:{{lc:{{{1}}}}}}}}} Absorption {{{2}}}%''': This effect absorbs {{#switch:{{{2}}}|25=one-quarter|33=one-third|50=one-half|#default={{{2}}}%}} of all {{#switch:{{lc:{{{1}}}}}|electric|lightning=electrical|elemental=acid, cold, fire, and electrical|#default={{lc:{{{1}}}}}}} damage the character would have taken, after all other protections have been penetrated.}}}}

becomes :

{{Long popup|[[Absorption|Acid Absorption {{{1}}}]]|'''Acid Absorption {{{1}}}''': {{AbsorptionPercentDescription|{{{1}}}|acid}}}}

for Template:AcidAbsorptionPercent Template:ColdAbsorptionPercent Template:ElectricityAbsorptionPercent Template:ElementalAbsorptionPercent Template:FireAbsorptionPercent Template:NegativeEnergyAbsorptionPercent Template:SonicAbsorptionPercent

and becomes :

{{Long popup|[[Absorption|Negative Energy Absorption]]|'''Negative Energy Absorption''': This effect absorbs negative energy and energy drain effects.<br />'''Charges''': {{{1}}}{{#if: {{{2|}}}|''' Recharged/Day''': {{{2}}}}}}}

for Template:NegativeEnergyAbsorption Template:SpellAbsorption Template:WhirlwindAbsorption

I think using more and more logic inside templates to determine WHAT should be displayed should be avoided, as I see the natural progression of that is a single super template that has a dozen different variables and is a nightmare to maintain. Template:Dmg is I think one of the heaviest templates that comes to mind. For an item that does Vorpal damage to have to parse through the hundreds of lines of code for every other damage type I think is maybe not the best direction. By creating multiple templates, there is minimal need for logic. Only one if statement is required, and it is used to determine whether or not recharged should be displayed, and it only exists for the absorption items that are charge based ( not percentage based ).

I hope you see the value and agree that splitting out the templates is a better direction to go ( I used the term "flatter" before, but that may not have been the correct description ). I can do the legwork to create the templates (it's a bunch of simple templates copied for each modification, so not a log of brain power required ). Swapping the actual items to use the changed templates will be something that's best automated, and I dont mind setting up routines to do that either, but will just need some direction on what tools to use.

Joenuts (Contributions • Message) 17:35, March 2, 2013 (EST)

What you seem to be forgetting, is the average editor has less than 100 edits. So, expecting them to know or remember over 500 templates when we only need less than 100 is excessive. By breaking it down and requiring people to use hundreds of new templates, you scare away the occasional editor. I don't consider this desired behavior. Templates are intended to be full of logic and it's not an issue for them to be extremely complex, as long as they are end user friendly. I agree that there are still some templates that need some more user friendly modifications, and Turbine-DDO's instance on changing the way everything works is putting most of my focus on the high end templates and the lesser ones are being neglected. As I said before, the average editor doesn't want to edit templates, so there is no reason to dumb them down. I would prefer you didn't break down any more templates at this time, and start a discussion for all of the administrators to consider your proposal.

ShoeMaker (Contributions • Message) 18:45, March 2, 2013 (EST)

I truly believe that my approach of having more templates would make it EASIER for the average editor, not more difficult ( and less processing on the server ). For example, if we had a template for blindness immunity CALLED {{blindness immunity}} then the editor would not have to lookup that it's the {{immunity|blindness}} template that displays the blindness immunity property. I'd certainly like to go over the pros and cons of the approach and get community ( / administrator ) input. Where would be the best forum to discuss?

Joenuts (Contributions • Message) 22:58, March 2, 2013 (EST)

Go to Help desk, type in a topic title, and click "Start new topic" button.

I also am thinking it is going to be allot harder to maintain 500-1,000 templates on MediaWiki:Edittools than it is the 100 or so we have now... Are you going to work on that as well?

ShoeMaker (Contributions • Message) 15:52, March 4, 2013 (EST)

I certainly would not be opposed to updating the edittools. I'm not familiar with the syntax, but I should be able to figure it out looking at what's already there. If every template is to be added to the tools ( ideal ), then more organization is warranted. The two ideas that pop in to my head would be to group alphabetically, or to group categorically. Alphabetically may be better for the end user, but it's going to have some bloated letters, like G for 'greater' xyz bane.

Joenuts (Contributions • Message) 17:36, March 6, 2013 (EST)

Brief to the point uhhh NO to having every ability have its on template. As long as the same effects are group together like elemental resistance, damage etc I dont see the need for hundreds of small individual templates just picturing what happen if they make one change then going through a dozen templates instead. of one. Rather see well documented templates that be modify without looking up the code does.

18:05, March 7, 2013 (EST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'd like to get some input / opinions on the following proposals.

1) As it pertains to the templates being created / updated for item properties I'd like to see an official policy concerning the design / naming / layout implemented.

• Pros
  • Consistency - It will be easier for all editors/creators to remain consistent with a policy that can be referenced and followed
  • Clarity - A clearly defined policy would eliminate any confusion between editors
• Cons
  • Work will have to be put in to create and document such a policy (started -- see proposal )
  • Work will have to be put in to make all item property templates adhere to the policy (in the middle of template revamp / refactor at the moment )

2) Concerning the existing structure and design of item property templates, I propose that templates be brought more in line to match the property that exists in the game.

• Pros
  • It will be easier on the people that use the templates.
    • Editors need only know the property description
    • {{Blindness Immunity}} as opposed to {{Immunity|Blindness}}
    • {{Lesser Turning}} as opposed to {{Bonus Turning|2}}
    • {{Sneak Attack Bonus|+5}} as opposed to {{Backstabbing|5}}
    • {{Greater Humanoid Bane}} as opposed to {{Bane|Humanoid|greater}}
    • {{Acid Resistance|20%}} as opposed to {{res|20|acid}}
    • {{Exceptional Strength|+2}} as opposed to {{stat|2|str|exc}}
    • {{Shocking Burst}} as opposed to {{dmg|shockingburst}}
  • It will create less load on the server when templates are transcluded
    • If the template does not have to check against a dozen ( or in some cases over a hundred ) strings every time template is loaded, there will be less processing required by the server
  • Templates will be more brief, making it easier for the casual editor to modify or create templates
    • ( Side effect of this quality is that fewer item property templates will need to be protected, thus allowing more of the community to modify )

• Cons
  • More templates would be required for this transition ( LOTS more templates )
    • Some existing templates cover over a hundred item properites. The current pool of about 100 item property templates would explode to around 500 templates.
  • As new degrees of modification are created by developers, new templates would have to be created for every property that matched.
    • Example: Soverign resistance gets created by developers, since it can apply to five item properties, five new templates would need to be created.
    • As opposed to modifying a single template to add another value to a variable that is passed in

I've started an example policy for User:Joenuts/Item property template policy. I also have a proposed list of the templates that would need to be created to conform with such a policy User:Joenuts/Item property template matrix. Creating the individualized templates is a big project, but I would be personally willing to take it on as I feel that is a step in the right direction ( many unique templates as opposed to a few super templates ). I feel we're slowly working our way towards a mega template that you just pass in a dozen variables to in order for it to display the appropriate property. That direction would cripple performance, require the template to be protected due to the sites heavy dependance on it, and require a highly skilled maintainer to be able to make modifications.

Please share any thoughts you have concerning the above topics. I tried to be fair in my evaluation, if anyone feels that I've missed anything, or needs more clarification on my points, let me know. -Joe

Joenuts (Contributions • Message) 16:31, March 6, 2013 (EST)

I am not persuaded.

• Server load: I don't know much about server load, but afaik there are problems only with a handful of long pages (e.g. u17 loot article)
• As mentioned by Tech elsewhere, casuals don't edit templates. No need to make them more accessible.
• I don't care if a template is complicated to write (that's tech's problem :P); but we should strive to make them easy to use. Your proposal goes in the right direction, but I think a bit too far. dmg template is imho a great one, easy syntax and works as expected. Other templates like res or false life are a pain to use, they should be updated somehow (first step would be that the magnitude x should equal the amount of hp/resistance, and not be some predefined value).

So I guess my summary would be: let's split only those templates that have too complex syntax to be used by editors.

--Cru121 (Contributions • Message) 03:50, March 7, 2013 (EST)

Okay, I'm glad this is moved off of my talk page into the open for all to discuss. For those of you interested in how this topic began, I recommend checking out the Few BIG Templates or Hundreds of little templates. section of my talk page.

We currently have 185 Item description templates  (including 17 that have been deprecated); this leaves 168 active item description templates. Your proposal of one template for every item effect as listed on items to make it easier for a casual to use and edit the template would increase this template count to about 987 (there were a couple that I couldn't calculate what it would break down into).
I don't see how that makes it any easier on the casual editor to use. If anything, I would think it would be more difficult.
Now, there are some templates that I have not had the time to work on yet, and have been around longer than I have. Those templates most certainly need some work to make them easier to use, and I have attempted to mark most of them with Item description templates in need of a complete overhaul  or Templates in need of deprecation . I encourage anyone that finds a template that is hard to use to add this category to the template if they want to draw my attention to it for fixing. I will either fix the currently template, or scrap it and build it from scratch (as I have done with T:Stat and T:Skills). My current goal in that aspect is to get the new templates built for the new effects being introduced and making all of the current templates uniform in layout (which in of itself will make them easier to edit).
Furthermore on the aspect of casual editors being able to edit the templates. My personal policy (which I would be happy to make formal) is as such:

1. If the template is in Meta templates  - it is fully protected.
2. If the template is more than two edit windows long (using the system default (25px), which I have set my personal to 50px) - it is fully protected.
3. If the template uses more than two extensions, or uses the loops extension - it is fully protected.
4. ALL other templates - semi-protected.

This means that "most" people wouldn't have access to edit the templates anyways, as I feel they shouldn't. Templates cascade across many pages and could easily be manipulated to cause undesired results. Say, for example, an intrusive bot was to come to our wiki. It could very easily find the most used templates and replace them with an advertisement or even worse an endless loop or a broken parser hook causing the whole wiki to go down. It is for reasons like this that all used templates should have at least "some" level of protection and not be able to be edited by those who have not demonstrated good intent for the wiki.

ShoeMaker (Contributions • Message) 10:11, March 7, 2013 (EST)

This is so strange, I feel like I'm taking crazy pills. I just dont see how anyone can take the position that {{Greater Humanoid Bane}} is more difficult on an end user than {{Bane|Humanoid|greater}}. Especially when "Greater Humanoid Bane" matches exactly the item property.

To say that casuals dont edit templates I believe furthers my point, and I suspect the reason is that casuals are intimidated by the existing templates. Deciphering a hundred lines of nested tags, if statements and switches is not my idea of what the every day editor would be interested in doing. On the other hand, if creating a template were as simple as copying an existing template, and changing "Acid" to "Cold", I think a lot more casuals would be editing templates.

Concerning server load, almost as if it was fate, an editor ran in to a resource limit problem just today trying to add content to a page. A solution of modifying a template to reduce logic, and increasing the limits allowed on the server was implemented, but I think that's about as clear as an example of too much logic in templates as you can get. Also, when refactoring a template, and using stored variables to cut down on duplication and make the template more readable, it was explained to me that using stored variables put an extra load on the wiki core. If the server is sensitive to storing a couple of variables in a template, than it is certainly going to be sensitive to a switch statement with over a hundred checks.

I also take the position that the natural progression of making templates more complex is fewer people will want to work on them. Dismissing that factor because it's not your concern I think is a bit unfair.

Shoe, I understand the concern that protections are required for templates because of the volume of pages that rely on templates. I would like to make my position more clear. *ONLY AS IT PERTAINS TO ITEM PROPERTY TEMPLATES* I think protections are warranted. If we have 1000 item pages that hit one template and that template gets split in to a hundred templates, now we have 10 item pages that hit 100 templates, the volume of pages affected by the item property template goes from 1000 to 10, using rough numbers. In that scenario I would propose dropping security from fully protected templates to semi protected.

Joenuts (Contributions • Message) 21:28, March 8, 2013 (EST)

My big problem with the templates is that they aren't logical and I can't find detailed usage instructions for some of them. If we get a logical system and stick with it I'm fine with big templates but the list I found with instructions doesn't even have everything working. Talk:List_of_templates or its successor needs to be to be more visible and be updated for every change in how the templates work. The damage template is a huge offender here with an invisible system beyond the basics and some of those don't work.

Book O Dragons (Contributions • Message) 16:09, December 1, 2014 (EST)

Four years later...

I find this thread fascinating. So how did this story end up? Did the heroic Joe move mountains? I popped a whole pan of popcorn for this read =). I think my first try to be a wiki editor was during this phase, and I was all, like... "heck no. That is one bowl of noodles I haven't got time for." Fate, or at least Mogafi, has brought this back up on the queue, and I want to know where this went. ⇒ meander (Contribs • Message • Email) 20:39, September 10, 2018 (EDT)

• I think this ended up without a conclusion. Though it seems Shoemaker is now also in favor of many small templates. My opinion is that dissecting big templates into small templates smells like work. However, I have this brilliant idea that we create redirect templates (for now), for example a new {{Blindness Immunity}} would not have the full code, instead it would link to existing {{Immunity|Blindness}}. For example, I was unhappy how inconsistent were the templates for T:Spell Focus, T:Spelllore, T:SpellPower. Note how the spelling is different for each. I have created new T:Spell Lore that internally points to Spelllore and T:Spell Power that points to SpellPower. Existing users who know the old templates can still use old names. New users that don't know exact template names have now more chances to guess the correct name. So this kinda looks ideal. Not sure how server load feels about it though. ⇒ Cru121 (Contribs • Message • Email) 05:29, September 11, 2018 (EDT)