Template talk:Skill progression

This table looks really strange centered, when all the content we have is either right or left aligned. Can we have this left aligned? It makes it easier to read under the skill description and looks a lot less awkward. - B e X o R  23:59, 1 April 2007 (EDT)
 * Bexor - you're pretty much the wiki style guru. If you think it looks better then you should go for it, you're probably right. :D I was just copying from what was around before. --Aspectacle 00:31, 2 April 2007 (EDT)
 * Well I'll change it and when everyone has a cry they can do so here. - B e X o R  00:37, 2 April 2007 (EDT)
 * *cry* - Anja Astor  02:06, 2 April 2007 (EDT)


 * Oh no! It takes a bit of getting used to - it makes the page look very left handed if you've got a big monitor. --Aspectacle 02:08, 2 April 2007 (EDT)
 * Yea, on my screen (in my eyes maybe) it looks really odd. Before it was a nice balance with the right aligned skill box. - Anja Astor  02:10, 2 April 2007 (EDT)


 * I think it looks good to the left. LordBiro 06:09, 2 April 2007 (EDT)
 * Anyone thinks it should at least have a little cell padding? -- ab.er. rant [[Image:User Ab.er.rant Sig.png|sig]] 05:02, 4 April 2007 (EDT)


 * Not personally. LordBiro 05:04, 4 April 2007 (EDT)


 * It already does have cellpadding. Any more and it will look bloated. - B e X o R  06:08, 4 April 2007 (EDT)

Maximum
I've created Skill progression limit which determines what the length of the row should be based on the attribute. At the moment it is only used if maximum is not specified. Since I was unsure whether the attribute parameter would be a link or not, I have switched based on the unlinked attribute.

I don't really think the attribute should be linked, since the attribute will already be linked in the skill infobox, but I have brought this up at Guild Wars Wiki talk:Formatting/Skills. LordBiro 06:35, 5 April 2007 (EDT)


 * You might want to remove the changed parameters from usage too. - B e X o R  00:14, 6 April 2007 (EDT)


 * Ok! LordBiro 07:02, 6 April 2007 (EDT)

Micro-font part II
As per the discussion I was mistakenly having at User talk:LordBiro/Skill box draft 5, why are we using such a small font for the progression table? The old tables at GW make much better use of available space - I'm not suggesting we copy them, but I don't understand how presenting the numbers with such a small typeface improves things. --NieA7 10:49, 5 April 2007 (EDT)
 * Repetitive data doesn't need to be in full font size (i.e. things that you've read once and don't need to again, like headings or such), but seeing as the progression table data is unique to each page, I can see why the full font size would be required. - B e X o R  11:30, 5 April 2007 (EDT)
 * I'm in favor of a full size too. It's hard to read even for me with perfect sight. (when wearing my glasses ;) ) -- [[Image:User Gem sig.png|Gem]] (gem / talk) 11:33, 5 April 2007 (EDT)
 * I just got new glasses! 90% has always been easy for me to read though, as long as I have them on. I can see about 20cm without them. - B e X o R  11:39, 5 April 2007 (EDT)
 * It is readable if you concentrate on it, but I don't want to need to use more time and concentration to see how much the skill wil benefit me when I'm scrolling through skills and builds. It does make a big difference in time that I need to use on a skill page, I've tested. -- [[Image:User Gem sig.png|Gem]] (gem / talk) 11:47, 5 April 2007 (EDT)
 * It should be changed - of course. I was expecting to get pulled up on this much sooner

