Site Help & Support - Review Writing Guidelines

This section outlines some requirements and guidelines for writing reviews for HPC:Factor.

 

General Requirements (summary)

Reviews submitted to and subsequently published on HPC:Factor must:

  1. Be English language (any region)
  2. Be based around a written structure
  3. Have accurate spelling, punctuation and grammar
  4. Minimise the use of the first person - you are not writing a blog post
  5. Be at least 500 words long
  6. Not defame or seek to unfairly influence the public presence of any individual or company

 

Common mistakes in review writing

The examples below outline some of the more common mistakes that we have seen over the years in review submissions. If a review is rejected it is usually the case that it is for doing one of the following:

#1 Creating a Photo Album

You aren't creating a picture book, you are writing a review - an opinion piece that is well argued, weighted and properly structured. Graphics are there to enhance what you are saying. From the users perspective it is a simple fact that it is more engaging to go and download the trial of the program themselves. As a writer it is your job to tell them why they should spend the time downloading the trial! If the sum of the pictures is greater than the sum of your writing - usually this is very obvious when laid out in a page template due to sparse bodies of text being present - then it just isn't worth publishing.

 

#2 Explaining information in a photo/graphic

Rule number one for our editorial standards check on any submission catches a lot of people out. When proof reading a document we delete all the pictures from it. If as an editor we cannot understand what you are referring to (save for absolutely necessary use of "see the screen shot below"), it will fail to be accepted. Your words have to tell the reader everything about the program, do not rely upon a picture unless it really is pivotal to your argument.

 

#3 Did someone ask for the manual to go?

A sure fire way for an editor to a) stop reading a review and b) refuse to publish it is if you are reciting the users manual in your review. The editor can read, we can all read or we wouldn't be here! If a reader wants to read the features list, they can go to the manufacturers site or related help file and read the features list. As a reviewer you are trying to tell the audience why they might be interested in the program (or why they shouldn't touch it).
If you the reader tell me that, great. If you can tell the reader something that no other reviewer has, excellent. If you can tell the reader something the manufacturer didn't know - Fan-tas-tic.

 

#4 Slang and colloquial phrases

No slang and preferably no colloquial expressions in the main review body. Your intended audience is international, not a corner of the US North West. Making a great joke about Martha Stewart in your review may be well very funny to 1/1000th of the global population, however there is a good chance that 5.7 billion people in this world have no idea who Martha Stewart is: If you're going to be cute, please elaborate as is necessary.

 

#5 "I"

Please try and minimise the use of the first tense. The use of "I" throughput an article often shows a lack of thought over the content of the article, and has too much of an informal tone to it. We aren't looking for blog style review pieces for publication, but academic style approaches.

 

#6 Spelling, punctuation and grammar

Little should need to be said here, but it does happen. Aside from UK/US/Int English differences - we will publish based upon spelling in your native English.

 

#7 Audience Awareness

Who are you writing for? Usually a good idea to spell that out somewhere near the beginning. If I'm a 2.11 reader and the app only works on CE 4.2...

 

#8 Nicey nice

Don't be afraid of being critical when and where it is fair and necessary to do so. We usually give developers a lead time on the review before publishing. There have been frequent instances in the past where warranted criticism in a review has led directly to changes in the application. A quick edit to the document to add that they responded and fixed some of the comments always looks good for the reviewer and for the manufacturer.

 

#9 The use of URL's

"http://". I was once at a seminar, many, many years ago being told by an "expert" just how wonderful hyperlinks are. Being told how great it is that the net is a non-linear system and why every website should make as much use of hyperlinks as possible so that all information can be intertwined with all other information.

That's very nice if you're wikipedia.

When a reader encounters a "http://" in a review, what you are saying to them is "here, please leave this website, please leave half way through my review; you don't need to finish reading it". Guess what we do not want readers to leave the website, and as a writer it is much preferred if the reader consumes all of your thoughts and ideas and absorbs your hard work!

 

