Originally Posted by DocSmith
I like Kevin Ames and his book, but it's hard to follow. If he would tell you why he is doing what he is doing, before just listing a series of unexplained keyboard shortcuts, it would make more sense.
I would add to your comments RFS's comments of there being bugs in the text. I am finding a few.
As you mentioned, it would be helpful to know in advance what you are trying to accomplish. The problem with the errors is that when you run into a rough spot, you don't know if you messed up or the author has messed up.
I've been sending Kevin Ames an errata chapter by chapter.
If I were his editor, I would go through each example and make sure it all hangs together. I'd also give a quick explanation of what I am trying to accomplish in advance of performing all the steps. Also, whenever there is a change in state, I'd give the new state. For example, say "eye" goes from on to off, instead of simply saying, "hit the eye on background", I would say " hit the eye on background to turn it off." And for long examples, say 30+ steps, I'd provide breakpoints where users could compare their work against the text (show layers/paths to compare) and the ability to save their work. If those changes were done, the book would be considerably better than it is.
As it is now, I am hitting a fair number of bugs and working through. Some bugs can be figured out with some thought. Some are just missing critical information where you need to skip over it.
Thank you for your comments.