(and probably with a bit more indignation) because this discussion has already taken place. :P It was cheeky of me to implement it with the small font knowing full well that there was a large discussion and concensus for the default font size further up the skill formatting page. Forgive me for using this template to make a small point about how the format is easy to change once the template parameters are finalised.
 * With this in mind I've immediately removed the font size 90% parameter., but you might like to consider increasing the cell padding from '2' to '3'. --Aspectacle 13:08, 5 April 2007 (EDT)
 * I've also changed the cell padding from 2 to 3. It makes the progression less of a great blob of  numbers that way. --Aspectacle 13:15, 5 April 2007 (EDT)
 * Much better now. I totally forgot that it was allready agreed on the skill formatting page. -- [[Image:User Gem sig.png|Gem]] (gem / talk) 13:56, 5 April 2007 (EDT)


 * I put the cellpadding back to 2, I thought 3 was a bit too much... I hope you don't mind! I also reduced the size of the header, although I'm not sure if that was a good idea, lol. LordBiro 14:27, 5 April 2007 (EDT)


 * I changed my mind, sorry, 3 does look better!! LordBiro 14:34, 5 April 2007 (EDT)


 * It's rare to see you change your mind, but it's good to see it atleast once in a while so now we know that it is possible. ;P -- [[Image:User Gem sig.png|Gem]] (gem / talk) 14:45, 5 April 2007 (EDT)


 * Hehe, well I don't like doing something until my mind is made up, but that was an unusual spur of the moment change ;) LordBiro 17:05, 5 April 2007 (EDT)

Template Change
Why not try to change the color of the background on the template, for example (Warrior):