#10 Forgetting the support & system requirements

If you can, try and comment on the manufacturers support procedure/efficiency as we do score based upon support. For John Ottini a particular bug here is the registration system for payware. For Clinton Fitch it's response time on email.

System requirements is also important for the review. If you don't actually know the system requirements for the product that you have reviews, the chances are you haven't reviewed it very well.

 

#11 Forgetting to conclude

Conclude you review. This is where you can sum up the entire review, and you can go to town on really adding a personal touch to the article (you can freely use "I" here). This is the experts opinion part of the review over the analytical part where you have the opportunity to tell the reader exactly what your feelings are and whether you would in all honest ever pick up the program/device again.

 

Review Ratings

As a reviewer the duty of responsibility falls upon you to issue the product with its 5 HPC:Factor review ratings. The 5 areas that we benchmark are:

  1. Cost - Does it offer value for money to the potential buyer?
  2. Usability - This is a very broad and unspecific term as it means many things to many people. This is intentional as it serves to allow you to reflect upon the entire usability experience in your review and rat it accordingly
  3. Built-in Helps - Quite simply was there help available within the application and was it actually helpful
  4. Customer Service - This value reflects your experiences talking to the developer and using their support pages and technical support
  5. Overall Rating - This is a subjective overall rank for the program given by you the reviewer. It is not worked out mathematically.

For all 5 of the ratings you can give a review of 0 - 5 in increments of 0.5. For reviews where a ranking is not applicable - for example a review of an application whose developer is no longer in business a N/A rating (blank) should be given rather than a 0-star rating. It is expected that such situations will have been outlined in the review.

The ranking symbols are shown in full below.

Not Applicable Rating

 

0 Stars (Dreadful)

0 Star Rating: Dreadful

0.5

0.5 Star Rating: Extremely Poor

1.0

1 Star Rating: Very Poor

1.5

1.5 Star Rating: Poor

2.0

2.0 Star Rating: Weak

2.5

2.5 Star Rating: Below Average

3.0

3 Star Rating: Average

3.5

3.5 Star Rating: Good

4.0

4 Star Rating: Recommended

4.5

4.5 Star Rating: Very Good

5.0 (Exceptional)

5 Star Rating: Exceptional

We expect that your review ratings will be based upon subjective and fair analysis of the product that you are reviewing. Although unlikely, we reserve the right to suggest changes to the ratings and, if you are not agreeable, to refuse to publish the review.

We also expect that all review ratings are backed by a short "Pro's and Con's" list to give a very brief summary justifying your choices. Such summaries are best exampled by viewing existing reviews.

 

Photographs in reviews

Photographs are often necessary and add value or substance to the review as a whole. Aside from remembering to keep image use to the most salient points you should:

  • Photograph on a white sheet. Frankly, it looks a little odd when a review contains a plethora of other peoples carpets
  • Try to minimise flash use as flash reflections can be unsightly
  • Please send photo's in JPG format along with your review
  • Please do not try to resize the photo's to match HPC:Factor's layout, we will do that
  • Unless you are a dab hand in photoshop, please let us know about any edits / removals that you would like from the photo rather than removing them yourself in say Microsoft Paint
  • Please do not photograph software reviews, please use a screen capture program

 

General Graphics, Images, Photo and video use

When submitting your review, please send your photographs etc along with the document together in a Zip file. Please ensure that:

  1. Photographs are in JPG format
  2. Screen shots are in BMP format
  3. All images and graphics are named to reflect their order in the review e.g. 001-thejornada720.jpg, 002-the720keyboard.jpg, 003-hpc2000desktop.jpg
  4. Videos are in a standardised format, preferably in a web player format
  5. All graphics and video have captions or pointers for placement in the article
  6. Please do not simply send the entire review as an embedded set of objects in a word file as it is difficult to maintain image quality when extracting back out of word documents