GuildWiki talk:Style and formatting/Quick references/Weapons

Idea 1: Collapsible legend
Compare Perfect stat weapons (Domination Magic) with the status-quo legend represented by Monk_unique_items_quick_reference.

The legend width and position relative to the TOC is not part of the proposal.

Explaination
There was a previous general consensus to not use the show/hide javascript in general articles. Unfortunately I was not around back then so I did not know the arguments each side has used, nor am I successful in tracking it down. Thus, please excuse me if my points raised here are a repetition of what has been brought up and rebuked before.

I see the legend as something similar in purpose to the TOC, except it's usually less important. The legend does not help you jump to a section, and once you are familiar with the icons and abbreviations used in the skill or weapon quick reference list, the legend loses its value to you (whereas a TOC is still helpful). Additionally, the legend in some cases take up significant visual space.

It is my belief that the use of the show/hide script in this context, in a way that is consistent with how the TOC behaves, helps making the wiki more user-friendly, at least for users with javascript turned on. With the exception of font-size differences (adjustable via CSS), it does not noticeably affect users with javascript disabled (vs the status-quo).

Recognized issues

 * Cookie is not implemented yet, so unlike the TOC, the legend will not remember if you last set it to hide or show. Everytime you visit the page the legend will show by default, even if you left it hiding the last time.  Depending on feedback, I or someone else might add cookie support for it later, but it is not currently a priority for me.

Discussion of using collapsible legend
I'm against using show/hide in general - I much more prefer keeping default wiki behavior. Howqever, when used in just the legend, and having the default being to "show", I don't see it as being as much of an issue as prior examples/proposed uses - so I won't object too strongly here. --- Barek (talk • contribs) - 11:10, 13 April 2007 (CDT)

Idea 2: Sortable table
Compare Perfect stat weapons (Inspiration Magic) with the status-quo legend represented by Monk_unique_items_quick_reference.

