I'm a reader as well as a writer, and a reader who writes reader-type reviews on my own blog. So I thought for my first guest spot I'd drag out a post I wrote last year about what I think a review should be... It's quite a long one, so I'll put up the first section and then give a link to the rest.
The job of the reviewer isn't to say whether she liked or disliked the book...
We've all seen them on Amazon. The one line reviews that say "This book sucked!" or "This book is great!". They're not very helpful, and one of the reasons they're not very helpful is that they don't tell you why the book sucked or was great. You have no way of knowing whether that person's tastes match yours, and hence whether you can trust their opinion to reflect what you'd think of the book.
The job of the reviewer isn't to say whether she liked or disliked the book--or indeed to say whether the book was good or bad, for it is quite possible to like a bad book and dislike a good book. Ideally, what the reviewer should be doing is providing information that helps other people to decide whether or not a book would be of interest to them. That the reviewer liked/disliked the book is important, but the reason why is more important. If I read a review by someone who disliked a book, but who takes the time to explain what she disliked about it, I may well find that her reasons would be good reasons for me to buy it, and vice versa. We may simply have different tastes; or the book may target a specific audience and be of no interest to those outside that audience. A good reviewer recognises those possibilities, instead of assuming that everyone is looking for the same things in a book.
I have a very specific example in mind. A few days ago as I write this, I was wondering whether it would be worth buying an updated version of an O'Reilly manual. (For those who don't know, O'Reilly publish a much-respected line of IT technical reference books.) The one I'm using is the 1998 edition, and as such dates from the Stone Age in computer terms. It's still useable, but I thought that I should look at whether it was worth buying a newer edition.
It turned out that there were not one but two books that I might want to look at, so I settled down to read the reviews. It rapidly became clear that the technical people didn't think much of one of the books. Too basic, too much repetition of things that were obvious, the author hadn't written the book that they wanted. Most of them were content to slam the book as unworthy of the O'Reilly name. Most of them saw it only as a book that had failed practicing geeks.
The beginners, on the other hand, loved the book. It was pitched to their level, and they appreciated it. That was fine, because that was the sort of book I was looking for. But because they were beginners, I couldn't trust their judgement of whether the book was technically accurate.
And then there were a couple of technical guys who said very bluntly that the book was a failure as far as they were concerned -- but who also recognised that ubergeeks were not the only potential audience for the book. Those guys took the trouble to explain why they thought the usual audience for O'Reilly books would find the book a poor buy, while at the same time it was probably a very good book for people who were just starting. They felt that it was at a very basic level and very repetitious, but it was clearly written, accurate and reliable in what it did cover. It was a beginner's tutorial rather than a reference guide, and it did it very well. And they said this without being condescending to people at a basic level.
Those are the reviews that got a "helpful" rating from me. They gave me the information that enabled me to decide whether the book would be useful to me, instead of assuming that if they didn't like it, nobody should.