Pages

Saturday, March 12, 2011

Proper Design

Zak S has a post about bad (and good) graphic design, in the sense of proper layout and illustration designed to make a product usable, as opposed to pretty. I got this same lecture once from Kibo when were examining RPG books in (I think) Pandemonium; I agree completely.

It's one reason why I'm doing two Liber Zero documents. The one I'm trying to finish first, the summary document, is the compressed version of the core rules. If you've played D&D or a game very much like it before, you should be able to understand the summary document and not need anything else. Thus, this document will be the completely free part of the game, with generous licensing. The other document will be the longer version, with options and variants, and won't allow wholesale copying.

But in addition to separating the documents based on licensing, I plan on making a print version of the longer document with the summary version in the sidebars. Why? So you can flip through the booklet, looking at the margins, and quickly find the section you're looking for. So you can read the booklet in full the first time, but just read the summary when needed thereafter.

The other design decision I have already made is to put the cheat sheets (theoretically, everything you need to play, once you understand the rules) in the center of the saddle-stitch booklet, so that they are easy to find and even photocopy. Incidentally, when I get around to printing projects involving dice maps (like the attribute map,) I'll put those in the center of their respective booklets, too, as opposed to on the cover, which seems to be Zak's approach to his upcoming book. I haven't seen Zak's dice map, so maybe it doesn't require looking up things in the book; I figure I should make my own dice maps easy to photocopy, though, just in case someone wants to look up stuff without disturbing the position of the dice.

Naturally, not everything about design is so certain. For example, I worry that I use bullet lists too much. I can't help it: I prefer bullet lists that make information stand out, so that I can find stuff quickly (find the bullet list, look at each item for the bold word or phrase until you find the one you want, read that item.) Of course, I don't like bad bullet lists. I consider the D&D 3.0 PHB to have bad bullet lists in the class section, because it puts boring, stupid stuff you are only going to read once into the list, like "reasons why you might want to be a fighter". What you want, of course, is a summary version of what makes a fighter different: fighter abilities. That's why I use a pretty standard bullet list of class abilities for my Liber Blanc-style classes, like this one for the Sage class:
  • read ANY written magic item, including scrolls;
  • get an HD (or level-based) bonus when using written resources.
I could maybe add two or three lines about HD progression, XP progression, and saves, but that's it. It tells me everything I need to know about the class in one glance.

So yeah, good design is good. I hope to practice it as much as possible.

2 comments:

  1. I'm a technical author by trade, and the presentation of most RPG rule sets frankly appalls me! Bullet points are most certainly your friends, and I whole heartedly agree that you should only use them for information people will need more than once.

    Can I suggest you consider adopting a concention I use for software manuals:

    Bullet points ("*")for un-ordered lists, only.
    Numbered lists "(1", "2",..."n") for sequential instructions, only.
    A special bullet (">") for single step instructions.

    The idea is to be consistent throughout, so the reader never confuses a list for a set of instructions.

    The other thing: if there's a simple mathematical relationship between a character statistic and some derived number, consider giving that. Tables are great, but mentla arithmetic is often faster.

    ReplyDelete
  2. Good ideas!

    I know I've been lax, using bullets for some sequential steps, often because I'm splitting instructions across posts or into groups and Blogger is not so good about that... although I *could* open my Markdown-enabled edit window and write it all there, first, then copy the HTML code it generates...

    ReplyDelete