We just had a conversation with one of our moderators about quality of our reviews, and how it can be improved, and it became apparent that this problem should be fought from both three directions. So while our reviewers hone their rhetorical skills, I would like to ask, what are you as a reader expect from a review? Another interesting question: what are you as an author want to see in a review for your book? Do you have any specific ideas, besides "if the book was useful or not..." [ August 13, 2003: Message edited by: Mapraputa Is ]
I like reviews that are themselves interesting to read. So many are cut and dry discussions < yuck >. I want to know how indepth the subject matter is handled, and how much sample code is provided. I want to hear about the shortcomings of the book also. All books have something that could be improved.
"JavaRanch, where the deer and the Certified play" - David O'Meara
I would like to know whether an author sticks to coding conventions(!!!) and about what (how close to the subject) and how long are "introductoty" chapters: For ex. i am buying book about networkigng and there are two chapters on threads that are about 1/3 of entire book. I don't object these, but how relevant are examples in the introductory chapters to concept of the book? About coding conv.: some of the authors think they can mix up declarations and methods at their will because they are so clever. I suggest cut those short, period. As i understand some of the authors are working in companies with their own coding policies. When writing books they are better to go with sun's conv-s.
I enjoy reviews as a literary art form in their own right. I appreciate impressionistic descriptions much more than I do detailed chapter listings. "This book made me feel like..." or "I have a much better understanding of..." is more useful than "There are 100 pages on chicken plucking." I agree that I like to see the bad as well as the good; not only within a single book, but I like to see "bad" books reviewed as well as good ones; they serve as a reality check (if a reviewer always likes everything then a positive review doesn't mean much.)
I also like "impression" reviews. I don't need a rehash of the TOC (unless we're talking about a page long review, in which a summary of the TOC may be appropriate).* I do want to know how this book is different from the others. This can be done even if the reviewer doesn't know what the others are. Is this book for beginners? architects? What does it assume? Where does it focus and go into depth. What are its strengths weakenesses? For what type of person would you recommend this book (as opposed to another randomly selected book on this topic)?
*This assumes the TOC is obvious from the subject. For example, a book on EJBs will obviously have chapters on session beans, entity beans, etc. There's no need to state that. On the other hand, if there's a chapter on EJB-CORBA integration, that should be mentioned, because it's not obvious.