Main.ReviewGuidelines (r1.1 vs. r1.4)
Diffs

 <<O>>  Difference Topic ReviewGuidelines (r1.4 - 20 Jan 2012 - GeoffreyRockwell)

META TOPICPARENT TAPoRRedesign

Review Guidelines

These are the most recent guidelines for the tool reviews which are being commissioned for TAPoR 2. Tool reviews should include:

Changed:
<
<
  1. The basics about the tool. Identify what the tool is. What other tools are similar? Who developed it? Who the intended audience? What it is meant to do?

  1. The requirements for use. Is it a download, a plugin, a webapp? Is it free or does it require purchase? Is it open source? Does it require a license? Where can you get it? What are the browser/OS requirements?

  1. How quickly can you get the tool up and running? Are there any special requirements, such as creating an account, a lengthy install process, or other setup processes? How much room does the user have to customize elements, append custom code, or otherwise adapt it to their particular needs?

  1. Ease of use. Is the interface intuitive? What kind of learning curve can the user expect? Are there any obvious limitations or bugs? Is it a specific-purpose tool, or does it have wider applications? Does it lag under certain circumstances, such as feeding in a large text or multiple texts? Does it demand input in a specific format or can it handle a wide variety?

  1. Is this tool recommendable? Does it fit the needs of the stated audience? Are there any unique or particularly outstanding features? Any notable drawbacks? Where can you go for more information about the tool?
>
>
  1. Introduction: The basics about the tool. Identify what the tool is (what does it do? is it online? free?.) Who developed it? Who the intended audience? What it is meant to do?
  2. Details: More information about the tool. What does it do in detail? What features? What other tools are similar?
  3. Limitations: What doesn't it do. What are the limitations? What bugs are there?
  4. Questions: What might others comment on.

Other things to take into account

  1. The requirements for use. Is it a download, a plugin, a webapp? Is it free or does it require purchase? Is it open source? Does it require a license? Where can you get it? What are the browser/OS requirements?
  2. How quickly can you get the tool up and running? Are there any special requirements, such as creating an account, a lengthy install process, or other setup processes? How much room does the user have to customize elements, append custom code, or otherwise adapt it to their particular needs?
  3. Ease of use. Is the interface intuitive? What kind of learning curve can the user expect? Are there any obvious limitations or bugs? Is it a specific-purpose tool, or does it have wider applications? Does it lag under certain circumstances, such as feeding in a large text or multiple texts? Does it demand input in a specific format or can it handle a wide variety?
  4. Is this tool recommendable? Does it fit the needs of the stated audience? Are there any unique or particularly outstanding features? Any notable drawbacks? Where can you go for more information about the tool?

-- AmyDyrbye - 21 Sep 2011


 <<O>>  Difference Topic ReviewGuidelines (r1.3 - 21 Sep 2011 - AmyDyrbye)

META TOPICPARENT TAPoRRedesign

Review Guidelines

Changed:
<
<
These are guidelines for the tool reviews which are being commissioned for TAPoR 2.
>
>
These are the most recent guidelines for the tool reviews which are being commissioned for TAPoR 2. Tool reviews should include:

Changed:
<
<
  1. The review should start like a book review: "Cirrus is a member of the Voyeur Tools family. It was developed by Stéfan Sinclair and Geoffrey Rockwell ... It generates a word cloud of the high frequency words." This is an introductory paragraph. It should mention the genre of tool (statistical, viz ...) and it could mention community the tool is for.
  2. The review should then look at the license and availability (where do you get it, how much does it cost, and can you run in the web, or do you need a particular system.)
  3. The review should then discuss installation and set up for those tools that need it.
  4. Then the review should talk about usage. The review might be specific as to the texts tried and what errors there were or problems. The review should talk about difficulty of use. It should talk about performance - how fast is it to get to results with what size text.
  5. The review might then talk about what this is good for. What sorts of questions/answers does it help with? What community uses it (linguistic? literary? ...)
  6. Then there should be para about where to get more info and links to any publications you can easily find about the tool. There should be some evaluation of the documentation.
  7. Then something for developers if the tool is open source and/or extensible, programmable etc.
  8. Finally, a concluding para with anything else that stands out and a general recommendation of who this for and what it is for.
