I have not voted for the node in either direction; I've not heard of this Black Book until now, but more importantely, the review tells me little about it that would influence my purchasing decisions.

A growing problem/trend of PM latety in the Review areas is the quality of the Reviews. Before I get too far, let me slap this up:

IMO!!

I believe that if you are going to review something here at PM, you should consider giving out as many details as possible about the book or module, positive or negative, that would help me decide whether to use the item in question. Simply stating "I found it useful" doesn't help at all.

Imaging if movie reviews were only listed by title and the number of stars that it was given; would that be helpful to determine what movie to go see? Definitely not, which is why most reviews give details such as the genre, the MPAA rating and any specific such as language or violence that earned it that rating, the actors and directors involved with it, the length of the movie, and maybe some 'preliminary' movies or material that you should be familiar with to fully enjoy the movie. Putting that all together, I now know if there's enough elements about the movie that I might want to see it.

The same ought to go for book or module reviews. For book reviews, I would find it very helpful to know things such as the size, cost, and hardback/softback-ness of the book, year and publisher, a table of contents (particularly any references/appendix material), the amount of background and advanced material in it, the number of illustrations in it, and the amount of sample code in it. Most of this is factual, and thus should have no bias. However, it can help to improve a review. EGs: "This book has about 6 of 10 chapters dedicated to reviewing the basics of perl. Obviously, this book is not meant for the advanced perl programmer...". "While the book has frequent illustrations, these tend to be too large and reduces the amount of usable content in the book..." (Note those are not real reviews of any books, just examples). If it comes with a CD, information on what's on that too is helpful.

Obviously, there's more on the 'personal' part of the review that's harder to distinguis. RhetTBull points out one aspect that I find helpful; stating what level the reviewer is and how helpful the book is too that level. Other aspects that should be considers is how readable it is (is it meant to be used as reference or can be taken on a plane or trip for casual reading?), quality of writing and code examples, organization of the book, how well the book met the reviews expectations, and other details that are going to vary depending on who reads it. Exactly what goes in here will all depend on what the book is and how the reviewer does it, but the more information a reviewer can give here, the better the review.

For module reviews, again IMO, I believe there's a lot of fixed unbiased details that can be included to help out, including installation needs of a module, the amount of documentation associated with it, example code present, etc. Particularly for modules, I find it very helpful to have code of the module in use hopefully created by the reviewer, but borrowing code from the module isn't a bad thing either. If a module claims to be simple, but requires 4 function calls to do something simple, it's not a very good module, and an example would show that. A module review should go through all the general class of methods and objects that a module can provide, and any features that might be unique to the system. If module reviews for 2 or more compariable systems are done properly , I should be able to read those reviews side by side without resorting to looking at the module itself to determine which one will suit my needs. (Of course, a reviewer may completely miss a lacking/broken feature that they never would encounter that's critical for someone else, but here on PM, that's easily resolved since reviews can have additional feedback and be modified after posting to fix it).

Again, this is all IMO, but I do believe that more in-depthness in reviews are needed here, at least to be more effective for my selection process. As of late, a lot of the reviews seem to be thin, and really have not helped me decide if I need a book or not. Of course, going by a review alone is poor, but when looking at filling a potental perl bookshelf or a module directory, a well-written review will at least help point me to good starting points.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.