Talk:Druid (Evaluational Base Class Layout)/Overview

From D&D Wiki

Jump to: navigation, search

This sample layout is based on the newer format WotC is using their more recent source books. I started with that and made changes from there:

  • Everything before "Alignment" (except, of course, the header with the class name), the section "Playing a Druid," and everything after it would be largely optional for user classes. And with the SRD classes, they'll be omitted along with the starting gold for the non-psionic classes. (For whatever reason starting wealth is OGC for the psionic classes, but not for the core classes.)
  • The new format no longer has the key ability listed next to each class skill. I think it's still useful to have the key ability listed so I've demoed the layout with them back in.
  • Also with the class skills I replaced the colon with a <br/> to avoid crowding.
  • All other instances of "header:" were made into L5 headers. The reason for this is to satisfy the anchored subsection request for the SRD, and if it's going to be done for the SRD classes, it should be done for the user classes, too. See revision.
  • Epic class progression has been included.
  • This is only a sample for base classes. Other class types are to come. (Although sans the epic progression, this layout could apply to NPC classes.)

Sledged (talk) 14:49, 18 March 2007 (MDT)

I have a couple problems with this, and I hope as a community we can iron these out. First off the table of Contents is so big it it worthless - I say make the Class Features not be L5 headers however make them use span id's. Span id's work just as well and will not show up on the Table on Contents. Also, they can be on the same line as the beginning of the class feature. Another thing I do not like is how under all the headers (made by ;) come before the material. I think it looks better and is more in-line with how WotC does their classes when the Class Features and headers are on the same line as their material. Also, I think the class should start with a L1 header instead of the L2 header you have (even though wikipedia says it is bad to start things with L1 headers). All the other L's would need to be moved up one if we decide to make the first header a L1. --Green Dragon 22:32, 18 March 2007 (MDT)
  • Blank sections should be removed. There is no material to put into them. I am extremely hesitant to add original material into the SRD.
