18 replies to this topic

[Talkerst]

Currently there is a lot of repeated information between the D3_Skills information and the Skill_Description information.  It seems like a headache to maintain both as can be seen by the fact that currently the D3_Skills has different info than the Skill_Descriptions.  So I came up with a pretty simple solution.  I've create a new D3_Skills_Overview template (D3_Skills_Description was already taken) that uses the same parameter names as D3_Skills.  By doing this and changing Data:Spells/<spell name> into a very simple template you only have to enter the data in one place.  I've created samples at Data:Spells/Impale_Test, Impale_Test and Impale_Test_Overview.

I'd like to put this system in place to ease the burden of data entry in the future.  However, it is a somewhat major shift so I didn't want to just put it in and have people object then have to roll it back out.  There are a couple issues with my samples which I'll address below.  If the sysops think this is a good idea I'll get to work on updating the files as soon as I can.

Issues:
* This would require changing Data:Skills/<skill name> to a template.  Currently all templates , that I've seen, are in the Templates namespace.  Not sure how big of a deal it is to add very simple template functionality to an existing page but not place it in the templates namespace.  I'm open to suggestions on this one but would prefer not to have to create template pages for each skill and a data page when the templating is so trivial.

* The icon on the Impale_Test test page doesn't show because the name is based on the page name and not the spell_name_en and I didn't bother to create a new Imaple_Test.png.  This won't be an issue with the final version.

* The overview has redundant information about level on it because the D3_Skills template lacks a level parameter.  That's an easy fix that I'll implement if I move this to live.

* I'm not sure how the skills pages are being updated.  If it's via a script the script will probably need to be modified but the changes are trivial (see Data:Spells/Impale_Test).

If anyone sees any other issue let me know and I'll address them.

[PhrozenDragon]

Talkerst, on 05 October 2011 - 04:21 PM, said:

Currently there is a lot of repeated information between the D3_Skills information and the Skill_Description information.  It seems like a headache to maintain both as can be seen by the fact that currently the D3_Skills has different info than the Skill_Descriptions.  So I came up with a pretty simple solution.  I've create a new D3_Skills_Overview template (D3_Skills_Description was already taken) that uses the same parameter names as D3_Skills.  By doing this and changing Data:Spells/<spell name> into a very simple template you only have to enter the data in one place.  I've created samples at Data:Spells/Impale_Test, Impale_Test and Impale_Test_Overview.

This seems to a be a system almost identical to the one currently employed for items, and it's a good idea I think. Data is stored in the Data: namespace in the form of a template, and depending on which functionality the article requires different formats can be used.

Example:
Azurewrath
Sword List

Both those pages pull data from the same page, namely Data:Items/Azurewrath, but they use different template to achieve it.

The item design uses the following templates:
Template:Item (must be used if anything but the default design is needed)
Data:Items/X
Template:Item Display (decides which layout is actually going to be used)
Template:Infobox Item (the default infobox)
Template:Item List (the list template seen on the sword list page above)

Talkerst, on 05 October 2011 - 04:21 PM, said:

I'd like to put this system in place to ease the burden of data entry in the future.  However, it is a somewhat major shift so I didn't want to just put it in and have people object then have to roll it back out.  There are a couple issues with my samples which I'll address below.  If the sysops think this is a good idea I'll get to work on updating the files as soon as I can.

Implementing this change will require a lot of manual edits. Once the design is complete we can get ApocBot to do the mundane copy&paste work required on all the data pages.

Talkerst, on 05 October 2011 - 04:21 PM, said:

* This would require changing Data:Skills/<skill name> to a template.  Currently all templates , that I've seen, are in the Templates namespace.  Not sure how big of a deal it is to add very simple template functionality to an existing page but not place it in the templates namespace.

All data pages work like templates, in fact the namespace shows up under the template list when you edit a page same as proper templates. And if the item layout above is mimicked then the Item template (preferably called Template:Skill in this case) will serve as a template for all skills.

Talkerst, on 05 October 2011 - 04:21 PM, said:

* I'm not sure how the skills pages are being updated.  If it's via a script the script will probably need to be modified but the changes are trivial (see Data:Spells/Impale_Test).

It was done by script once, and it may be done again. But for the most part it will be manual.

