5 Basic Rules on Typography

Written by Granny's Mettle


Whenever you get projects for designing graphics for different media materials, there are certain rules you need to know before venturing torepparttar complexities and elaborate world of graphic design.

One ofrepparttar 107163 elements considered in graphic design is typography. This is how you utilize and create your text to come out with a result that complements your images and design ofrepparttar 107164 whole media material, whether it's for print or web.

For typography, here are five ofrepparttar 107165 basic rules to follow (or to break, whichever suits your creativity atrepparttar 107166 moment):

Rule No. 1- DO NOT use allrepparttar 107167 fonts in one document.

Every designer has his or her own collection of fonts, which he or she uses for each design project. As one designer would say: "If you're a designer, it almost goes without saying that you own fonts- Lots of fonts."

Aside fromrepparttar 107168 existing fonts inrepparttar 107169 software program being used, most designers have their own lists that were added torepparttar 107170 already existing list. And because ofrepparttar 107171 availability of so many fonts, one may be tempted to use as many, if not all ofrepparttar 107172 fonts that he or she owns.

Always remember that simplicity is more attractive than disarray and confusion. When you start using many fonts in one document,repparttar 107173 message most often get lost inrepparttar 107174 jumble. In addition, too many fonts can distractrepparttar 107175 reader fromrepparttar 107176 original intent ofrepparttar 107177 design- to get a message across. Nevertheless, this doesn't mean that you have to be dull and boring by sticking torepparttar 107178 conventional "two-font rule", which states that you had to have one font for headings and another for text. So where'srepparttar 107179 creativity in that? Just make sure to have a reason why you want to deviate fromrepparttar 107180 rule and chose to userepparttar 107181 fonts.

Rule No. 2- "Serif type is easier torepparttar 107182 eyes than sans serif."

There's an old principle inrepparttar 107183 graphics world that goes "Serif type is easier to read becauserepparttar 107184 serifs draws your eye from character to character." Hence, sans serif type is oftentimes used for headings and short quantities of text.

Truth to tell, all fonts can be made readable (except, well, maybe for Wingdings) withrepparttar 107185 ideal design. With sans serif, although it needs more leading than serif type, it can give your documents a very modern look, and isrepparttar 107186 popular body text in Europe.

Successful Documentation Projects – Part 3 of 3 – ‘Writing’

Written by Glenn Murray


So you understand your user documentation project and you’ve specced it out. Now you’re ready to write. Here’s some tips to help you on your way. This article isn’t aboutrepparttar actual writing itself; it’s aboutrepparttar 107162 things which go along withrepparttar 107163 writing. (For information on writing online help, see www.divinewrite.com/helpfulhelp.htm.)

NOTE: This isrepparttar 107164 final article in a series of three outliningrepparttar 107165 key elements of a good user documentation process. (To readrepparttar 107166 first and second articles in this series, go to http://www.divinewrite.com/docoprocess1.htm and http://www.divinewrite.com/docoprocess2.htm.)

Indexing

Index keywords should be defined whilerepparttar 107167 topic is being written. At this time,repparttar 107168 subject matter is clear inrepparttar 107169 author’s mind, and they are very conversant with all ofrepparttar 107170 intricate details. Indexing duringrepparttar 107171 writing stage also means that your keywords are reviewed as part ofrepparttar 107172 draft process. Some authoring tools don’t really facilitate this kind of approach particularly well (e.g., some don’t allow multiple author access torepparttar 107173 files needed for indexing), but at leastrepparttar 107174 keywords should be listed atrepparttar 107175 end of each draft. (Depending onrepparttar 107176 authoring tool, this may actually be easier forrepparttar 107177 reviewers, anyway.) TIP: For further information on indexing, see The Art of Indexing (1994) by Bonura.

User documentation reviews

To ensure that your user documentation is technically correct and readable, you need to get it reviewed by an intelligent selection of people. For a software project, your review list should include a subject matter expert (generallyrepparttar 107178 programmer),repparttar 107179 software architect, perhapsrepparttar 107180 project manager, and another writer. The review requirements will vary with each draft, so your reviewers and review procedures should be documented in your work pracs.

Testing your user documentation

Testing can be performed at a number of levels:

•Each writer should test their own user documentation by following it to userepparttar 107181 product. But remember, this kind of testing isn’t very powerful, because there’s a tendency for writers to follow instructions as they think they’ve written them, not as they’ve actually written them. •The second level is forrepparttar 107182 testing to be performed by other writers… as part ofrepparttar 107183 peer review. •The third level is forrepparttar 107184 testing department to do formal testing onrepparttar 107185 user documentation. This type of testing doesn’t often happen, but it’s good to try to get it happening. •The fourth level is/should be conducted as part of Beta testing (see Managing Your Documentation Projects by Hackos (1994), pp.452-453).

No matter what level of testing you use, it should be designed to ensure thatrepparttar 107186 tasks documented are true torepparttar 107187 product, and that any online help functions correctly. Forrepparttar 107188 user documentation to pass testing, it needs to satisfyrepparttar 107189 goals you specified inrepparttar 107190 earlier stages ofrepparttar 107191 project.

Localising your user documentation

Although localisation is often considered a post-writing activity, it’s best to do it as part ofrepparttar 107192 writing stage. The exact timing may vary project to project, but a good rule of thumb is to getrepparttar 107193 translators working onrepparttar 107194 second drafts (but only if you’re not expecting many changes torepparttar 107195 draft). TIP: Most translators will probably prefer to work on a sizable piece of user documentation, rather than individual topics sent to them piece-meal, so you should wait ‘til you have something of a respectable size to send them – perhaps a whole subject area, as opposed to a single topic.

With localisation, you’re performing a balancing act. If you sendrepparttar 107196 user documentation torepparttar 107197 translators too soon, you’ll spend a lot of money on changes torepparttar 107198 translations. If you send it too late, it won’t be ready in time forrepparttar 107199 release ofrepparttar 107200 product.

Cont'd on page 2 ==>
 
ImproveHomeLife.com © 2005
Terms of Use