Guide writing guidelines

It feels kinda weird to write a guide on how to write guides, but to ensure that submissions have the best possible chance to be published, and to limit work on my end, I feel it is a necessity.

So, you're planning to write a guide to be published on Doom9. What should you consider:

• Don't reinvent the wheel. There are plenty of existing guides published on this site, and it makes no sense to explain the same thing over and over again, just in different words. Rather, try to base your work upon existing documents, and just write the part that is really new. If integrating the new parts into an existing guides causes problems (because the existing document does not have enough information or too much), get in touch with us - it is always possible to change existing documents.
  If you have an idea of a guide extension, you shouldn't write a whole guide, rather get in touch with us first, maybe we can integrate your idea into existing guides without writing any new documents at all.
• Use a real HTML editor. Word's HTML export is poor (and that's a compliment). Good, yet easy to use HTML editors that do not require you to learn HTML coding, are Dreamweaver or Frontpage (the 2003 release preferably, older versions are worse).
• Chose the proper screenshot format: GIF is appropriate for most screenshots, unless you need to show a live picture (something from a movie), in which case jpeg is most appropriate. Make sure there are no visible artifacts in the shots (especially important if you make a jpeg that shows both a live picture and computer generated elements (program windows)).
  
  Modern programs sometimes have a Windows XP skin. Taking a GIF screenshot of such a program will result in visible artifacts:
  
  
  
  In such a case, use the PNG format (and don't forget to set the output format back to GIF for subsequent shots).
  
  Furthermore, you don't have to show the entire window sometime. Take a look at this example:
  
  
  
  This screenshot is too large. There is so much information that you need pages to describe all the options shown on this screen. Rather, try to split up a large screen into different elements. For instance, the Duration section shown in this screen, or the Total Size section (which has been shown already once in the first screenshot on this page). Also, NEVER include the window border (the blue part around each window). This just wastes screen space and creates more traffic than necessary. People don't need to see the Gordian Knot 0.28.8 (gordianknot.sourceforge.net) line, they know they're in Gordian Knot. Most of the time you can also do without the tabs. Just mention that it's time to go to a certain tab, and that's it.
  
  If you have to show a rather large image, be careful when resizing it. The following example is horrible as you cannot read the text properly anymore. This is clearly a situation where the screenshot should be divided into various elements. A possible way to split up the screen into different screenshots can be seen in the GordianKnot guide.
  
  
  
  Last but not least, images have to be placed at the proper place: Here's the basic structure this website has, all relative to http://www.doom9.org/
  
  / - generic site related documents and everything that is AVI/DivX related
  /images - images that belong to the HTML documents in the abovementioned directory
  /mpg - everything that is MPEG-1/2 related: VCD, SVCD, DVD±R/W
  /mpg/images - images that belong to the HTML documents in the abovementioned directory
  /DigiTV - everything that belongs to DVB / HDTV capturing
  /DigiTV/images - images that belong to the HTML documents in the abovementioned directory
  
  Both images directories contain subdirectories for the various programs. There's a subdirectory for each program that has more than a handful of screenshots. If you're dealing with a new program, don't be shy to create a new directory.
  
  Use names that reflect the contents of a screenshot. You might be able to tell what shot1.gif, shot2.gif, etc. mean while writing the document, but 3 months later you'll certainly not remember. But if you pick names that reflect on the contents (as an example: the first image used on this document could have a name like gknot-bitrate-sizes.gif, which clearly identifies that image as belonging to GKnot, being part of the bitrate tab and containing filesize settings).
  
  So let's recapitulate: GIF for computer generated material, JPEG for live material, PNG if GIF has artifacts. Split up images, and try to use as little resizing and possible. Put the images in a path compatible with the current structure and use names that allow you to easily identify the images.
  
  A good tool to make screenshots of areas of a window without a lot of extra work is Hypersnap DX, or a freeware alternative: MWSnap.
• External links should open in a new window. This site uses frames, so a link to another page would usually open in the same frameset. This is considered to be rude and could potentially even lead to lawsuits.
• Use relative links to all content available on-site. It makes no sense to link a document that's on the same server using an absolute URL (for instance http://www.doom9.org/autogk.htm). Rather, a relative link (autogk.htm) will do just fine. The same also applies to the software archive
• Use the Doom9 stylesheet (http://www.doom9.org/doom9.css). This allows for a consistent look of all documents.
• Use the same presentation elements: Start with a bold title (same font size as the regular text), then a small introduction, then a list of software required, then the guide divided into steps, all starting with a bold headline. Buttons to be pressed, menu options and other elements that can be seen on screenshots should be written in italics.
  Of course, if you're writing a document that is to be integrated into an existing guide, you don't need the introduction and list of software, and should number your steps to be consistent with the entire guide once it has been integrated.