Also a quick note, the wiki makes no distinction between empty spaces and "_", so you don't have to include underscores most of the time.

[Apoc]

Definitely good practice to reduce redundancy by keeping it to a single source. Couple things I'm noticing as I post this (ya'll are having a nice revert war over there..):

- the level in the description should be removed if we're putting it in the title - it's redundant
- the <noinclude>{{Data:Spells/Monk_Skills}}</noinclude> should be pulled in on the main namespace page, otherwise we set ourselves up for some ugly chain transclusion situations

[Talkerst]

The level in the description was a chicken and the egg issue.  I added the level information in, then adjusted the template.  So I left the info in the description until the template change was complete.  Now that it's done I've gone back and removed it from the description.  I know it's a lot of steps but I didn't want their to be a period of time when no level information was available.

As for <noinclude>{{Data:Spells/Monk_Skills}}</noinclude> I was going to just remove it based on a couple people requesting that.

You can see how the system works by checking out the Demon Hunter page.  You'll see some extra info that wasn't there before due to it being in the skills description.  I think that info should be changed to parameters so it doesn't have to show up there unless we want it to.  That's probably the next thing I'm going to tackle.  Was planning on adding parameters for cost, subcategory and extra info (stuff that shouldn't be in a brief description).  This will require me to touch all the skills yet again so if anyone would like to see something else changed to a parameter let me know so I can get them all at the same time.

Edit: Also, does anyone know why almost all of the string parameters in the skills start with a BR?  It seems to have no effect on their display in the tables but does mess up formatting if they are displayed else where.  Had the one from spell_desc_en on all the skills so that the descriptions would display nice on the classes home page.  Seems like they add nothing but make re-using the data harder.

Edited by Talkerst, 06 October 2011 - 05:23 PM.

[PhrozenDragon]

Talkerst, on 06 October 2011 - 05:06 PM, said:

Edit: Also, does anyone know why almost all of the string parameters in the skills start with a BR?  It seems to have no effect on their display in the tables but does mess up formatting if they are displayed else where.  Had the one from spell_desc_en on all the skills so that the descriptions would display nice on the classes home page.  Seems like they add nothing but make re-using the data harder.

No I have no idea. Could you show me where and how the formatting gets messed up?

[Zhuge]

pretty sure those <br>s are from when we imported the parsed pages about 2-3 weeks ago.

[Talkerst]

PhrozenDragon, on 06 October 2011 - 05:44 PM, said:

No I have no idea. Could you show me where and how the formatting gets messed up?

I added one back into Spike Trap though the new template doesn't like it as well as the old one did.  However, you can see what it was doing to the overview formatting at Demon_Hunter/Skill_List.  If that doesn't make sense let me know and I'll try to explain better.

In addition, I've finished the updates to the D3 Skill template though I am smarter now so if you aren't using the new parameters you won't see anything.  That way the skills can be updated at leisure without looking ugly.  The new parameters are:

• spell_cost - Used to store the cost of a skill
  