MediaWiki’s template allow for a empty entry to be ignored. I know that templates are traditionally used for boxes, but, technically speaking, nothing prevents them to be used as full pages.
David Latapie ( | @) 16:55, 21 March 2007 (MDT)
  • Class Features and similar L4's should be L3's. The headings need a larger point size difference. This helps a skimming reader know when they are crossing section boundaries.
  • For headers, I agree with green dragon. Experience on the wiki shows me that the L1/L3/L5 hierarchy looks best.
  • EPIC should be a L2 header, along with other MAJOR subsections (such as a paladin's steed). The reader needs to intuitively know that they are crossing an idea boundary.
  • The main thing to keep in mind is: when a reader comes to reference the class, how quickly can they locate their desired section through the TOC and through skimming the material?
At this point, I think that the PHB material is so archaic, with so much flavor text missing, that aside from tweaking the heading and the class table, that going this direction is a great deal of effort for very little reward.
Is there a way to turn on text wrapping around the TOC?
I am suspicious about the SPAN tags being used in the user classes. The base classes need these tags because those abilities are frequently referenced throughout the wiki. I do not see the same happening for user base classes. --Dmilewski 07:08, 19 March 2007 (MDT)
With the blank sections, as I said above, those sections will not be present with the SRD classes, so no non-OGC in the SRD. Also, I think it should go without saying that, with the user classes, any optional sections that are empty would be deleted. My purpose for putting those in is to (A) show what sections exist in the WotC source books and how they're laid out, and (B) if a user wants to fill in all that additional info for their user class, they'll have a format by which to go that follows WotC's style.
Changing the L4s to L3s is in line with Green's suggestion to knock up the L2 to L1 (see above), and my comment on it (see below). It would eliminate the L4s, and would have the major sections you mentioned (Epic progression, special mount, familiar, animal companion, etc.) changed to L2s.
I don't know of any way to make the text wrap around the ToC, short of hacking the core mediawiki code. —Sledged (talk) 11:09, 19 March 2007 (MDT)
I take that back. The CSS can be modified, but that will affect every page. —Sledged (talk) 09:53, 20 March 2007 (MDT)
I have an intense distaste for how the class feature names are on the same line as the description. When you have five or more of those, it's a little difficult to read, and looks very crowded. Dmilewski once mentioned that layouts in the sourcebooks tend to be partially governed by a need to save space. "We don't have that problem on a wiki, so there's little payoff for saving space." (see the Character Template discussion in my archives.) I'm for going against the WotC format when it increases readability. Also, the L5s weren't made with the semi-colon (;), they were made with using ====='s. However if semi-colons were used instead, they wouldn't show up in the ToC, but then they would need the span id tags.
For the title, I used an L2 to correspond with the headers used in WotC sourcebooks. The following is a breakout of how wiki headers correspond to the sections in the source books:
  • L1 for chapter titles (which is why this layout doesn't have any L1s).
  • L2 for major sections within chapters. In the source books, these are the headers that are in the largest font within chapters, are in all caps, and are underlined. Each class description starts with this header.
  • L3 for sub sections. The headers in all caps without underlining in the source books. They use a smaller font than the major sections. Each skill and each feat use this header.
  • L4 for the next level. These are a smaller font than the subsection headers in the source books (L3s), and they usually have the first letter of each word capitalized instead of using all caps.
  • L5 for most class features, creature special abilities, and other info at that same level. Unlike all the higher-level headers, in the source books these appear on the same line as the descriptive text (separated by a colon), are the same font size as the descriptive text, and are bold.
  • L6 for the lowest level. In the source books, these are like the L5s, except instead of being bold, they're italicized.
I don't see a problem with changing the L2 to L1. Since each class has its own page, users aren't going to see the wiki's counterpart to chapter titles and chapter sections on the same page. However, I suggest bumping up the L3s and L4s, too, but not the L5s and L6s. As Dmilewski mentioned the font size of L4s are very close to the L5s, but the difference in font size between L3s and L5s is much more noticable. —Sledged (talk) 11:09, 19 March 2007 (MDT)
Continuing on the L3 and L4 line of reasoning; because of the similarity, no page should have both L3s and L4s (not just the class layouts). They should either have one or the other. Why not just modify the CSS so that the L3s and L4s are different enough to stand out when scanning a page? —Sledged (talk) 09:53, 20 March 2007 (MDT)
Changing the CSS is for another discussion, right now I think we should focus on how to make this look very good. I see only three problems we are running into.
  1. Whether or not to use span id's or small headers
  2. Whether or not to have the title of the ability on the same line as the text.
  3. What header structure to use.
Personally I think span id's work the same and they make the ToC much cleaner. I vote for span id's. Also, for some odd reason, I think abilities all on same line looks better and cleaner. I put my vote for abilities to be all on same line. Finally, I am not really sure of all the header choices so I have yet to place my vote. BTW, should this discussion be linked to from the news? --Green Dragon 22:31, 20 March 2007 (MDT)
Sure let's put it in the news. —Sledged (talk) 10:13, 21 March 2007 (MDT)

Quite a solid block of text up there. As I've only skimmed it, I'll put in a few opinions before voting below.

1. What, exactly, is the advantage of the span tags? Armond 11:42, 21 March 2007 (MDT)

Span tags can be linked from anywhere on the wiki to the certain ability and also from the table above to the abiliy below. Overall it makes faster finding of abilities for users. --Green Dragon 17:09, 21 March 2007 (MDT)

2. Why use span tags when you can simply use the format of "Class Feature (Ex): Description"? I've used that on an assassin base class I'm making, and it looks pretty neat except for the sudden BLUENESS of the wiki link, though I bet I could fix that if I went deep enough into HTML. Rethought this in no. 7. Armond 11:42, 21 March 2007 (MDT)

Span tags are for anchoring withing a page so others can link directly to that section of the page. In fact the current Druid layout in the SRD has all the class features wrapped around span tags. With them I can link directly to the wild shape class feature (instead of the top of the page). This is mostly for the SRD classes, since they (and their class features) tend to be referenced more often than the user classes. For user classes, it will probably be optional. Span tags have absolutely no visual effect by themselves. Unlike the wiki headers, they won't show up in the ToC. —Sledged (talk) 12:15, 21 March 2007 (MDT)
That actually sounds useful. Do you do that with those links that look like [[#Class Feature]]? Armond 11:42, 21 March 2007 (MDT)
Yes, the class features in Table: The Druid link to the discriptions further down on the page, and in fact Table: The Druid has an anchor as well. —Sledged (talk) 14:00, 21 March 2007 (MDT)
I think that span id's should also be put into use on user classes. If they are on user classes the table above can link directly to the ability below. See some of Cúthalion's classes to see if you like it — I think it is a worthwhile thing to add. --Green Dragon 17:09, 21 March 2007 (MDT)
I've started using it on the base assassin class I've been working on (link on my user page), it's working wonderfully. I dunno how I got along without it :P Armond 08:42, 22 March 2007 (MDT)

3. Whatever we decide to do, we can't have the ToC as huge as it is here. It's effectively unuseable; the reader should never have to scroll down almost three pages before getting to the first header. Armond 11:42, 21 March 2007 (MDT)

How about now? —Sledged (talk) 12:15, 21 March 2007 (MDT)
Better, still a tad long - perhaps reduce "Druids in the World" to one section on the ToC? Then again, this is a rather large article, so... I'll leave it up to the rest of the community. Armond 11:42, 21 March 2007 (MDT)

4. The reader will never care about linking to things as specific as the DCs of his Druid Lore. I would recommend keeping all the 1.x headers, but generally nothing under that (exceptions being major points of major sections, such as Animal Companion --> Animal Companion Basics & Advanced Animal Companions Armond 11:42, 21 March 2007 (MDT)

5. Class Features should be its own 1.x heading - it's certainly important enough to have the heading, and the link to it is usually the most important link on the page. Armond 11:42, 21 March 2007 (MDT)

6. There are an absolute CRAPLOAD of links to the same places, most noticeably the links to the six abilities. This would be ok within the skills lists and the occasional link within class feature descriptions, but do we really need a link to Int just above all the class features? Armond 11:42, 21 March 2007 (MDT)

7. Expounding on no. 2 and 6, the feature names should not be blue. The best way to do this is to just not make links in the feature names, but then where do we make links to Ex, Sp, and Su? Armond 11:42, 21 March 2007 (MDT)

I'll vote after I see answers to my opinions, or something... Armond 11:42, 21 March 2007 (MDT)

Home of user-generated,
homebrew pages!
system ref. documents

admin area
Terms and Conditions for Non-Human Visitors