By Nicholas Zakas CHAPTER 2That’s why no piece of software should be considered complete with-
out accompanying documentation. Writing good documentation isn’t
hard, it’s just a matter of transferring your thoughts into text and images.
Depending on the type of software you’re building, it may make sense to
structure your documentation in different ways. However, there are some
common approaches to documentation that everyone should be aware of.
getting Started
A quick start guide describes how to get up and running. This is the
traditional “Hello world” example that many libraries have. A good quick
start guide describes how to obtain and set up the library, and how to start
using the functionality immediately. Twitter Bootstrap has a great getting
started guide^12.
Tutorials
There are common use cases that library users frequently need and so it’s
important to show them how to complete those tasks. The tutorials should
be in narrative form, describing each step of the process and resulting in
a functional prototype at the end. jQuery has a large amount of tutorials^13
that are very well written.
aPi Documentation
If you offer an API for others to use, then API documentation is very im-
portant. This describes every public interface of the API in very fine detail,
including the names of functions, the types of arguments the functions
expect, return values, available classes, and more. The YUI library has an
excellent and fully searchable set of API documentation^14.
12 http://twitter.github.io/bootstrap/getting-started.html
13 http://docs.jquery.com/Tutorials
14 http://yuilibrary.com/yui/docs/api/