#RTFM and WTFM How to write a fine modeling manual worth reading (ideas)

#RTFM and WTFM How to write a fine modeling manual worth reading (ideas) Note: The following is copied in part from this blog https://opensource.com/business/15/5/write-better-docs

Crafting a comprehensive and engaging modeling manual is no small feat. 📚🚀 It's about striking the right balance between depth and accessibility, ensuring that both newcomers and seasoned experts can find value in your documentation. Let's add a splash of emojis to illustrate the various types of documents you can create to guide users effectively:

📍 Start Here 🌟: Your "Getting Started" section is the launchpad for users. It's where they'll find all the prerequisites, installation steps, and initial configuration advice to get the ball rolling. Think of it as the grand entrance to your manual, where users are warmly welcomed and directed to the starting line.

🔍 Reference Guide 📖: This is the encyclopedia of your documentation - comprehensive, detailed, and matter-of-fact. 🧐 Here, users will find meticulously detailed descriptions, definitions of terms, and the nitty-gritty of functions and commands. It's factual, straight to the point, and usually void of any fluff.

🛤️ Tutorials 👩‍🏫: Imagine holding someone's hand and walking them through a process - that's what your tutorials are for. They are friendly, engaging, and patient, explaining steps one by one and providing context where needed. It's where the voice of the manual comes through, speaking directly to the user in a helpful and conversational tone.

🤔 Learning/Understanding 🎓: These documents go beyond the "what" and into the "why" and "how." They provide insights into the decision-making process, delve into implementation details, and offer a glimpse into the future of the technology. They're the think-pieces that can inspire and inform those looking to understand the system on a deeper level.

🍳 Cookbook/Recipe 📋: Just like a kitchen cookbook, this section provides ready-to-use solutions - the best practices for common problems. Users can expect to copy-paste these 'recipes' and have them work out of the box. They are the quick fixes, the life hacks of your manual, but it's essential that they also advocate for best practices, not just quick fixes.

🛠️ Error Messages 💡: Good error messages are the unsung heroes of documentation. They're the helpful signposts that tell users what went wrong and how to fix it, saving them from potential hours of frustration. They should be clear, constructive, and, if possible, point the user towards a solution.

By addressing each of these facets with care and thoroughness, you'll create a manual that's not just a dry collection of instructions, but a helpful, engaging resource that users will actually want to read and consult. 🌈✨

#RTFM and WTFM How to write a fine modeling manual worth reading (ideas)

Note:  The following is copied in part from this blog

https://opensource.com/business/15/5/write-better-docs

It is a wish list for me at least..

Types of docs

Once you've determined the scope, and who you're writing to, there are several different kinds of documents that you can write for them. Anne Gentle categorizes them like this:

Start here

Like the Getting Started document I mentioned previously, this is the place where you tell users what they need to know before they even get started.

Reference guide

The reference guide is comprehensive and usually pretty dry. This is where terms are defined, functions' input and output are explained, and examples are given. The tone is factual and to the point. There's not much discussion, or conversation. The voice is usually impersonal.

Tutorials

Tutorials hold your hand and lead you down the path. They show you each step, and occasionally sit down on a bench by the path to explain the rationale for a particular step. They are very conversational, sometimes even chatty. The voice is personal; you are speaking to a particular person, defined in the earlier persona phase.

Learning/understanding

Often linked to from the tutorials, the learning/understanding documents dig deeper. They investigate the why and the how of a particular thing. Why was a certain decision made? How was it implemented in the code? What does the future look like for this thing? How can you help create that future? These documents are sometimes better done as blog posts than as part of the formal documentation, as they can be a serious distraction to people that are just trying to solve a problem.

Cookbook/recipe

There's a reason that the Cookbooks are often the best selling part of the O'Reilly technical book catalog. People want solutions, and they want them now. The recipe, or cookbook section of your document, should provide cut-and-paste best-practice solutions to common problems. They should be accompanied by an explanation, but you should understand that most of the cookbook users will cut and paste the solution, and that'll be the end of it for them.

A large part of your audience only cares about solving their immediate problem, because that's all they're getting paid to do, and you need to understand that this is a perfectly legitimate need. When you assemble your new Ikea desk, you don't care why a particular screw size was selected, you just want the instructions, and you expect them to work.

So it's critical that examples have been tested. No matter how trivial an example is, you must test it and make sure it does the expected thing. Many frustrating hours have been spent trying to figure out why an example in the docs doesn't work, when a few minutes of testing would have revealed that a colon should have been a semicolon.

Recipes should also promote the best practice, not merely the simplest or fastest solution. And never tell them how not to do it, because they'll just cut and paste that, and then be in a worse fix than when they started.

One of my favorite websites is There, I Fixed It, which showcases the ingenuity of people who solve problems without giving much thought to the possible ramifications of their solution—they just want to solve the problem.

Error messages

Yes, error messages are documentation, too. Helpful error messages that actually point to the solution save countless hours of hunting and frustration.