Using the colors from: List_of_elite_skills_by_campaign Note: its possible adding the ranger, ritualist, assassin, dervish, paragon, monk, mesmer, necromancer... colors. the template page can be uopdated with those "template example" already with the new profession colors.
 * We use the green color to make it consistent with the skill infobox :) - Anja [[Image:User Anja Astor sig icon.png|Anja Astor]] (talk)  06:48, 2 May 2007 (EDT)
 * Of course but by adding diferent skill progression templates, it would save a lot of work Template:w_skill_progression <- this for example, alos if we change this the skill box also needs the same changing (in the colors perspective (warriors template skillbox... etc), it gives a lot of work but in the end it worth it (sorry for my poor english)
 * What work do you mean it saves? I don't see anything else than more work with your suggestion, since all skill articles would have to be changed, for example. Plus, I think the consensus was to use the same infobox for ALL skills, and thus have the same color also. It makes the articles easier to recognise, imo :) - Anja [[Image:User Anja Astor sig icon.png|Anja Astor]] (talk)  07:01, 2 May 2007 (EDT)
 * If you see User:BeXoR/Infoboxes you can see the way colours represent content. Using profession colours would just confuse things more. The skill infobox has the nice big profession image in the background, as well as the profession name and icon in the details, so it's not difficult to recognise which profession the skill is for. - B e X  07:19, 2 May 2007 (EDT)
 * I didnt know about those, still like the prof color based templates tho. but it its defined that way, theres anything i can do in this matter. --The preceding unsigned comment was added by User:194.210.96.137.
 * It was a general consensus, but isn't official yet. If you feel like convincing everyone to change it, then I suggest you do so here Guild Wars Wiki talk:Formatting/Infoboxes. There have been several discussions about it already though, scattered around the wiki, so I don't know how successful that would be. I personally much prefer the current system and think it makes more sense in the broader spectrum of wiki articles. - B e X  08:03, 2 May 2007 (EDT)

Move to CSS
I would like to suggest a move to CSS-classes for the table elements: Any comments? See also Mediawiki_talk:Common.css. Any optimizations are welcome, I'm not the greatest CSS-artist. -- (CoRrRan / talk) 13:14, 7 May 2007 (EDT)


 * You don't need a lot of those classes. If the class of the table is "skill-progression" then you can set rules for the rows by saying . The same applies to the header. For simplicity's sake it might make sense to keep the "skill-progression-1strow" class; you can apply rules based on the context, i.e. style all rows with a green background, but style all rows that follow a row with a white background, but IE6 doesn't handle these properly. LordBiro 14:53, 7 May 2007 (EDT)


 * I was wrong about th actually. The first cell in every also uses a th, so a class is needed in order to differentiate between them.


 * I've put an example at User:LordBiro/Pain, and the CSS is in User:LordBiro/monobook.css. LordBiro 17:35, 7 May 2007 (EDT)
 * How come doesn't your example show the background colors? If you look at User:CoRrRan/Sandbox2, it does work as a normal skill progression-template. My CSS is located at User:CoRrRan/monobook.css and the updated template at User:CoRrRan/Sandbox. -- [[Image:User Corrran sig.png|CoRrRan]] (CoRrRan / talk) 17:46, 7 May 2007 (EDT)


 * As I said above you don't need a lot of those classes, so my table in User:LordBiro/Pain is different to your version. Equally my CSS is shorter, because you don't need a lot of the CSS you've suggested. Have a look at my User:LordBiro/monobook.css. LordBiro 06:07, 8 May 2007 (EDT)
 * Oh wait! I didn't update my monobook.css stylesheet when I looked at your example. So I guess it's not showing correctly. -- [[Image:User Corrran sig.png|CoRrRan]] (CoRrRan / talk) 07:28, 8 May 2007 (EDT)

Auto-wrap
Just implemented an auto-wrap method for this template. See also the discussions on Guild Wars Wiki talk:Formatting/Skills, on Infuse Health and on MediaWiki talk:Common.css. poke | talk 15:45, 18 August 2007 (UTC)


 * This now autowraps even for those who wasn't suffering from the display error, thus not needing it, meaning it looks rather horrible. Backsword 15:48, 18 August 2007 (UTC)


 * Do you have an example of one that didn't need it? On the ones I tested, it looks okay - although I would like to see some buffer space between the wrapped rows to improve readability. --- Barek (talk • contribs) - 15:49, 18 August 2007 (UTC)
 * It only wraps if you really need a wrap (=when there is not enough space for the table). And it is needed, see the discussion on Infuse Health. A buffer space is not possible without changing the layout for progressions where no wrap is needed and I don't think it would look better. Also this method is meant to make it possible that big progressions can be correctly displayed without floating into the Skill infobox. As this not happens for every users and for every page it should be not that big issue. poke | talk 15:57, 18 August 2007 (UTC)
 * Poke,
 * True, for me, my screen and resolution is big enough that I never saw the problem in the first place, only when I resized my window from full width. But, when it does wrap, the rows being close together does make it harder to read - at least to me a buffer space between them would improve that issue.  I hate leaving a less-than-optimal display for even a sub-set of users, especially if the main argument for it is "not many poeople will see it displayed that way anyway".


 * Backsword,
 * You mentioned that the change was causing problems for a skill someplace, can you link to it? All the ones I've checked appear to only wrap if/when needed due to width restrictions. --- Barek (talk • contribs) - 16:04, 18 August 2007 (UTC)
 * When I made the template I tried different things to change the border etc. but everything looked stupid in some way when wrapped (for example all borders tied to the cells instead of the complete table or heading). A buffer space would be possible but then there would be always some whitespace - when wrapped and when not wrapped - but I simply think that it is not needed as the different rows has different background colors and you can easily differ them (imo). At the moment it is not possible to make a better wrapping without using complex javascript or something else. Because of this it is also not possible to repeat the variable titles for each row.
 * The reason I say "not many people will see it displayed that way anyway" is simply because it's true. The display resolutions today are normally 1024x768 or higher. The wrap problem only occurs on 1024x768 on progressions with 3 digit numbers. There are not that many skills that have 3 digit numbers so not many people will ever see this wrap. But because of the discussions there was a need to do something like this and I think it is ok. (Btw. I don't think we should change the view for the users who had a correct view so I do not think we should add a buffer space) poke | talk 16:13, 18 August 2007 (UTC)
 * Like I said, it looks okay ... I just think it could look better. To me, an argument that technical limitations prevent adding the buffer (as doing so would make it look worse when not wrapped) is a good argument - and I'm appeased by it.  If the only argument was that not many would see it, that - to me - is a bad argument when used by itself.
 * But, as there is a technical limitation here, that's good enough for me. --- Barek (talk • contribs) - 16:24, 18 August 2007 (UTC)


 * I would like to hear more from Backsword.


 * As far as I can tell this change means that those articles that previously had problems now look better, and those articles that had no problems look pretty much the same. While an even better solution might exist (one with some 'buffer' perhaps) there is no doubt in my mind that this change was a good one. LordBiro 16:36, 18 August 2007 (UTC)


 * Just to clarify (as you're replying to me) at no time did I say this change was a bad one - I support this change. I only said that, if technically possible, I think readability could be better with a buffer between rows when wrapped.  As it appears that this cannot be done without negatively impacting the appearance when not wrapped, I'm fine with it as-is, and support it as an improvement over how it was displaying. --- Barek (talk • contribs) - 17:37, 18 August 2007 (UTC)


 * I understand, Barek, I was just trying to make it clear to poke, more than yourself, that while there might be room for improvement his change is a positive one. :) LordBiro 18:11, 18 August 2007 (UTC)


 * Compare Image:User_Backsword_SPTnew.PNG with Image:User_Backsword_SPTold.PNG. These are from Golden Lotus Strike, but the same remains true for Infuse Health and several others. Only difference being the temp revert of this template.


 * (Delete pictures later, as they are screenshots) Backsword 19:45, 18 August 2007 (UTC)
 * First of all: don't change the template, to make a screenshot of an old version. Instead use the history, copy the code to your userspace and make it there, but changing the template will cause ~1000 skill pages to reset their cache! Second: Why are the screenshots that big? If you load the page and then make the font-size bigger (by CTRL + mouse wheel for example) it does not work, as the table loads it's own maximum size and then the content floats. Normally, it does not wrap (try reload and then just look) and it should work. poke | talk 23:14, 18 August 2007 (UTC)


 * I've tried those two skills under several different screen resolutions and window sizes - I can only get the table to wrap if/when it's too wide and should wrap. Because your screenshots only show the progression box and not the related skill box, it's impossible to tell from the screenshots if it is right up to the skill info box, but from my tests, being up to that box is the only time those two wrap, so I still fail to see the problem you've mentioned. --- Barek (talk • contribs) - 02:53, 19 August 2007 (UTC)


 * You can se the lower lef corener of the infobox in one of them. Basicly, it goes below the infobox, and is now wraped so it can be pushed up alongside it. From the debate over Infuse Health, it seems to be what most users get; the display problem seems to happen to some versions of firefox. Backsword 08:02, 21 August 2007 (UTC)
 * Again, it can only happen when you (after loading) change the font size.. Resizing window/resolution works if you reload the page. poke | talk 08:12, 21 August 2007 (UTC)
 * 'fraid that's not correct Poke. I don't normally fiddle with such things, so it's not the case for my screenshots. Also, since you mentioned it, I went and tested it, and no, font size has an effect, but it is the same effect as screen resolution, irregardless of when fontsize is set. Backsword 08:40, 21 August 2007 (UTC)
 * But how do you set the fontsize? The screenshots show that that obviously is not the normal font-size. poke | talk 09:11, 21 August 2007 (UTC)

