GuildWars Wiki talk:Style and formatting/Skills

Archives
/Archive 1 ~ 10th Aug 05	/Archive 2 ~ 25th Jan 06
/Archive 3 ~ 20th Feb 06	/Archive 4 - The Skill Box Revamp vote
/Archive 5 - The incomplete new skill box decision	/Archive 6 - The Skill icon format vote
/Skill box - The revote that settled the new format... for now	/Archive 8
/Archive 9	/Archive 10 - QR style, energy per second in progression
/Archive 11

Addition of blank template

I added a blank basic template under the example one. Would it be better to change their order (that is, provide the blank and then the prefilled as an example) or is it better as is? Or should I do away with it altogether? --HopefulNebula 02:45, 5 June 2006 (CDT)

Suggestion: linking elite skills to builds

moved from GuildWiki:Community Portal

While trying to figure out ways to better display and make accessible our builds collection, I've come up with the following suggestion:
I think we should make an addition to the default skill template for elite skills (possibly even for all skills), called "Builds focusing on this skill" or similar, and under the headline, link in the builds in the [[Category:tested builds]] that make use of the skill in question. This would showcase and make the good builds more easily accessible, make it easy to see if your idea for a build has already been done, and just plain be a practical reference for finding a build you know is here (but don't know the exact name). Thoughts? --Bishop (rap|con) 21:55, 10 May 2006 (CDT)

The way current template mechanics are, the section you want will appear above progression and acquisition. I do not believe it is the proper place for it. It should be manually added towards the bottom of the article, if the linkign is to be done. -PanSola 23:13, 10 May 2006 (CDT)

Agreed. I wasn't suggesting, or even thinking of, anything automagic. --Bishop (rap|con) 00:11, 11 May 2006 (CDT)

To showcase, rather than explain, what I mean, I have taken the liberty of adding my idea to the IW article, as an example. --Bishop (rap|con) 00:34, 11 May 2006 (CDT)

No comments on this for over a week. If there are no objections, I'm going to start implementing this soon. --Bishop (rap|con) 09:52, 19 May 2006 (CDT)

Exactly why would this need to be done? I do not think the builds need to be more accessable, it will be alot of data to update if a build was updated/removed than just the build page. I would rather not see such variable and technically opinionated information be added to the skill pages which should be entirely concrete fact. --Draygo Korvan 10:13, 19 May 2006 (CDT)

Do not use include/templates for Skill Quick References

moved from User talk:PanSola#Skill boxes

What are you trying to achieve, and wouldn't it be better to experiment on non-live pages? Hank 22:19, 11 May 2006 (CDT)

I thought I was done with experimenting. Then as I was pushing it live, I discovered I was wrong. Now Ithink I'm done with experimenting again, so I'm pushing it live again. -PanSola 22:21, 11 May 2006 (CDT)

Gah! Can you not explain what you're trying to do? Is this related to that subst issue above? If so there is a simple solution. {{subst::Rush}}. Hank 22:57, 11 May 2006 (CDT)

I'm keeping things dynamic, but using template instead. -PanSola 22:59, 11 May 2006 (CDT)

It is a terrible idea. Can I talk you out of it? You will kill the server with a page such as Mesmer Skills Quick Reference. Not to mention template pollution and confusion for editors. Please use subst. Hank 23:03, 11 May 2006 (CDT)

Like you said, template stuff are cached, so I don't see why it'll kill the server. SKill articles get edited often, but not the skill details that are being put into the templates. I think subst still defeats the entire motivation behind GuildWiki talk:Style and formatting/Skills/Archive 4. Namely, we need to remember to update multiple articles when a single skill changes. I see little benefit in re-subst compared to manually updating Mesmer Skills quick reference, Interrupt Spells Quick Reference, Mantra Quick Refernce, Signet Quick Refernce, Degen Skills Quick REference, or a sixth article whenever Anet changes skills between ladder seasons. -PanSola 23:08, 11 May 2006 (CDT)

I never said "template stuff are cached". That would be wrong in any case. I have considerable experience with the MediaWiki templating engine, so please let me examine the proposal again. There is no principal difference in recaching if the skill quick reference article includes {{Rush}} or {{:Rush}}. The costs are identical. Every time a page that has about a 150 templates or so is rendered, it will still query every single template at the database to see if it needs to rerender. So you do not avoid any cost in separating a fixed portion of a skill article from a variable portion. MediaWiki templates are not robust enough for a page to have more than a couple dozen of them without consuming a terrible amount of memory. This is by design.. Hank 23:19, 11 May 2006 (CDT)

If the article Rush has been edited, but all the edits happen in the noinclude section, then is the render engine robust enough to not re-render it (when loading a page containing {{:Rush}}? It still makes a difference between 150 queries and not having to re-render, or 150 queries and HAVE to re-render because an artiticle got stubbed, or someone while editing a non-included part of the article, suddenly decide to adjust the whitespace in the included section to make the raw text in the edit box easier to read. -PanSola 23:26, 11 May 2006 (CDT)

No, it will force a recache of all pages that include a page whenever the text of the included page is changed. However, this is not the issue. Stripping noinclude sections takes nanoseconds. What is the bigger issue is that a page that includes 150 templates will cause O(150) database queries every time, even if the templates themselves have never been touched since the last render. The strain on the database is far greater than the computation required to rerender the page. Hank 23:27, 11 May 2006 (CDT)

Darn, and this is including features since MediaWiki 1.6, not just 1.5 and prior right? I would've thought if MediaWiki figured out how update link tables to deal with categories used inside templates, then this wouldn't be a problem. -PanSola 23:38, 11 May 2006 (CDT)

It is true of MediaWiki 1.7+ CVS as of last night. Like I said, by design. There have been no plans to "pre-cache" templates or any other suggested alternative because it was deemed long ago that it is worth paying the price of querying the DB for every used template. Hank 23:44, 11 May 2006 (CDT)

I guess it's no huge surprise the wiki is becoming so unbearably slow, then, with the recent template-craze (I'm not referring specifically to this, but the general use of templates everywhere)... of course, it's easy for me to be smug, I've never liked templates in the first place (beyond very limited use, anyway). --Bishop (rap|con) 23:39, 11 May 2006 (CDT)

BTW, the "recent template-craze" is about editing, changing, and updating templates. We aren't using templates in any articles we weren't using them before. In fact there is a net number of reduction of templates being used, as teh armor and skill articles each used to use about 10~15 templates each, and now it's more like 3~4.

BTW, so when it checks whether a rerender is needed, does it do a diff, or does it look at timestamps of most recent modification? -PanSola 23:42, 11 May 2006 (CDT)

Timestamps mostly. The most accurate answer is that it first asks any of the object caches if the referenced template with the referenced parameters have been invalidated, and if any of them answers yes, then it queries the template article's timestamp to see if the invalidation was the result of a modification or because of other cache coherency conditions. But, generally when it gets to the second stage, it has already made two database queries (though to much more memcacheable tables than the full article itself). Hank 23:48, 11 May 2006 (CDT)

So if I compare a page that uses 150 templates (which take no parameter and only contain plain text), versus a page that has 150 links, does the number of queries differ? I presume queries are needed to decide whether links should be rendered as to the articles directly or to an edit page for new article creation. -PanSola 23:52, 11 May 2006 (CDT)

You are right that queries are needed to verify the existence of links, but the problem is far simpler, as databases are very efficient at answering existence queries. Also, it should be noted that existence queries are possibly the most cacheable queries possible. I should make one other point clear, because I am not sure if I conveyed it correctly. The O(150) queries are needed on a recache, but not on every visit of the page. Presumably the quick reference page has far more views than the skill articles change, so there is still some amortization. Hank 23:58, 11 May 2006 (CDT)

"The O(150) queries are needed on a recache, but not on every visit of the page" I definitely misunderstood you earlier. Another question: does use of embedded images generate the same type of quieries as use of templates? And is MediaWiki smart enought to only send one query if a particular image is embedded 150 times in the same article? -PanSola 00:03, 12 May 2006 (CDT)

The MediaWiki rendering code does nothing clever about images, but the database layer in the MediaWiki code is clever enough to remember the result of asking if an image exists (and where its imagefile can be found) the first time the render layer makes the query. So the next 149 queries finish about a thousand times faster because no database queries are needed. Hank 00:11, 12 May 2006 (CDT)

Hmm, back to an earlier point, because the O(150) renders only happen on a recache, which only happens when the included article/template is modified, and becasue we only expect the skill details part to be modified between ladder seasons, I feel the usage of the templates will only cause a relatively insignificant amount of server drain (note this is different from including the full skill article, which gets edited OFTEN and produces big server stress). Comparing it to the benefits of keeping information centralized, I am still supportive of using the templates. IF I am proven to be wrong and it does have a non-negeligable impact on the server, we can always (and easily) subst them at that point. This is my opinion after considering all the evidence presented above. -PanSola 00:27, 12 May 2006 (CDT)

Recaches are not triggered only by changes. Any number of things can trigger it. For instance, the there may simply be too many entries in the object cache, in which case some entries are expired using a LRU algorithm. Also all cached objects have a forced hard expiry time after which a rerender is forced no matter what. Also some pages are simply uncacheable for various convoluted reasons and I have to read the cache code again to convince myself that the quick reference pages are cacheable. I still think that if you want a centralized location, then the difference between {{Rush}} and {{:Rush}}> is minor. Hank 00:34, 12 May 2006 (CDT)

By the way, if you want to persist with your plan, I would suggest making "subpages", ie., Rush/Skillbox, instead of polluting the Template namespace. Hank 00:38, 12 May 2006 (CDT)

I consider the difference to be major if we have to redo the subst. Or more precisely, if we have to remember to do the subst on other articles. I didn't realize sub-pages take parameters. I thought only articles with colons in their names do. Why is the way I use the template namespace considered as "pollution" btw. That concept is relative foreign to me. -PanSola 00:42, 12 May 2006 (CDT)

There is nothing special about pages in the Template: namespace except that Template: is the default namespace for transclusion, just like {{NS:0}} is the default namespace for normal articles, etc. All transclusions can take arguments. It would be rather hard to test out templates in user subpages if they didn't. About pollution -- wouldn't you prefer all pages about the "Rush" skill to be named "Rush/somethingorother" rather than half being "Rush", half "Template:Rush", and the remaining half in some other place? I would. Plus, I was browsing the Special:Allpages in the template namespace earlier to see what sorts of templates you guys use, and I would hate to wade through 500 templates with no real purpose. Hank 00:45, 12 May 2006 (CDT)

Another reason for subpages just occured to me. Talk:Rush/Skillbox would naturally be a real subpage of Talk:Rush then. Hank 00:48, 12 May 2006 (CDT)

Hmm, the overall GuildWiki practice has a trend to make transclusion be as easy (ie short) as possible, as evidenced by Template:Monk, Template:G, and so on. As a 6-month GuildWiki user and not familiar with other major wikis, I'm not particularly bothered by the fact that some info of Rush is in Template:Rush, especially when that info is accessible and has an edit link to it from the Rush page (and any page that transcludes Template:Rush. We are trying to categorize all our templates via Category:Templates instead of using Allpages, since similar templates won't get grouped together anyways. Besides, if something is a template (I consider Template:Rush to be a template, not just a subpage, but our views obviously differ), it makes the most sense to put it in the template namespace. It's a template that takes parameters and controls how information about Rush is displayed in other articles. Anyways, I'm going to leave this entire issue just hang here for half a day or so, so others can voice their opinions. -PanSola 00:54, 12 May 2006 (CDT)

What is hard about including a "subpage"? Just add {{{{PAGENAME}}/Skillbox}} to every article. This is so systematic that it can be templated into {{skill}} to be added at the top of every skill article. The quick reference pages will presumably be created by clueful people who will know to include {{:Rush/Skillbox}}. A half day's cooldown is good. Hank 01:00, 12 May 2006 (CDT)

I'm late to the discussion, but I think Karlos would be furious about some info being in Rush and some being in Template:Rush. I wouldn't be furious but I agree with his issue on redundant data. --68.142.14.79 05:24, 13 May 2006 (CDT)

The proposal is to have some info about Rush in Template:Rush, some different info about Rush in Rush, which includes Template:Rush. This is called splitting the data as opposed to having redundent data. Redundant data is the alternative: All info about Rush in Rush, half of the same info about Rush is in Warrior Skill Quick Reference, and also in whatever other quick reference articles or build articles that want to include Rush's information. The third alternative to avoid Split Data or Redundant Data, is to have a very very over-worked server. -PanSola 05:46, 13 May 2006 (CDT)

Looks like this subject isn't something most ppl keep an eye on. I'll continue ahead with the project. -PanSola 01:06, 13 May 2006 (CDT)

Subpage or include only it or something—polluting the template namespace is a BAD idea! Hank is right on the money here. If I knew anything about this "subst" thing you keep bringing up, I'd argue about that too. :) —Tanaric 21:12, 13 May 2006 (CDT)

Okay, after rereading this, I see I was mistaken before about what you were doing. But now I'm unclear on how the new templates either simplify editing or decrease server load. The QR pages will still include the same number of templates as far as I can tell. QR would include {{skill}}, which ends up using {{skill box row}} versus QR including {{:skill}} which through includeonly/noinclude would use {{skill box qr}}. Is the change just to reduce the number of lines in the skill articles that the unknowledgeable shouldn't touch? --68.142.14.79 22:06, 13 May 2006 (CDT)

Compare to the original plan of including skill articles directly in quick reference pages, the use of the templates do decrease server load. The reason is, in the original plan, whenever someone edit the article Mantra of Recovery, perhaps to correct a spelling on a usage note, perhaps having a revert war on the edit note, or whatever; whenever someone edit that article, all other articles that include Mantra of Recovery (various quick reference pages) would have to rerender their own cache. The plan of using the template reduces server load because re-render would only be needed if someone edit the actual skill details of Template:Mantra of Recovery, as opposed to if someone edit the skill article directly. -PanSola 22:19, 13 May 2006 (CDT)

Hank said that (he thinks) "the difference between {{Rush}} and {{:Rush}}> is minor." --68.142.14.79 22:35, 13 May 2006 (CDT)

I believe he said it under a different context. Specifically, he said it in the context of having data being centralized. I believe he wasn't talking abut different in teh sense of server load. -PanSola

Before that sentence, he was discussing MediaWiki's caching, so I don't think so. --68.142.14.78 00:37, 15 May 2006 (CDT)

The "Plan"

So here's what my planned template will feature (not all features implemented):

1. When in the quick reference view, the ability to hide or override the profession/attribute column, the stats symbols, the description, the skill type, and/or the campaign. This will be done by providing parameters to whatever is being included (be it a template or a subpage).

Example syntax:

{{Backfire|row| profession=hide|attribute=hide}}

(the "row" is used to trigger the special quick reference view.

Usually just including Backfire will cause it to display everything. But if you set any of the fields to "hide", the entire column will be hidden. Even the icon can be overridden or hidden.

2. Ability to add custom notes. This can be done by either overriding existing fields (say I want the column that used to display attribute to change to % speed increase for a speed article), or by adding a "notes" parameter.

Except the custom notes functionality, everything else have been implemented.

Factions Skill Icons

Some of you may have noticed I uploaded a clean good looking skill icon for Bull's Charge, Resurrection Signet, and Signet of Capture. Thats because I found them, and all the factions skills, at 50x50 on the Guild Wars Japan site. Because those were all core/prophocies skills I figured I should take advantage of that and resize/add border to them and upload them so we have good looking versions. However, I'm not sure what to do about the factions ones. I could easily take all the factions icons and resize/add border to them and upload them but do we want to instead wait for the fansite kit to come out first? The icons already formatted to 64x64 from the fansite kit would look much better and it looks like it might be out soon seeing as they are already using the icons for those skills. (T/C) 23:26, 14 May 2006 (CDT)

We have no clue when the fansite kit will be updated, as a point of information. -PanSola 00:28, 15 May 2006 (CDT)

Discussion with major implications

Not sure if anyone would be paying attention here but not GuildWiki talk:Community Portal. Anyways, there's a discussion over there about how data used in multiple places is to be handled. Just follow this link: GuildWiki talk:Community Portal#A New Section for the Bigger Issue - Split/Subst/Redundant. -PanSola 05:58, 16 May 2006 (CDT)

Elite Skills categorized

When an elite skill is categorized in any category page other than Category:Elite skills, it should be added with the keytag (Elite) this will make it easier for people to spot elite skills from regular skills eg:

[[Illusion Magic skills|Illusionary Weaponry (Elite skill)]]

--Jamie 04:01, 4 June 2006 (CDT)

I don't understand what you are talkinga bout... -User:PanSola (talk to the ) 04:45, 8 June 2006 (CDT)

I would have thought it was simple, basically to make elite skills easier to find in the category sections we tag then with the suffix (Elite skill) in every category they are in. Except for Category:Elite skills where all the skills are Elite Skills.

What this achieves:

• Easier for users to find & locate Elite skills in category pages like Category:Illusion Magic skills. --Jamie 05:09, 13 June 2006 (CDT)

Um, that wouldn't help. It doesn't change how the skill shows up in the category page. -User:PanSola (talk to the ) 05:28, 13 June 2006 (CDT)

Alright.. it was just an idea, I was thinking it would be like Pipelinking in category pages, but obviously not... --Jamie 06:03, 13 June 2006 (CDT)

Vote: Format of Fractional activation time for Skills

I apologise if this has been finally settled before, but I am unable to find a decision about this within the WiKi (and especially within the Archives of this very talk page).

What's all this about? There's skills like e.g. Blessed Light that have a fractional activation time like three quarters of a second that can be written in different formats:

Choices

1 (aka: plain text)

• 1/4, 1/2, 3/4

1/4, 1/2, 3/4

2 (aka: htmlchar)

• ¼, ½, ¾

 ¼, ½, ¾ 

3 (aka: htmlcode)

• ¹/₄ ¹/₂ ³/₄

<sup>1</sup>/<sub>4</sub> <sup>1</sup>/<sub>2</sub> <sup>3</sup>/<sub>4</sub> 

4 (aka: latex)

• , ,

 [[Image:Frac_1_4.png]], [[Image:Frac_1_2.png]], [[Image:Frac_3_4.png]] 

Note: GuildWiki does not currently use the latex plugin to support variant 4, so I just uploaded the corresponding images created on wikipedia.

5 (template)

• Template:1/4, Template:1/2, Template:3/4

{{1/4}}, {{1/2}}, {{3/4}}

Pros and Cons

Variant 1 (plain text)

• Pro

• simple
• readable in any browser

• Con

• harder to recognize as a fraction

Variant 2 (htmlchar)

• Pro

• conforms to html standard
• easy to recognize as a fraction

• Con

• very small and hardly readable

Variant 3 (htmlcode)

• Pro

• easy to recognize as a fraction
• good readable

• Con

• not the standard html representation
• considered ugly

Variant 4 (latex)

• Pro

• easy to recognize as a fraction
• good readable

• Con

• requires latex plugin or images
• huge as compared to the others and the non-fractional numbers

Variant 5 (template)

• Pro

• conforms to html standard
• easy to recognize as a fraction
• easy to input without memorization of fancy stuff
• inflatable

• Con

• 3 more templates for the wiki

Vote

Please place your name by your main preferences, and specify alternate backup choices after your name for the purpose of instant-runoff.

This vote is open until 7 July 2006

Variant 1 (plain text)

1. Latecomer vote for a totally unpopular option. Really, though, this option has the lowest barrier to entry. I would even propose a decimal notation (i.e., 0.25, 0.5, 0.75) because it is the most flexible; for instance, Fast Casting already uses this format. Seventy.twenty.x.x 05:13, 10 June 2006 (CDT)

Variant 2 (htmlchar)

1. --Bishop (rap|con) 04:36, 8 June 2006 (CDT) Standards, standards, standards!
2. --Theeth (talk) 06:08, 8 June 2006 (CDT) Except with the html entities instead of the unicode code points.
3. --Draygo Korvan 11:14, 8 June 2006 (CDT) Standards!, i think templating it is a seperate issue. The template should use the HTML standard. using <sup> is too messy!

Variant 3 (htmlcode)

Variant 4 (latex)

Variant 5 (template)

1. User:PanSola (talk to the ). Alt choices in order: 1 > 3 > 2
2. Chi Li . Alternatives in order of preference: 3 > 1 > 2
3. User:Xis10al Alternative choices: 1 > 2 > 3
4. Xasxas256 Easy to use, easy to read
5. Skuld Easiest to read, easiest to use 3:2
6. Chrono traveller I like it since it is (currently) basically 2 but larger font, for those who may have problems reading it, alternate choices: 2 > 1 > 3 (alas my poor latex fractions aren't an option till the math plugin is implemented)
7. Rainith Oh god, another fsking skill vote.  :(
8. --- Barek (talk • contribs) - 11:10, 8 June 2006 (CDT)
9. Thank you for not making the template link to an image. I'm voting for it. — 130.58 (talk) (11:15, 8 June 2006 (CDT))
10. HopefulNebula 02:01, 9 June 2006 (CDT) alts in order: 1, 3
11. User:LordBiro This is a very old discussion on the GuildWiki, and I'm sure it was settled, but I can't find it anywhere. Maybe it wasn't! Anyway, I think template is the best choice. <LordBiro>/<Talk> 04:58, 10 June 2006 (CDT)
    • P.S. After reading GuildWiki_talk:Style_and_formatting/Skills/Archive_2#Skill_Formatting_Example it looks like Tanaric and myself already made this suggestion a year ago :) hehe <LordBiro>/<Talk> 05:04, 10 June 2006 (CDT)

P.S.

Please don't feel offended by me using my preferred variant while moving skill pages to the new template. As stated on my talk page I volunteer to change every skill template to the standard format once a decision is reached. --Chi Li 04:21, 8 June 2006 (CDT)

Discussion

As I see it, there have been various attempts to standardize this tiny aspec ot the Skill description, but none of them led to a final decision. In the recent past the discussion about this fractions was brought up again on various talk pages, including Chrono traveller (talk) and Chi Li (talk).

On the existing skill pages and skill templates the variants 1, 2 and 3 are used, so in fact no standardization has taken place yet. The Example Skill currently uses variant 2, but that's IMHO just a result of an unfinished discussion from the past.

I'll try to summarize the pros and cons for each variant (these are initially based on my opinion, so please add your own pros and cons): - Chi Li

Previous discussions on this issue:

• GuildWiki talk:Style and formatting/Skills/Archive 2#Skill Formatting Example
• GuildWiki_talk:Style_and_formatting/Skills/Archive_5#Discussion on Hybrid 2

-User:PanSola (talk to the ) 04:35, 8 June 2006 (CDT)

Variant 3 will look like ^1/[4] on text browsers, so I reject that option. If variant 2 gets passed, I'm just going to ignore it, type "1/4", and let other people clean up after me, because there is no way I am going to memorize the htmlcharr code. This is a wiki for the love of Cunningham. Variant 4 is currently not pratical, so is a moot option. -User:PanSola (talk to the ) 04:53, 8 June 2006 (CDT)

That totally works for me. 2 is the correct one to use, imho, but if you feel like using 1 instead, that's fine because content over presentation. --Bishop (rap|con) 04:58, 8 June 2006 (CDT)

Correct with respect to what? Half the point of wiki is to avoid html code. Kinda ironic to be using something that is being labeled as "htmlcharr" (unless that's just a random misnomer invented by Chi Li). Granted, I'm guilty of using lots of fancy formatting and templating to enhance presentation, but I pay extra attention to make sure those fancy stuff are hidden away from the average contributor, so all they need to do is filling out a template without needing to know how the fancy formatting/character stuff works (separation of content from presentation). I'm fine with variant 2 and content over presentation (as long as ppl clean up after me), but I challenge it being "the correct one to use". -User:PanSola (talk to the ) 05:20, 8 June 2006 (CDT)

Correct with respect to adhering to established standards whenever possible. I did point out that it was in my opinion, nothing more. Your point about acessability is valid, however. On reflection, I may be inclined to support option 1 equally. I would have supported your option 5, was it not that I think we have much too many templates as it is, and they're not making it easier for new users at all. --Bishop (rap|con) 05:29, 8 June 2006 (CDT)

Fair enough (-: -User:PanSola (talk to the ) 05:33, 8 June 2006 (CDT)

It is correct with respect to HTML. Anything between "&" and ";" is HTML-code for something you can't otherwise format with plain ASCII. I used term htmlchar to indicate that in this case a single character (char) is represented in html-code where the term htmlcode describes that a more complex structure is used to represent basically the same semantic value.

Would it be better to memorize or use for the average wiki contributor to implement something like {{frac_1_2}}: a template that would automatically fill in the same html-code on every occurance? This would be mainly used within a template anyway, so I see no harm in that. Edit: Just recognized that this is the newly added Variant 5, I'd support that (if the magnification to 125% or 150% is kept). --Chi Li 05:35, 8 June 2006 (CDT)

I actually do think it'd be better to implement {{1/4}} than to memorize that 190 gets turned into this, and 188 turns into that. "Mainly used within a template" is only a good reason when you don't need to type out something in order for something to be displayed. In this case, to have the template display the 1/4 sign, you need to type the 1/4, which is quite different from the auto-generated male/female symbol of the armor boxes. -User:PanSola (talk to the ) 05:42, 8 June 2006 (CDT)

Just curious (and hoping for an honest answer): Are you (or anyone you know) really browsing this wiki with a text browser? --Chi Li 05:06, 8 June 2006 (CDT)

Ask LordBiro. He's the major advocate for it back when we were re-designing the skill box templates. -User:PanSola (talk to the ) 05:15, 8 June 2006 (CDT)

For Variant 2, instead of the unicode code point, why not use the HTML entities: ¼ (&frac14), ½ (&frac12), ¾ (&frac34). This is much easier to remember. --Theeth (talk) 05:44, 8 June 2006 (CDT)

Probably because none of us knew it existed. -User:PanSola (talk to the ) 05:45, 8 June 2006 (CDT)

True for me :) Still I do favor encapsulating that into a template thats even easier to remember, at least for me. Chi Li 05:48, 8 June 2006 (CDT)

I also didn't know about this. But, I do think the template is probably the best way to go, since the htmlchar without an increase in font size is more difficult to read than others, but looks the best.--Chrono traveller 08:29, 8 June 2006 (CDT)

For what it's worth, the only ones I really like at all are plain text and template. I'm not scared of the template, and making the template {{1/4}} actually simplifies things, because plain text is exactly what novice users will put in, regardless of anything we say. (This makes it easy to change by throwing braces around it). I mostly hate the idea of using anything at all complicated for something that will be so very common. --JoDiamonds 12:48, 8 June 2006 (CDT)

Section ordering

This article and the example skill page currently have different orderings of the sections:

• Progression
• Notes
• Acquisition

versus

• Notes
• Progression
• Acquisition

which should we use?

Also, I have seen many pages rename the section headers and sometimes split them to be more specific, e.g., "Notes"/"Usage Notes" or "Additional Notes"/"Trivia", is this desirable? --66.92.33.187 01:19, 9 June 2006 (CDT)

1. Progression
2. Errata/Clarification
3. Acquisition
4. Notes

My suggestions would be Progression/Notes/Acquisition/Trivia. My reasoning is to list the things people are mostly likely to want to read first; Progressions is a key property, and Notes generally include things people don't know they are looking for but are generally relevant. People looking for the Acquisition will find it quickly regardless. Trivia is entirely superfluous and therefore can be last. =) If something isn't applicable, just leave it out. I think Errata/Clarification is just a more specific type of Note (as are Usage Notes, etc. Just fold nearly everything else into "Notes". I'd be happy supporting an optional "Trivia" section for things which are clearly irrelevant to gameplay. --JoDiamonds 19:12, 10 June 2006 (CDT)

I'm not too fussed about the order, but I do think it makes sense to show progression first, then a clarification of the finer points of the skill, i.e. "you can use this skill with this other skill to blow up parliament", then acquisition, and then trivia, such as "rodgort is trogdor backwards".

I think the term "Clarification" is better than "Errata". Errata means a correction, whereas in many cases on the GuildWiki we are really trying to clarify points. It is not often that skill descriptions in-game are totally wrong, but it is often the case that they could be elaborated upon. <LordBiro>/<Talk> 05:49, 11 June 2006 (CDT)

The slash is meant to be "whichever is/are applicable", where the slash in that statement means "whichever is applicable". -User:PanSola (talk to the ) 07:03, 11 June 2006 (CDT)

Quick reference box layout

← Moved from Talk:Mesmer skills quick reference

I liked them before, but I don't now that I've tried to actually use the skill list. The new boxes are pretty, but putting them in a list makes it exceedingly hard to actually read it: the icons are distracting, green/blue is too low contrast, and it difficult to quickly look at names when they are separated by descriptive text. A list that actually has all the names in a separate column would be much more user-friendly. — 130.58 (talk) (00:21, 11 June 2006 (CDT))

The green wasn't my idea. Pick something. -User:PanSola (talk to the ) 00:39, 11 June 2006 (CDT)

Maybe a lighter (pastel) green that lets the black lettering stand out better? Yes, I too miss the ! for questable skills. -Pandelume

It's not just the green, mostly (same color as the regular background would be ideal, though, if you're asking). It's the fact that there isn't a column that just has skill names and nothing else in it anymore. Your can't scroll through the list with your eyes very easily anymore. — 130.58 (talk) (00:45, 11 June 2006 (CDT))

Agreed. The previous lists were far more readable and informative. I miss the green "questable" exclamations. Seventy.twenty.x.x 00:43, 11 June 2006 (CDT)

The question mark has its own problems, and has been discussed elsewhere with no one ever proposing a solution that they favor personally, muchless trying to reach a consensus on what to do. -User:PanSola (talk to the ) 01:14, 11 June 2006 (CDT)

Ok I just gave skill name its own column, but I think the rest of the row looks worse now than it used to... -User:PanSola (talk to the ) 01:21, 11 June 2006 (CDT)

You're right: it's a bit uglier but way more readable. I find it much easier to look through the list now, at least. — 130.58 (talk) (21:13, 11 June 2006 (CDT))

Might I suggest switching position of the Prophecies/Factions box and the skill stat box? It would be nice to see that skill stats near the skill name (all at a glance, so to speak :) Another possibility would be to use a narrow column on the right for the letters 'P', 'F' or 'C' since it's more a tag for searching skills. It would reduce some of the visual clutter in the main body (description area) -Pandelume

There are only 26 letters in teh alphabet, and I wouldn't be surprised if by campaign 6 we are already running into duplicate letters. I personally would like to see numbers ("C1", "C2") etc, but that hasn't garnered much support from other ppl. As for location of the stats, it was placed there to mimick the location in hte in-game skill menu. If ppl are used to the skill menu layout, this would be pretty natural. -User:PanSola (talk to the ) 00:34, 13 June 2006 (CDT)

If and when that becomes necessary, I'm sure commonly accepted two letter abbreviations can be used, like Mo and Me (for Monk and Mesmer) for professions. If the stats are moved to the left, I'd suggest not even boxing it, since the icons would be distinct from the description below them anyway. Simpler is always better, IMO; it makes it easier to see each skill as a single big description block. And surely there must be a way to restore the ! questable. Just some suggestions. -Pandelume

The problem with the ! mark isn't not knowing a way, but that neither of the two ways to do it are supported by anyone. As for the stats, I am for keeping it boxed in order to keep them aligned between skills. -User:PanSola (talk to the ) 23:32, 13 June 2006 (CDT)

In terms of usability, the Campaign vs. stats boxes should definitely switch location. The campaign is generally of very minor importance, while the stats are vital and essential to what people are looking for. I do like the current form with the names in a column. And frankly, I'm 100% about usability and readability, and overall "prettiness" is irrelevant. It's not ugly if I can read it easily. =) --JoDiamonds 09:42, 13 June 2006 (CDT)

I love usability, too. Since most people seem to think the old one had more usability going for it, let's try this: everyone who cares, describe what works about the old boxes and what doesn't. Here's me starting...

• It's nice to have each entry on an individual column, as it makes it easy to scroll down visually. Though I think this is an ironclad requirement only for the name column.
• Having some visual cute to a skill's elite status is good, though it needn't be egregious.
• Factions/Prophecies/Core could've used some kind of symbol or color-coded letter. Just a word can be annoying sometimes.
• Giving casting/recast times is absolutely vital.

— 130.58 (talk) (23:54, 13 June 2006 (CDT))

• Having skill stats be column-aligned is good. -User:PanSola (talk to the ) 23:59, 13 June 2006 (CDT)

• Green and Yellow Backgrounds to distinguish Elite from usual skills is not necessary - I find it distracting and it makes things harder to read. The yellow border around the Skill Icon is enough, just like on the skill pages.
• Factions / Prophecies / Core should go to its own column, and something else than just plain text would be easier to distinguish, maybe an Icon or an iconic Letter (F, P, C).
• The Information that a skill is questable (green exclamationmark) should be included in the skill template to be evaluated by the list.

--Chi Li 02:58, 14 June 2006 (CDT)