>
>
  1. The basics about the tool. Identify what the tool is. What other tools are similar? Who developed it? Who the intended audience? What it is meant to do?

Added:
>
>
  1. The requirements for use. Is it a download, a plugin, a webapp? Is it free or does it require purchase? Is it open source? Does it require a license? Where can you get it? What are the browser/OS requirements?

Added:
>
>
  1. How quickly can you get the tool up and running? Are there any special requirements, such as creating an account, a lengthy install process, or other setup processes? How much room does the user have to customize elements, append custom code, or otherwise adapt it to their particular needs?

Changed:
<
<
-- GeoffreyRockwell - 29 Jun 2011
>
>
  1. Ease of use. Is the interface intuitive? What kind of learning curve can the user expect? Are there any obvious limitations or bugs? Is it a specific-purpose tool, or does it have wider applications? Does it lag under certain circumstances, such as feeding in a large text or multiple texts? Does it demand input in a specific format or can it handle a wide variety?

  1. Is this tool recommendable? Does it fit the needs of the stated audience? Are there any unique or particularly outstanding features? Any notable drawbacks? Where can you go for more information about the tool?

-- AmyDyrbye - 21 Sep 2011



 <<O>>  Difference Topic ReviewGuidelines (r1.2 - 16 Sep 2011 - GeoffreyRockwell)

META TOPICPARENT TAPoRRedesign

Review Guidelines

These are guidelines for the tool reviews which are being commissioned for TAPoR 2.

Deleted:
<
<
The students reviewing should work with a set of texts and test questions that we review. We will want a collection of test texts. Can you come up with a set that includes Plain, HTML, XML, small text, medium, and large (1 meg).

  1. The review should start like a book review: "Cirrus is a member of the Voyeur Tools family. It was developed by Stéfan Sinclair and Geoffrey Rockwell ... It generates a word cloud of the high frequency words." This is an introductory paragraph. It should mention the genre of tool (statistical, viz ...) and it could mention community the tool is for.
  2. The review should then look at the license and availability (where do you get it, how much does it cost, and can you run in the web, or do you need a particular system.)
  3. The review should then discuss installation and set up for those tools that need it.

 <<O>>  Difference Topic ReviewGuidelines (r1.1 - 29 Jun 2011 - GeoffreyRockwell)
Line: 1 to 1
Added:
>
>
META TOPICPARENT TAPoRRedesign

Review Guidelines

These are guidelines for the tool reviews which are being commissioned for TAPoR 2.

The students reviewing should work with a set of texts and test questions that we review. We will want a collection of test texts. Can you come up with a set that includes Plain, HTML, XML, small text, medium, and large (1 meg).

  1. The review should start like a book review: "Cirrus is a member of the Voyeur Tools family. It was developed by Stéfan Sinclair and Geoffrey Rockwell ... It generates a word cloud of the high frequency words." This is an introductory paragraph. It should mention the genre of tool (statistical, viz ...) and it could mention community the tool is for.
  2. The review should then look at the license and availability (where do you get it, how much does it cost, and can you run in the web, or do you need a particular system.)
  3. The review should then discuss installation and set up for those tools that need it.
  4. Then the review should talk about usage. The review might be specific as to the texts tried and what errors there were or problems. The review should talk about difficulty of use. It should talk about performance - how fast is it to get to results with what size text.
  5. The review might then talk about what this is good for. What sorts of questions/answers does it help with? What community uses it (linguistic? literary? ...)
  6. Then there should be para about where to get more info and links to any publications you can easily find about the tool. There should be some evaluation of the documentation.
  7. Then something for developers if the tool is open source and/or extensible, programmable etc.
  8. Finally, a concluding para with anything else that stands out and a general recommendation of who this for and what it is for.

-- GeoffreyRockwell - 29 Jun 2011


Topic: ReviewGuidelines . { View | Diffs | r1.4 | > | r1.3 | > | r1.2 | More }

Revision r1.1 - 29 Jun 2011 - 20:37 - GeoffreyRockwell
Revision r1.4 - 20 Jan 2012 - 21:27 - GeoffreyRockwell