Wouldn't it be much simpler to add space between the top of the page an the progeression box? I use 1024X768 on IE7 and the progression box is wrapped because the skill info box is at the end of it. I get the same on firefox (at 1600X800) and Netscape (at 800X600 and 1024X768) and three different OS. By simply putting the progression box below where the infobox ends (or even above it) the full width of the page becomes available, and all but the lowest resolutions will not need wrap. Just my thoughts... Gwynna Vive 02:08, 5 September 2007 (UTC)
 * This would make more problems.. See Healing Hands for example: If the progression box is below the infobox there would be a very big useless and empty area. Also it is not guaranteed that the progression box is then fully displayed (for example with resoultions below 1024x786). poke | talk 05:27, 5 September 2007 (UTC)
 * This example displays fine on my machines, and I am not trying to get rid of the wrap, it is needed for low resolutions and will appear of every single progression regardless at 800X600 or lower. I do understand about the blank space as well.  Perhaps adding the progression at the very top, and the infobox immediately below would work, or making the height scaleable so that long variable names (ie: domination magic) can be broken and still keep the table connected (top to bottom).  Current design leaves the vertical lines short if the variable is 2 lines high.  Again, just some thoughts and ideas.  Gwynna Vive 02:47, 6 September 2007 (UTC)

Progression range
IMO we should use 0...20 for attributes without 20% +1 items and 0...21 for attributes with 20% +1 items. You can get any attribute up to 20 with Candy Corn, a Golden Egg, a Grail of Might and the appropriate blessing, monsters can have attributes as high as 20 in Hard Mode and attribute raising buffs can't bring an attribute above 20. -- Gordon Ecker (talk) 04:24, 24 November 2008 (UTC)
 * Yes, the current ones seem fairly random. Rather than wild guesses at what people may use, just list a few more values and be sure, since we now know the max. Backsword 20:50, 30 November 2008 (UTC)
 * I've implemented it now. Backsword 19:17, 16 December 2008 (UTC)