Revision as of 16:57, 6 May 2010 (view source) Elliot (Talk | contribs) (→Explain too much, rather than too little) ← Older edit		Revision as of 17:02, 6 May 2010 (view source) Elliot (Talk | contribs) (→Tell a story) Newer edit →
Line 16:		Line 16:
	= Tell a story =		= Tell a story =
-	???	+	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.
		+
		+	# Set up the project
		+	# Create the basic skeleton of the application
		+	# Add some read-only widgets
		+	# Add behaviour to the widgets but stub out interactions with other parts of the environment
		+	# Add interactions with the real environment (e.g. fetch data from the network, talk to device APIs)
		+
		+	Start with small pieces and join them into a significant whole.
		+
		+	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
	= Explain too much, rather than too little =		= Explain too much, rather than too little =

---

Revision as of 17:02, 6 May 2010

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

Contents 1 Start from a known state 2 Tell a story 3 Explain too much, rather than too little 4 Compare the new with the familiar 5 Provide useful, relevant, meaningful code samples 6 Don't get sidetracked

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

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)

Start with small pieces and join them into a significant whole.

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

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

???