• spell_generate - Used to store how much resource a skill generates (can't be used with cost)
  
• spell_resource_type_en - String for the resource type (I.E. Hatred, Fury, etc.)
  
• spell_subcategory_en - Skill subcategory (I.E. Offense, Discipline, etc.)
  
• spell_extra_info_en - This is where any base skill descriptive text that is not part of the simple skill description should go.  Things that would go in here would be like if a Wizard spell is a signature skill.  It's info you don't want showing up on the skill's overview on the class's home page.

I've updated the the Demon Hunter and Barbarian skills so you can see what the finished product looks like.  I'll work on the others as time permits.

Edited by Talkerst, 06 October 2011 - 10:05 PM.

[PhrozenDragon]

Talkerst, on 06 October 2011 - 06:58 PM, said:

I added one back into Spike Trap though the new template doesn't like it as well as the old one did.  However, you can see what it was doing to the overview formatting at Demon_Hunter/Skill_List.  If that doesn't make sense let me know and I'll try to explain better.

I see there's a <br /> in front of the description that bumps down the text, that's what you mean right? If so, then that's just part of the information in the data namespace and it will be easy to remove. Apoc has a bot that can go through all of the spell pages and remove that piece.

[Talkerst]

PhrozenDragon, on 06 October 2011 - 10:16 PM, said:

I see there's a <br /> in front of the description that bumps down the text, that's what you mean right? If so, then that's just part of the information in the data namespace and it will be easy to remove. Apoc has a bot that can go through all of the spell pages and remove that piece.

Yeah, that is what I was referring to.  Since I was touching all the files anyway I've removed them from all the descriptions.  Though if we ever wanted to use the rune descriptions for something other than in a table it would present a problem with them.  Glad to hear it can be done via bot.

[Talkerst]

I've finished up the template change to all the classes and reworked every skill to use it.  Should make updates more streamlined and cleans up the skill descriptions quite a bit.

I've noticed that the nav boxes are not consistent between classes.  Some are listed in order of level attained while others are in alphabetical order.  I was going to change them all to alpha because that just makes more sense.  However, this makes it harder to 'walk' the skill list in order.  To compensate I was planning on adding previous and next links to the skills template.  Thus you would be able to easily step through the full descriptions in order or jump to a particular skill via the nav box.  I should have an example up soon but if this doesn't seem like a worthwhile effort let me know.

Edit: Here is an example of how it could look, User:Talkerst/Bola Shot.  The links and names are all pulled from a list so it's easy to adjust their look, feel and location via the D3 Skill template.

Edited by Talkerst, 10 October 2011 - 05:53 PM.

[PhrozenDragon]

Talkerst, on 10 October 2011 - 05:19 PM, said:

I've noticed that the nav boxes are not consistent between classes. Some are listed in order of level attained while others are in alphabetical order.  I was going to change them all to alpha because that just makes more sense.

Navboxes are rarely isted in alphabetical order unless there's no other criteria to list by. Template:D2 NPCs is a good example of a navbox where there's no other parameter by which to list them other than names.

In other cases, such as item, areas and skills, pages are usually listed in order of appearance. For items that's item level/required level, areas it's order of appearance, skills level requirement. This provides access to the pages in the same order they appear in-game, which will be a familiar order regardless of what information one is looking for. But it also provides additional information to the viewer.

If you are for instance looking up an item to use, listing item links in order of level will indicate to the viewer that those items near the page they're on might also be good candidates. Similarly this is true for acts and, traditionally, skills.

However since all skills are supposedly good at lvl 60, or intended to be, the prime reason to sort them by minimum level seems diminished. Perhaps in the case of skills it is less important to sort by level.

[Talkerst]

I've wavered back and forth on what I personally feel is the correct order for skill nav boxes.  I can see it going either way and really it doesn't make a big difference to me.  I just think they should all be the same.  Since they aren't now, if a consensus on how we'd like them can be reached I'll do any necessary updates.

Also, I edited in the link to my example previous/next template addition idea.

[Apoc]

Personally I prefer alpha since the navbox is intended as an index (provides a quick way to jump to another skill), and if its not sorted I have to look around a bit to find what I want. In addition the skills are already listed by order on the class/Skill_List pages.

Edited by Apoc, 10 October 2011 - 06:06 PM.

[Talkerst]

Apoc, on 10 October 2011 - 06:06 PM, said:

Personally I prefer alpha since the navbox is intended as an index (provides a quick way to jump to another skill), and if its not sorted I have to look around a bit to find what I want. In addition the skills are already listed by order on the class/Skill_List pages.

Any thoughts on wither it would be useful to have previous and next skill links on each skill's page?

[Talkerst]

I've started on a new phase of redundancy removal.  Right now there are several places where skills are referenced and there is a potential for even more.  I'm creating a mapping that can be used to navigate through the skill references by both level (forwards and backwards) and via alpha (forwards only).  I've already completed the mapping for the Demon Hunter and am using it for the active skills page.  I'll be updating the nav box and passive skills tomorrow.  This system creates a one stop location for all skill references (by class).  By keeping the one file up to date all skill lists will stay up to date.  If a new skill is added or one is removed updating the mapping will properly updated all references.  At least that's the goal.  Something unforeseen could come up but as of now it will work for everything we have in place as well as adding previous and next skill links to the detailed pages.

[PhrozenDragon]

What exactly is the purpose of http://www.diablowiki.com/Template:Demon_Hunter_Skill_Mapping? As I understand it, this is intended to allow for easy updating of all pages which use any skill data pages in the wiki, so that when a new skill is added, all pages will also be updated?

It seems like a rather complicated solution given the low chance that we'll see massive skill changes. If a skill is indeed updated or removed, it won't take that much effort to add it to the handful of pages where it's data page is intended to be used.

[Talkerst]

PhrozenDragon, on 10 October 2011 - 11:49 PM, said:

What exactly is the purpose of http://www.diablowiki.com/Template:Demon_Hunter_Skill_Mapping? As I understand it, this is intended to allow for easy updating of all pages which use any skill data pages in the wiki, so that when a new skill is added, all pages will also be updated?

It seems like a rather complicated solution given the low chance that we'll see massive skill changes. If a skill is indeed updated or removed, it won't take that much effort to add it to the handful of pages where it's data page is intended to be used.

It was a process that seems to have taken on a life of its own.  I wanted an easy way to navigate between pages (prev/next) and once I got that figured out I realized it could be extended to include all references.  By reference I mean places where the class data is linked to and possibly partially displayed.  However, due to wiki's limited capabilities it wound out turning into a rather complicated science experiment.  I think the idea was good but I let the implementation get out of hand (complexity wise).  I'll back it out.  Though it does bring up a fundamental question.

It might just be the programmer in me but I view the majority of the work being done now as data driven.  With a large data based project I'd normally want to store all the data in one place and then use various algorithms and transformations to display it as desired.  As I learn more about extensions (see my while example at User:Talkerst\Sandbox2) I realize this is probably a realizable goal even using wiki.  However, what I'm not sure of is if it's something that's desired.  For me, I'd rather enter data in one table like place and have a script (even a complicated one) do all the formatting work.  That also helps maintain consistency.  The flip-side is, if you see something wrong with a generated page you have to know where to go to correct it.  While comments can easily point people to the write location the disassociated nature of data and content might turn off the casual wiki editor.  Thoughts?  Any preexisting methodology that is employed here?

[PhrozenDragon]

Talkerst, on 11 October 2011 - 08:31 PM, said:

However, what I'm not sure of is if it's something that's desired.  For me, I'd rather enter data in one table like place and have a script (even a complicated one) do all the formatting work.  That also helps maintain consistency.  The flip-side is, if you see something wrong with a generated page you have to know where to go to correct it.  While comments can easily point people to the write location the disassociated nature of data and content might turn off the casual wiki editor.  Thoughts?  Any preexisting methodology that is employed here?

It is a tough question to be sure.

I can't say we have a clearly defined concept of how to handle this, since most of our templates are quite simple in nature: I do think the most important point is to make sure that all handling of data be kept very simple. I'll try to explain that better.

I'll refer to the way items are currently handled. Right now a user can easily edit the data of an item by clicking the arrow in the infobox, which takes them to the data page of said item. While there editing the actual stats is just about as simple as wiki-editing can be made. Conversely, adding new items to pages or removing them, whether as infoboxes and lists is also very easy.

The complexity of these templates that handle items are all constrained to the actual formatting of the information. If a specific data field displays incorrectly it might be hard to fix, but if the data is simply incorrect it's rather easy.

That I feel is an important aspect to always keep in mind.

Talkerst, on 11 October 2011 - 08:31 PM, said:

(see my while example at User:Talkerst\Sandbox2)

A good idea is to always use permanent links to sandboxes, since they tend to change a lot. That way it's easier for people to figure out what you actually wanted to link to Permanent links are found under "Toolbox" in the left navbar.

[Talkerst]

PhrozenDragon, on 13 October 2011 - 08:58 PM, said:

A good idea is to always use permanent links to sandboxes, since they tend to change a lot. That way it's easier for people to figure out what you actually wanted to link to Permanent links are found under "Toolbox" in the left navbar.

As usual, thanks for all the great info.  Wasn't aware of how permanent links work but that's pretty nifty.  Here is the link to the example I was talking about While Example. Though my new sanbox2 uses a while template too.  I think Wynthyst has about gotten me straightened out with the complexity issue.

Edited by Talkerst, 14 October 2011 - 04:09 AM.