Worst user guide ever

After 4 days of trying to make sense of this error-filled nightmare of a user guide, I’d like to officially nominate it as the worst software manual I’ve ever seen. No glossary, a mistake every other page (the Mac version), no explanation of when obscure functions would be useful, simply a horror-show.

If I ever learn to use this software, it’ll be a miracle.

what do you need help with?

As someone who tries to be helpful by writing articles and tutorials I can really appreciate the difficulties of organizing and communicating both artistic and technical information. I also know that one of the most important aids in improving my own communicating is receiving feedback from my readers both positive and negative. It is important to hear constructive thoughts so that I can do more of what my readers tell me they like and find helpful and to use their feedback to learn to avoid or change the things that they tell me are not helpful or confusing.

Members of this community are very good about recommending suggestions for new features and feature improvements for the software itself, but often far too quiet on the subject of the documentation. A few years ago there was a real void of tutorial materials for TBS, and community members voiced their concerns and made suggestions and there have been significant advancements in terms of available materials both from Toon Boom Animation and from individual volunteers like myself and Nolan and Will, just to name a few.

My point being that constructive suggestions lead to constructive changes and improvements. It is time to address the user guides and manuals. They do need significant improvements. So I respectfully am posting this call for community input. What do you like about the manuals? What parts are useful? What parts are confusing or unclear? What’s missing? How can we the users of the software help the team at Toon Boom Animation to better serve us their customers? Post your thoughts here. Its up to all of us as users to drive improvements. Thanks -JK

My apologies for not responding sooner, I’ve been out of the country on a production shoot.

First, far be it from me to claim any expertise on how to write a good user guide. Although I have participated in the creation of manuals for video games, where it’s also necessary to make clear concepts users have never come across before. And as a visiting professor/lecturer, I’ve needed to work on condensing ideas very familiar to me into nuggets folks new to the ideas could understand. I imagine creating good technical manuals is a difficult job, and take my hat off to those who do it well.

That said, I’ll offer some thoughts in an effort to be constructive and helpful, to be taken with whatever grains of salt you feel appropriate given my experience.

First, though brand new to animation, I’m very experienced and fairly successful in other fields that require the use of complex software.

So experience has taught me not to be one of those who says, “eh, who needs a stinkin’ manual, anyway, I’m sure I can figure it out.” I need to meet professional deadlines with high-quality product with such software, so I don’t have the time NOT to know how to use it as productively as possible.

So I’m willing to read things over and over a couple times, and “fight” with a manual. But within certain limits…

In that context, a couple thoughts:

First, when there are concepts that your software introduces that are either unique to it, or may be unobvious to those new to your field, such as “peg”, “element”, “exposure”, etc., have some sort of glossary in clear language (même en français si vous préférez - que je parle aussi) that unambiguously defines those terms, distingquishes one from the others that may be similar but different in key ways, (“element” vs. “drawing”. vs “exposure” “An ‘element’ is X. It means the following things. However, don’t confuse it with a ‘drawing’, which is similar in the following ways, but different in these other ways” ). I’d note that I think you did a great job in this regard with describing the things “scenes” have in common. Kudos there.

Second, have a variety of examples, from the real animation process, of when this tool or that function would be useful. For example, "animators will often try to save time by X. If they can do Y, then they don’t need to worry about Z. You can do something similar in Toon Boom is the following: Imagine you have A going on. But you really want B. The long-winded way to do this would be to C. But if you use D from the E menu, tweak F and G, then you can accomplish the same thing in 1/4 the time) I appreciate that is are some of this in the guide, and for that I’m grateful. But a) certainly not enough, b) rather cursorily done, c) often not useful for noobies like myself, d) rather cryptic language is used.

Third, CHECK FOR ACCURACY. There I am struggling to try to understand something you don’t describe well or thoroughly or with any examples. But when I try to follow your step-by-step directions to get a handle on it, it doesn’t even work because you’ve screwed up the shortcut keys for the Mac!!

Fourth, use redundancy. Explain tricky or new concepts in a couple (or more) different ways or from a couple (or more) angles, when appropriate. This shouldn’t be hard. Presumably you have folks on staff who actually use the software to animate with, and could just write up something reflecting their own experience and methods.

Fifth, change your point of view occasionally from the software to the user. For example, you’ll say something like “the A menu has the function B in it. The B has suboptions C and D and E. E will only work under condition F…” etc. Well, as often as feasible, come at it from the user’s point of view: , or “When you’re coloring, there are a few ways to do it. First you could use tool A. That will allow you to do B and C, but D will be tricky because of E and F. That’s why we provide tool G. When you find yourself wanting to color this way, use tool G because it’ll give you a better (whatever), or even tool H, which we specially designed for people who want to color in way J.” (I appreciate you try to do this sometimes, though I’d argue a) often unclearly, and b) not enough).

Sixth, run the manual through the QA process just like you do the software so you can anticipate user frustrations and get ahead of them: "You may find that when you’re doing X, Y doesn’t seem to work right anymore. That’s because you need to check of Z in the A menu…"

For now I have to get on a plane, so I can’t continue, or even edit this post, so my apologies for incongency and typo’s, etc. But I hope I’ve at least provided some inkling as the the sources of my frustration. And I hope to continue this discussion further as time allows.

By the way, thank you for taking this issue seriously. To me that says you’re probably a good company I may be able to partner with for the longer term despite by shorter-term frustrations.

Thanks, and bonne journée.





Hi,

I will forward this to our documentation team since their may be things in there we could adjust in upcoming documentation that are done.

Best regards,

Ugo

Actually, the adobe aftereffects manual is worse! The problem with the toonboom manuals, and many others, is that they fail to explain WHY you are doing things. They also skip over simple mechanical things, like in the photo-puppet workout series I’ve been struggling with, they break down a photo character into parts by duplicating the main photo, chopping it into bits and renaming the bits (a cumbersome process BTW) the video part shows you selecting the unwanted parts - then nothing! At no point does it explicitly say “press delete to get rid of unwanted parts” there are countless other examples like this, simple omissions that stop you dead in your tracks.