Explaination
For users with javascript disabled, it will appear identical to the status quo. For users with javascript enabled, little square image boxes appears in the header row. Clicking on a certain square box sorts the table rows using the corresponding column to determine order. The list can be sorted by weapon name, requirements, suffix, campaign etc. The syntax for disallowing sorting for any arbitary column is simple (specifying class="unsortable" in the corresponding column's header cell).

Recognized issues

 * While ordering of plain text and pure numbers are easy, some data have special meaning in the game context, and may have a natural ordering that is neither alphabetical or numerical. The current javascript fortunately allows the customization and fine-tuning of such options, but will need to be implemented manually case-by-case.
 * Currently the sorting is not "stable", in the sense that if the sorting criteria results in a tie, which row comes first does NOT depend on the relative positioning of the rows prior to the sort. Stable sorting runs slower, and will be implemented after the current sorting code has been optimized to run faster.

Discussion of using sortable tables
Does not work in all web browsers (in IE7 only the weapon name column is visible - I believe IE6 had that problem too, but I'm not near my machine with that browser at the moment to confirm). I'll hold off on a final opinion until I see this working in all browsers. As an initial hurdle, any tool must either work or default to emulate the status quo appearance - any tool that hides data from users of certain browsers is a broken tool as far as I'm concerned, and should not be used. Once that issue is resolved, I'll give a more detailed opinion of its functioning. --- Barek (talk • contribs) - 11:10, 13 April 2007 (CDT)
 * can you test out the following script by putting inside your monobook.js file?

function sortableTables { if (getElementsByClassName(document, "table", "sortable").length != 0) { document.write(' '); } }
 * I'm not sure what the problem is in IE7, but IE6 worked fine on my computer. -PanSola 12:27, 13 April 2007 (CDT)

Idea 3: Splitting caster weapon types into different tables
Compare Perfect stat weapons (Domination Magic) with the status quo represented by Monk_unique_items_quick_reference.

Explaination
With the introduction of sorting, under the status quo the staves, wands, and foci will often get mixed up in a sort. However, with the original functional goal of these weapon quick references, that isn't the most desirable outcome. I might be looking for a wand/focus combo where the wand go by one criteria while the focus use a different criteria. With three campaigns worth of weapons, most weapon types have enough entries to justify having their own tables, making looking up weapons by a combination of properties easier.

Recognized issues

 * Some attributes, especially primary caster attributes, have REALLY FEW weapons associated with them. Splitting those tables by weapon type would result in tiny tables that some people might dislike.

Discussion of splitting caster weapon types into different tables
Holding judgement until resolution of sorting issue (see above). --- Barek (talk • contribs) - 11:10, 13 April 2007 (CDT)

Idea 4: -enhancing caster weapons
This isn't actually a new idea, but rather was the original design of all collector/green/crafter (caster) weapon quick references.

Compare the pre-Nightfall version of Monk_unique_items_quick_reference with the status quo Monk_unique_items_quick_reference

See also Mesmer perfect weapons for a compromise.

Explaination
For my Domination/Inspiration Mesmer build, if a wand/staff does not give me HCT Domination/Inspiration Magic 20%, HSR Domination/Inspiration Magic 20%, nor Domination/Inspiration Magic +1 20%, then I don't give a Lyssa's dime if it requires only 3 Domination Magic or 3 Inspiration Magic. And if it does give me the HSR/HCT/+1 combo in the attributes I am looking for, I also won't give a Lyssian dime whether it requires 9 Illusion Magic, 12 Fast Casting, or 16 Beast Mastery. Whether or not I meet the weapon requirement, the weapon is only going to deal 1 damage to the level 28 monster chewing up our monk anyways. When planning equipment for my caster build, I want through do the most with my spells, not wanding level 3 gargoyles in Old Ascalon.

And if I got 60 DP from some Deep Wound-spke-spamming mobs and need extra survivability, I will not hesitate in switching to Gorrel's Staff for that +60 health and reduce Deep Wound duration even if I have 0 points in Illusion Magic.

Arguably, the situation with Focus Items is difference, since requirements affect your max energy. Still, in general, as a caster I go between the extremes from trying to do the most with my spells (with HCT/HSR/+1) to compensating for DP plus surviving being a pressure/spike target. My equipment of choice in the two extremes share almost nothing in common, and the Monk_unique_items_quick_reference old Monk unique items quick reference illustrates the difference the excellently.

While it is possible to build this separation into the sorting criteria, I believe the difference is so great the utility of the quick reference is best served by completely separating them into different tables.

Recognized issues

 * Q: From the above logic, doesn't it seem to follow that all the caster weapons not enhancing any specific attribute be grouped into one single mega table? Why do the above samples not do that?
 * A: Indeed. The old Monk unique items quick reference was doing some sort of compromise by having the non-attribute-specific caster weapons separated by profession.  The current Mesmer perfect weapons take the compromise further, separating them by attributes.  But the idea situation is actually having one Quick Reference for caster weapons reducing Deep Wound (which may include weapons that do enhance specific attributes), one QR against Dazed, one against Poison, one for extra health, one for energy boost, etc etc, similar to how we have a .  However, because people keep messing with my original attribute-enhancing QRs, I've decided that, at least for attributes, compromise in the direction of Perfect stat weapons (Inspiration Magic) etc (and re-arrangeable into Mesmer perfect weapons).

Idea 5: Standardized row-format for all caster weapons & column-hiding
Compare Perfect stat weapons (Domination Magic) wikicode vs Perfect stat weapons (Blood Magic) wikicode.

Explaination
In the interest of reducing work or avoiding redundancy, information that is the same throughout a section or a page were often be omitted from the table, and summed up in a sentence in the legend or somewhere above the table. For example, all Necromancer primary weapons deal Dark damage, all Mesmer weapons enhancing the Domination Magic attribute require 9 Domination Magic and deal Chaos damage. However, if we were to make a certain quick reference list of caster weapons, some of which are Domination-enhancing weapons, some of which are Necromancer weapons, and some of which are Monk weapons, under the status quo we will not be able to just copy-paste rows from existing lists and paste them together. We would have to add the missing Damage Type and Req columns for all Domination-enhancing weapons etc.

I propose we make all the row format identical, at least among the caster weapons, whether it be staves, wands, or foci. The entries in the Mesmer perfect weapons all use this format, and if the other caster weapons also follow a uniform format (may not be the current one used by Mesmer, but as long as all caster weapons share the same format), then constructing new caster weapon QR lists will be very easy.

If you are using MSIE to view Mesmer perfect weapons, then you'll see the columns of redundant information, as well as empty narrow columns. However, if you use Firefox, Opera or any other browser supporting the CSS2 specification's "adjacent sibling selector", then you will not see the Damage Type columns at all, and certain other columns are hidden depending on what columns are unnecessary in the particular section.

Recognized issues

 * "It just looks absolutely HORRIBLE on IE!"
 * A: There are a few other alternatives:
 * Complain to MicroSoft and get them to follow the CSS2 specification of "adjacent sibling selector".
 * Stay with the status quo, with each weapon list having a different row format, which keeps creating new lists of known weapons tedious.
 * For every single cell entry that have a need to be hidden, mark it with class=coli (where "i" is the column number), then use CSS in the table header to hide the explicitly marked columns. Note that this approach takes O(n)+O(t) amount of work, where n is the total number of max-stat weapons (including unique, collector, and crafted) and t is the total number of quick reference lists.  The approach proposed by idea 5 above, in contrast, only takes O(t) amount of work (constant work for each table).
 * Use templates to separate data from formatting
 * Nest templates to avoid data redundancy and to keep the wiki code clean. This would be the equivalent of the approach currently used by Domination Magic skills and the like.  Note that you would need to be careful with different weapons sharing the same name, especially with crafted and collector weapons.  Additional benefit for this approach is, like the skills, only one place needs to be edited for each weapon's change, as opposed to trying to track down each and every weapon QR ever created and keep them all up-to-date (some of the existing weapon quick references are already awefully out of date).
 * Explicitly call templates on each usage. Copy entire template call when using the data to make new QR lists containing known weapons.  This approach would be the equivalent of the wiki code demonstrated in User:PanSola/t5.  For a new QR listing with different layout, the "qr" in teh wiki code is replaced by something else corresponding to the new layout.
 * I personally have no interest in any of the above 4 alternatives, though if you are interested, I can provide assistance in terms of how to technically implement the templates. If you have other alternatives not listed above, I am eager to hear them.