Forum > Random

Wiki Formatting

(1/4) > >>

Synric:
Hey everyone,

As some of you may have noticed, over the last few days I've kinda taken it upon myself to reformat the pages on the wiki. I'm not making any content deletions (for the most part, more on that later), I'm simply changing the presentation of the pages to be more standardized. As of writing this I am around 100 out of 427 DBC pages in.

Obviously I am not in sole control of the wiki, and a lot of people contribute to it. Therefor I'm writing this post to try and explain my thoughts behind my changes and, more importantly, to get feedback about what I could do better, other users thoughts, and anything else you may have to say about the wiki.

Tables of Contents
I've been adding a Table of Contents to each page in the DB section. I know this may seem superfluous on pages with one entry, but for most pages, to me at least, it's about quick and easy navigation, and for the pages with one entry it's about standardization and presentation.

DBC Information
Directly under the TOC I like to include any short information that would relate to the DBC regardless of the version. This is information such as when it was added or removed, and a short explanation of the function of the DBC if necessary.

Version Sections
One of my major problems with the wiki is the randomness of a specific builds information within a page. I've begun to rearrange into a new setup. It goes something like this: Expansion (Oldest first) - Build - Table/Struct. Specifically formatted as follows

==Version==
Version number and build number, i.e., 3.3.5.12340

===Type of information===
Depending on who wrote it it's either ===Struct=== or ===Table===. Sometimes we have both.

Addendum: On this note, this will probably be the most controversial statement to some people in this thread: I prefer both. The wiki, in my opinion, should not be able helping one type of person versus another. Programmers would prefer it in struct form, content developers probably prefer it in table form. I prefer to have both types of information, it takes nothing away from the page. I'm not a programmer, I'm a content developer, and it helps me far more to have the table for quick referencing. On the flip side, the guy who writes the tools my server uses is able to easily copy/paste the struct. Everyone has their way and need of presenting information. I say let the users decide how they need it, it really isn't about us.

Extraneous Information
I try to keep extraneous information at the bottom of the page. This type of information includes any information that explains the information contained above. Usually this is information like Flags and what they do. I try to separate them based on version, usually by placing some sort of stop notice between expansions. Whenever something is added that takes up a value in a previous list (for example, in Wrath only values 1-25 work, then in Cata add 26-30, but also go and add value #3) simply note it for that value.

Categories
There seems to have been some different ideas of how the category section at the bottom should be handled. It looks like the prevailing theory ended up being listing the DBC category, then the specific expansion DBC category we have information on that table for, and specific version category. So, we're going with that. The style I'm using is Expansion - Build, so for example a page with information for 3.3.5.12340 and 6.0.1.18179 looks like this:

Category: DBC | DBC WOTLK | 3.3.5.12340 | DBC WoD | 6.0.1.18179

Other Information
Schlumpf prefers DBC information added in a structure style, I add information in Table form. Each one serves  a purpose. Feel free to add either, only Schlumpf will judge ;)
This post is for discussion about my changes, your ideas, things we can do in the future, and anything about these changes. Thank you for reading.

Edit: Removed expansion headings. Back to just by version

schlumpf:
Please use __FORCETOC__ instead of __TOC__ to respect the wiki's layout and have it consistent across auto-toced and manually-toced pages.

There are templates for versioned sections, please use those. Especially for "extra information".

I don't like the multi-level versioning. Using the build as section only would be preferable to me. Also, I wouldn't add a section for struct and table.

I propose to drop build-specific categories and only use expansion based.

The goal should be to at one point automatically generate table and struct from the same description and compress descriptions as much as possible with conditionals so that information (comments, types, value ranges, …) are not duplicated and more important don't divert. This was the case a lot for M2 and M2/WotLK and is the case a lot of times on DB/ pages with multiple versions.

Synric:
1) Must have switched off __FORCETOC__ at some point. My bad.
2) Thanks for the note on the version boxes. I'll go ahead and start using those
3) I can change it up if anyone else has a problem with the expansion level heading. As far as struct/table labels I propose 3 options, it's up to yall
- Keep them as is
- Keep them, but hide from the ToC (I dunno why we'd do this, but hell its an option)
- Remove them. Up to yall, I'm cool with whatever.
As far as repeating comments I don't really see the harm in the tables. Comments don't create new lines therefor not using up more space, and would alleviate the need to jump around with the definitions. If a comment needs to take up subsantial space it really should be in the extra information sections, in my opinion.
4) I can see why, but I can also see why not. It's kinda nice in my opinion to be able to search by version... I guess I don't really care either way
5) No comment. Don't really follow what you're saying.

Edit: After looking at how a few look with and without the expansion headers, I'm just gonna go ahead and remove those.

Amaroth:
I wanted to do something similiar on my own, but I'm glad someone else, apparently more skilled than me started doing so instead ^^. Great to hear that you are working on this.

Gamh:
It's very nice of you to take the time to do this and discuss it!

Version Sections: agreed with Schlumpf, keep it simple and just precise the build it was taken from, or the expansion if we don't have that information. We should also avoid duplicate information with table + struct and stick with one. I tend to think structs just give the best layout for information (like int types give you explicit boundaries). If some people have trouble with reading structs, it's possible to write a short guide to the types commonly used in structs.

Categories: same, drop the build here, not useful enough to care and in some cases we aren't sure of the build anyway.

Navigation

[0] Message Index

[#] Next page