The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
So at the place I work I have been handed the task of writing the manual for a 3d modelling program that our team wrote. The boss wants a short 15 page guide.
Basically what I want is, if you would be so kind, is to link me to any manuals that you've read that made you think "wow, what a good layout, and what ease to find information that is relevant to me".
Here at work we use a program called 'help and manual' though the license might be steep. It makes writing manuals kind of boilerplate, which makes it easy for people to follow.
Depending on the program you might want to divide the manual into three parts; overview, step-by-step introduction, and reference. To cover all that in 15 pages might prove difficult.
Big question: what kind of user is the manual aimed at?
L*2*G*X on
0
MichaelLCIn what furnace was thy brain?ChicagoRegistered Userregular
edited March 2009
15 pages is more of a quick-reference than a manual, at least that's what I think when I hear, "3d modelling program."
What's the audience? Is it end-users? Do they have general computing knowledge? Is it going to be a training manual, or more of a technical reference?
I would say this is an example of a bad manual, there's no clear section beaks, and the heirarchy is not consistant: Garmin Manual.
The program is an interface for a 3d printer, and the users would be people who have some experience making 3D models and would now like to use them in a 3d printer. However we are trying to reach users who may have felt daunted before. So I guess the answer is moderately computer literate people.
I think they want it to be more of a reference type thing, though I am thinking of doing a 3-part approach.
Is this a bit like what the reprap people are doing? I was thinking about writing a manual for their software once, as a way of learning to use it myself, but that never really got out of the starting blocks.
Anyways, I've found they have just bargeloads of documentation that doesn't really tie together, since they use so many different software packages. Perhaps this can be of use to you.
In general though I fear 15 pages will be far from sufficient. Perhaps you could start with the interface and visualisation tools, then cover import and mesh debugging functions in a step by step way.
Don't stray into modeling territory though...
Posts
Depending on the program you might want to divide the manual into three parts; overview, step-by-step introduction, and reference. To cover all that in 15 pages might prove difficult.
Big question: what kind of user is the manual aimed at?
What's the audience? Is it end-users? Do they have general computing knowledge? Is it going to be a training manual, or more of a technical reference?
I would say this is an example of a bad manual, there's no clear section beaks, and the heirarchy is not consistant: Garmin Manual.
I think they want it to be more of a reference type thing, though I am thinking of doing a 3-part approach.
https://medium.com/@alascii
Anyways, I've found they have just bargeloads of documentation that doesn't really tie together, since they use so many different software packages. Perhaps this can be of use to you.
In general though I fear 15 pages will be far from sufficient. Perhaps you could start with the interface and visualisation tools, then cover import and mesh debugging functions in a step by step way.
Don't stray into modeling territory though...