Reviews & Beta Reports First things first : reviews and beta reports are NOT the same thing. Reviews should be designed to inform people about what they can expect from a track before they download. Beta reports should be designed to help a track maker refine and improve his/her track. People participating in this process should remember the distinction. I am writing this page because recently a couple of people had trouble understanding these concepts, problems dealing with constructive observations, and, after all had been said and done, asked for help but didn't really want to hear the truth. Now, I am all in favor of being tactful and considerate of a track maker's feelings, but I also believe that if a track maker is not prepared to receive the responses he or she gets - the good and the bad - then perhaps it would be best not to ask for opinions to begin with.
A good review should : Try and keep the same look and feel with several reviewers. Keep in mind the purpose of a review is to give the downloaders an idea what the track is like before they download it, not to criticize the author. Especially new track makers. Different people like different things from a track. Point out the good with the bad, but get the essential information in at the top of the review, like setting, layout, etc. You can go on to point out special details you did or didn't like, but don't get too carried away. Remember, the reviews are for the downloaders, not the track makers. Concerning the 1-10 rating scale, be thoughtful of the track makers feelings. Few tracks deserve a 1 or 2. Most tracks should fall into the 4-8 range. Reserve the 9 and 10 ratings for exceptional work. If there are errors in a track or it simply does not work, either don't review it or e-mail the author and ask permission before you post. Triple check your review for spelling errors and accuracy.
A good beta report should : Look for flaws in the track. This should include any and all technical, functional, or visual problems that you find. And, don't forget to test specific areas the track maker points out to you. Make an assessment of the track as a whole. Yes, whether or not you like a track is important, but this kind of assessment is not restricted to personal preferences and should extend to include things like derivability, texture usage, consistency of motifs (if any), etc. Think of possible ideas. These may include anything from nifty little touches to major reworkings to something the tracker hadn't even imagined. Don't be afraid to be too obvious or too detailed. Give a summery of your assessment. This is not the same as your initial assessment. Rather think of it in terms of the 1-10 rating system. Give your idea and then go into some detail why you believe it deserves the ranking you've assigned to it.
Case study : a review Anyone can say "good" things about a "good" track. There is no art to reviewing a track that is near perfection. Likewise, very few people will have a problem talking about a track that locks up their system. The trouble begins, however, when you encounter those gray areas in between. The following example is about that in between area of track reviewing. This actually happened and I strongly recommend NOT to get yourself ensnared in these kinds of situations. The names are changed because this is a tips page, not a gossip column. I'm using it as an example because I think there's something to be learned from it. So.... Fred makes a new track and posts it for download. Fred asks Barney to review it. Barney agrees and downloads the track only to find it plagued with problems. So, now, Barney finds himself in a bit of a tight spot. He has promised a review but hasn't the heart to bash Fred's work. After all, Fred has put so much of himself into this track that Barney is sure any harsh words will crush ol' Fred's ego. Barney plans to ignore the situation in the hope that it will fade away. But! We all know what Fred is like; he pesters Barney about the review to the point that he doesn't know what to do. Barney's conflict is very real. He doesn't want to criticize Fred's
work, but he doesn't want to mislead potential downloaders. Not knowing
where to turn next, Barney asks Phineus what he thinks on the matter.
Now, if Phineus was sharp, he would have butted his nose out big time.
But, he's sometimes rather slow and dim-witted and, so, offers to look
at the track. To make a long story short, Phineus suggests to Barney
to post a review that goes something like this :
Now, Barney can't tear himself away from his initial feelings of kindness and decides to re-write his review entirely to make it sound softer. Phineus quickly objects that the downloaders are the target audience here, not the track maker; it wouldn't be right. Barney takes offense at this apparent jab at his integrity and becomes upset with Phineus. Meanwhile, Fred is still after his review, so Barney shows the "Phineus" proposal to him. Guess what? Fred is upset with Phineus too. In an effort to make amends with everyone, Phineus agrees to a tour of the track under the confident guidance of Fred. And, after an hour or so of falling into ditches and not being able to get out, after looking at sloppy texture work and a very roughly made terrain, after ignoring check point problems and trees that haven't been set to facing, after discovering a new lag problem not noticed before, and after listening to many many rationalizations about why these things were done on purpose, Phineus accepts a change to the proposed review. "Yes," he admits, "you can take out the wet-behind-the-ears part." In conclusion, a five is not an eight. And that's how fives are likely to be described. The track works - which is more than can be said for some other tracks - but it needs work. Yes, reviewers should be kind and considerate. But, please, track maker's, don't shoot the messenger either. P.S. I am really happy to say that all friendships remain intact. So, after everything has been said and done, good sportsmanship wins the day.
Case study : beta report 1 The above review gave rise to a considerable amount of talking between
myself and the track maker. Although, from certain perspectives,
the review can seem very harsh, the track maker recognized that it was
not a personal attack and eventually grew to appreciate a great deal of
feedback. It was during these conversations that I learned he had
received one beta report that went something like this:
This kind of response might recognize a degree of intensity, but it does nothing to help the track maker improve or make refinements to the track. And, as a review, it tells nothing about what the track is like. If you agree to beta test a track, then you are also agreeing to provide some useful commentary. Please do your part, so track makers can do theirs.
Case study : beta report 2 This is an actual beta report I gave to a guy. For the most part,
it follows the guidelines mentioned above.
The name of the actual track is not really the important thing here, but you should take note of the kinds of things being talked about and how suggestions are worked into the whole thing. Also note how I try to describe "where" in the track the things are that I'm trying to talk about. Pin-pointing locations can be very hard to do at times. In one case, I actually opened the pod up in Traxx's Pod File View and told the track maker the x, y and z values so he would know exactly where a hidden texture problem was located. In both cases, the track makers were appreciative of the report.
So, the point I am struggling to make clear is this : we are all neighbors
here in the mtm community. Those who provide reviews and beta reports
would do well to keep the track maker's feelings in mind. Those who
receive responses to their work would do well to take all suggestions under
"advisement";
then go ahead and make your track. If you can understand this,
then you should be able to understand why Yeastman signs his work, "Unity!
As one stand together!" We should respect the role or spot in which
we place our friends. It's not always easy pleasing everyone.
Apr 99
|