Template talk:Trait table
DPL table[edit]
My one and only qualm with dpl, which this template uses, is that is screws up with reference tags, and currently the wiki uses those things a lot. Konig/talk 02:53, 22 February 2012 (UTC)
- With the new traits system, we can just not include references tags in any new trait descriptions. My quick check of the traits returned no problems with the newer traits, some of the older traits are annoying, but I'll fix those soon and until then they won't cause an issue. Aqua (T|C) 03:14, 22 February 2012 (UTC)
- As much as I like DPL, I doubt it's going to work here. We shouldn't accept a DPL table that is anything less than what we already have. One of the main advantages of DPL is that it would prevent us from having the trouble of creating those tables, but now that's a non-issue since the tables are done anyway. The main advantage of DPL now would be to leave us with less work in maintaning the tables, once a trait is changed. But giving us less work is no excuse to change from a more informative format to a less informative one. And based on what (little) I know of DPL, it's not possible to make trait tables as good as the ones we have right now. Sorting traits per line or per type would not be enough - traits follow a specific pattern and a specific distribution that is of great importance and that should be represented in the trait tables. Erasculio 13:16, 22 February 2012 (UTC)
- It'll take a little work, but it is possible to get a closer table to what is there. However, there's something about the current table that feels off. Maybe it's the headers blending into the left columns, or the left columns just looking big and awkward. I was hoping to avoid that with a dynamic table. --JonTheMon 14:09, 22 February 2012 (UTC)
- Also, as a sort of aside, would this be better off on individual trait line pages instead of profession trait line pages? --JonTheMon 14:10, 22 February 2012 (UTC)
- This table is great, but I think that type sorting order is wrong. It can be corrected with a template that adds an invisible (with a span tag that has style="display:none;") sorting dummy before the type name, e.g. 1 for adept, 2 for master, 3 for grandmaster and 4 for major. That would make them sort in an appropriate order. I also think that making a trait line column hideable will help a lot, as this template would be used on individual trait line pages a lot, where this information is redundant. (Tried to do that myself, but it's harder than I thought.) Alfa-R 17:11, 22 February 2012 (UTC)
- What I had tried to mention on Talk:List_of_mesmer_traits, is it possible to have more than 1 dpl table on a page. Easy way to organize it would be to split up each line under its own header so that there is 5 tables under the 5 trait line headers like how they are individually on each lines own page (ex. Dueling). If you can do that then sort by Type it would look neat and be done.
- And Jon, it looks great on the individual trait line pages and a lot better than how the paged looked before. Could look good on the profession trait line pages too with a little tweaking imo. Mattsta 23:06, 22 February 2012 (UTC)
- Oh, and if it can be sorted by Type on the individual trait line pages too. That's the only criticism I have for the individual pages. Mattsta 23:08, 22 February 2012 (UTC)
- Currently in my sandbox, I'm demonstrating an early version of how I would go about a dpl version of the table. To get the minor and major traits separate, we would need to tweak the main Trait infobox template. --JonTheMon 23:48, 22 February 2012 (UTC)
- This table is great, but I think that type sorting order is wrong. It can be corrected with a template that adds an invisible (with a span tag that has style="display:none;") sorting dummy before the type name, e.g. 1 for adept, 2 for master, 3 for grandmaster and 4 for major. That would make them sort in an appropriate order. I also think that making a trait line column hideable will help a lot, as this template would be used on individual trait line pages a lot, where this information is redundant. (Tried to do that myself, but it's harder than I thought.) Alfa-R 17:11, 22 February 2012 (UTC)
- As much as I like DPL, I doubt it's going to work here. We shouldn't accept a DPL table that is anything less than what we already have. One of the main advantages of DPL is that it would prevent us from having the trouble of creating those tables, but now that's a non-issue since the tables are done anyway. The main advantage of DPL now would be to leave us with less work in maintaning the tables, once a trait is changed. But giving us less work is no excuse to change from a more informative format to a less informative one. And based on what (little) I know of DPL, it's not possible to make trait tables as good as the ones we have right now. Sorting traits per line or per type would not be enough - traits follow a specific pattern and a specific distribution that is of great importance and that should be represented in the trait tables. Erasculio 13:16, 22 February 2012 (UTC)
- From the standpoint of a sortable list, I think DPL serves very little purpose. The only variables of a trait are its profession, line, type, name, and description. The trait lists are already grouped by profession in their pages (e.g. List of mesmer traits), the trait lines are clearly shown on the left-hand side and are easy to look through, and there is a specific number of minor traits, leaving the only real "dynamic" content to be all of the major traits and their descriptions. Descriptions aren't very useful for sorting, leaving only trait names to be sorted by, which may as well be hardcoded.
- The only usefulness I can see from using DPL is for dynamically retrieving trait descriptions. That way, you could simply keep a template with a list of trait names, which is much easier to manage than the corresponding slough of changing and updating descriptions. —Proton 02:31, 23 February 2012 (UTC)
- Honestly, looking at your change to List of warrior traits, that doesn't seem that useful. It doesn't make it any easier for a novice editor to change, it's highly static, and it doesn't dynamically update based on changes to the traits themselves. --JonTheMon 02:39, 23 February 2012 (UTC)
- Hello, I'm new. From my point of view, it doesn't seem necessary to duplicate trait names and descriptions (list + individual trait pages). If an individual trait is updated, the list should update automatically. Granted, those thing probably won't change (much) once it's all finalised, but why duplicate effort and information if it can be avoided? Eerie Moss 17:50, 23 February 2012 (UTC)
- I'm not sure if it's possible for the DPL to load in the description, in a template, if say, we set up the trait page to use a [[TraitTemplate|name=traitname|desc=Signets Recharge Faster]] or something, then load it into the main trait page... it would be wonderful if we could, though at this point, undoing and simplifying may actually take MORE effort, since so many traits are already done ~~ Kiomadoushi 19:54, 23 February 2012 (UTC)
- Well, the goal of DPL is to take information from each individual trait page and collect them into lists like in my sandbox which takes the information from the infobox on each page and orders it a bit. --JonTheMon 19:59, 23 February 2012 (UTC)
- Jon, new table looks nice. Mattsta 20:03, 23 February 2012 (UTC)
- Well, the goal of DPL is to take information from each individual trait page and collect them into lists like in my sandbox which takes the information from the infobox on each page and orders it a bit. --JonTheMon 19:59, 23 February 2012 (UTC)
- I'm not sure if it's possible for the DPL to load in the description, in a template, if say, we set up the trait page to use a [[TraitTemplate|name=traitname|desc=Signets Recharge Faster]] or something, then load it into the main trait page... it would be wonderful if we could, though at this point, undoing and simplifying may actually take MORE effort, since so many traits are already done ~~ Kiomadoushi 19:54, 23 February 2012 (UTC)
- Hello, I'm new. From my point of view, it doesn't seem necessary to duplicate trait names and descriptions (list + individual trait pages). If an individual trait is updated, the list should update automatically. Granted, those thing probably won't change (much) once it's all finalised, but why duplicate effort and information if it can be avoided? Eerie Moss 17:50, 23 February 2012 (UTC)
- Honestly, looking at your change to List of warrior traits, that doesn't seem that useful. It doesn't make it any easier for a novice editor to change, it's highly static, and it doesn't dynamically update based on changes to the traits themselves. --JonTheMon 02:39, 23 February 2012 (UTC)
(Reset indent) I am completely okay with Jon's current table if its style is modified to have width:800px;font-size:90%
. —Proton 22:46, 23 February 2012 (UTC)
- Why would you want fixed width and smaller font? --JonTheMon 22:47, 23 February 2012 (UTC)
- Because all the cool cats design their websites for a width of 1024 pixels, and MediaWiki takes up 174 pixels with its sidebar, leaving 850 pixels, and some must be removed from that to account for a scrollbar, leaving a nice even 800 pixels for "full-width" objects. The smaller font is to accommodate the relatively-smaller width and minimize linebreaks.
- Although to be honest both of those preferences on my part were simply because the original trait list tables intended for it; the reason they don't already look that way is because they typo "font-size" to "fong-size", and the "max-width:800px" statement doesn't work when "width" is set to a relative value (in this case, 100%). —Proton 04:32, 24 February 2012 (UTC)
- As with the main page editcopy discussion, we need to account for larger than 1024 wide. Trying to avoid straining eyesight is also a good goal as well. So, I don't see a need to apply those to this template, especially since it's so information dense. --JonTheMon 04:35, 24 February 2012 (UTC)
- Also having 1600 pixels of width makes the lefthand headers immensely fat, which is not very aesthetically pleasing given their dark(er) background color.
- As a completely subjective opinion, I personally find raw 100%-width stuff to appear unprofessional and tacky. Could a different fixed size be agreed upon? Perhaps 1050 or 1200 (based on 1280-pixel and 1440-pixel widths respectively). —Proton 04:52, 24 February 2012 (UTC)
- EDIT: Better idea:
min-width:800px;max-width:1200px
gogogogo. —Proton 04:59, 24 February 2012 (UTC)- Giving the first few columns some set widths wouldn't be horrid, nor would a min and max width for the entire table. I still think you're going to have some problems with it being 100%. I'll look at that sometime tomorrow. --JonTheMon 05:03, 24 February 2012 (UTC)
- Ok, i've made some tweaks to my new template. Any thoughts or should we think about pushing it soon? --JonTheMon 20:55, 24 February 2012 (UTC)
- Looks great to me. Only thing that needs to be done is to make a capitalization crusade on all of the adept/master/grandmaster values in the traits. We could technically just put in a text replacement thingy but that would be hacky and therefore lame. —Proton 03:39, 25 February 2012 (UTC)
- Done. Eerie Moss 09:15, 25 February 2012 (UTC)
- Any last suggestions for improvement / objections? --JonTheMon 15:43, 25 February 2012 (UTC)
- None from me, looks great. Eerie Moss 16:00, 25 February 2012 (UTC)
- Any last suggestions for improvement / objections? --JonTheMon 15:43, 25 February 2012 (UTC)
- Done. Eerie Moss 09:15, 25 February 2012 (UTC)
- Looks great to me. Only thing that needs to be done is to make a capitalization crusade on all of the adept/master/grandmaster values in the traits. We could technically just put in a text replacement thingy but that would be hacky and therefore lame. —Proton 03:39, 25 February 2012 (UTC)
- Ok, i've made some tweaks to my new template. Any thoughts or should we think about pushing it soon? --JonTheMon 20:55, 24 February 2012 (UTC)
- Giving the first few columns some set widths wouldn't be horrid, nor would a min and max width for the entire table. I still think you're going to have some problems with it being 100%. I'll look at that sometime tomorrow. --JonTheMon 05:03, 24 February 2012 (UTC)
- As with the main page editcopy discussion, we need to account for larger than 1024 wide. Trying to avoid straining eyesight is also a good goal as well. So, I don't see a need to apply those to this template, especially since it's so information dense. --JonTheMon 04:35, 24 February 2012 (UTC)
(Reset indent) I'm trying to work with some browser dumbness (Chrome in particular), but such fixes are not critical and I can easily make them later while I experiment in my sandbox now. In the meantime I see no reason that the template can't be implemented now. —Proton 16:11, 25 February 2012 (UTC)
Update: Actually, Jon, if you could modify the DPL instructions to get trait names from the "name" part of the template if it's there; that way we won't get stuff like "Lung Capacity (ranger)" in the table.
- Fine. Picky, picky. --JonTheMon 17:50, 25 February 2012 (UTC)
- ♥ —Proton 04:17, 26 February 2012 (UTC)
Center align and table design[edit]
Two things (as stated);
- I don't think the center aligned text is complementary towards this template from any perspective and thus propose left-align or a more consistent alignment in general.
- The design of this table (and mostly every other table on this wiki) should be revamped (like the infoboxes and the navigation boxes are/have been). This has no direct relevance to the current revision of this template but should be noted all the same.
That is all. - Infinite - talk 15:41, 23 February 2012 (UTC)
overly organized disorganization[edit]
do we REALLY need the trait line box there?... So far as i've seen, it's only used with one trait line at a time (as multiple trait lines become disorganized when it displays alphabetical) So then everything becomes a mess very quickly... This needs some serious cleanup, and I don't know how to play with the DPL... ~~ Kiomadoushi 20:03, 23 February 2012 (UTC)
- Er, what example are you looking at? --JonTheMon 20:04, 23 February 2012 (UTC)
- Look at any of the trait pages (i've just been copying the format over), and try using it with the category=*Profession traits and it makes it turn into a colorful DPL list, nothing like the organize table that is set up by hand... do YOU have an example where using multiple trait lines makes sense, and is smarter than, say, organizing it out multiple templates at a time? (like template category A, template category B, etc) ~~ Kiomadoushi 20:18, 23 February 2012 (UTC)
- Oh, right, take a look a the first ele table on User:JonTheMon/sandbox --JonTheMon 20:21, 23 February 2012 (UTC)
- See, now that would work, but what about the redundancy on a single trait page? to show every trait as, say, Shadow Arts, on the Shadow Arts trait page... It just looks gaudy. ~~ Kiomadoushi 20:31, 23 February 2012 (UTC)
- Uh, under "Fire magic traits (without trait line)" there are only 3 columns: type, name, description. It doesn't give the trait line in that table at all. --JonTheMon 20:33, 23 February 2012 (UTC)
- So then that would apply to Shadow Arts then to leave out the lockpick key Thief icon, and not have to say Shadow Arts with each one of them... ((Also, do you know why the Warrior trait pages are now saying unspecified for the trait family? the very same gaudy one that we're talking about?)) ~~ Kiomadoushi 20:36, 23 February 2012 (UTC)
- Uh, under "Fire magic traits (without trait line)" there are only 3 columns: type, name, description. It doesn't give the trait line in that table at all. --JonTheMon 20:33, 23 February 2012 (UTC)
- See, now that would work, but what about the redundancy on a single trait page? to show every trait as, say, Shadow Arts, on the Shadow Arts trait page... It just looks gaudy. ~~ Kiomadoushi 20:31, 23 February 2012 (UTC)
- Oh, right, take a look a the first ele table on User:JonTheMon/sandbox --JonTheMon 20:21, 23 February 2012 (UTC)
- Look at any of the trait pages (i've just been copying the format over), and try using it with the category=*Profession traits and it makes it turn into a colorful DPL list, nothing like the organize table that is set up by hand... do YOU have an example where using multiple trait lines makes sense, and is smarter than, say, organizing it out multiple templates at a time? (like template category A, template category B, etc) ~~ Kiomadoushi 20:18, 23 February 2012 (UTC)
This Template is Junk[edit]
This template is incomprehensible and prevents editors from modifying anything. There's been a duplicate trait listed on the Mesmer Duelist line for about a week now because no one seems to be able to figure out how the heck to edit this thing.Strill 05:11, 9 March 2012 (UTC)
- The duplicate was due to there being a duplicate page (in actuality, it was the difference between duAlist and duElist). The template is only as good as the pages, but that's still better than having to make sure both the lists and the pages are correct. --JonTheMon 06:01, 9 March 2012 (UTC)
Sort[edit]
I think sorting by Tier (Adept, Master, Grand Master) is more important than sorting by name. Perhaps had sortability to those table headers? llandale 13:11, 14 June 2012 (UTC)
- That's something we're working on. —Dr Ishmael 15:16, 14 June 2012 (UTC)
2017[edit]
Can we have traits in the same order as presented in the game? i.e. by its position property, not name. Shena'Fu (talk) 12:36, 19 March 2017 (UTC)
- Done. -Chieftain Alex 13:24, 19 March 2017 (UTC)
specializations update[edit]
I've updated this template at User:Dr ishmael/Trait table to work with the new, numeral-less trait system. Instead of putting all minors at the top of the table, I moved them to be at the top of each tier, which better reflects the actual progression anyway. I'm willing to take suggestions on improving this new design, which can't really be implement until we've got all the traits sorted out. —Dr Ishmael 21:25, 23 June 2015 (UTC)
- Elementalist traits are all good now, no thanks to you not setting type/tier correctly. :P —Dr Ishmael 13:38, 24 June 2015 (UTC)
Should the minor traits have border on both top and bottom? I can't decide. —Dr Ishmael 16:03, 24 June 2015 (UTC)
- Both and make the top bar thicker than the bottom? Show the split between tiers and that the minor trait has a prominent position the section.--Relyk ~ talk < 16:26, 24 June 2015 (UTC)
- Just same width at the top and bottom of the minor trait imo. -Chieftain Alex 18:19, 24 June 2015 (UTC)