Revision as of 17:07, 6 May 2010

Some guidelines for writing MeeGo (well, any) kind of developer documentation.

Start from a known state

A guide should explain why it exists:

• What it will show you to do (build a PDF viewer, understand how DBus works)
• The intended audience (beginner, C programmer, web programmer)
• The vertical it's applicable for (will it only work for netbooks?)

A guide should start from a known state and explain to the reader what that state is. For example:

• A "getting started" tutorial should start from a clean install of an operating system.
• A tutorial about "advanced widget use" might build from a state reached in a previous tutorial. But you need to make that explicit: say, "You should do tutorial X before you start this tutorial".

Tell a story

Start with small pieces and join them into a significant whole. Make sure there's a progression (from nothing to something).

Only add a small amount at each step, and make sure what you add is one coherent thing: for example, implement a single feature or explain a single concept (that's tricky to work out...).

You could show a screenshot of the finished application and then say "here's how we got here". But don't start with a big pile of code and try to pick it apart and explain it. That's difficult for someone to grasp.

If you're writing about building a full application, add the features in a logical order the way a developer might do it, e.g.

1. Set up the project
2. Create the basic skeleton of the application
3. Add some read-only widgets
4. Add behaviour to the widgets but stub out interactions with other parts of the environment
5. Add interactions with the real environment (e.g. fetch data from the network, talk to device APIs)

Make sure there is a reason for adding each new feature. Adding spurious, unrealistic, disjointed (but maybe cool) features doesn't make a good story.

You could also use "characters" and put them in scenarios which mirror development in the real world. For example:

• A developer is being asked by a customer to add new features to an application.
• A tester and developer are working together on testing an application.
• A developer is writing an application for his girlfriend.

The O'Reilly Head First books are a good example of how to do this well

Use action-based structures

???

For example:

• "Configuring the application" rather than "Application configuration"
• "Writing a depth-first parser" rather than "Depth-first parser construction"
• "Adding a label widget" rather than "Label widgets"

This means someone knows what they're going to achieve by the end of the section, and has an idea of the scope of the information in that section.

Explain too much, rather than too little

???

Try not to make too many assumptions about the reader

Compare the new with the familiar

???

Provide useful, relevant, meaningful code samples

Code examples should be:

• Included in the MeeGo code examples repository: ???no URL yet??? This makes it easier for other people to get at them, fix them, extend and improve them.
• Self-contained (as far as possible): you should be able to compile them without needing loads of tools, or use them straight away inside an IDE like Qt Creator. If this isn't impossible, they should include an INSTALL file (or at least README comments) explaining how to build them, distributed with the code (see above).
• Meaningful: they should provide a solution for some possible issue. For example, if you're explaining how to use widgets, write an application which demonstrates how to use them in context, e.g. an address book.
• Available under a liberal open source licence. I suggest BSD.

Some open problems:

• How to include source code in guides. I tend to cut and paste as I go, but maybe there's a better way.

Don't get sidetracked

???