Overview
Preparation
Review components

Overview

A technical review describes an computer application and how it joins technology to underlying concepts. You answer the following questions with a technical review:

• What application are you writing about?
• How does it fit into the larger ecosystem of computing?
• What are its underlying concepts?
• In which areas does it stand out for better or worse?
• Who should use the application?

The term "computer application" is meant in a broad sense - it may be a software suite, a research prototype, a web page, a database system, or something else. The key is that it should be a discrete instance of a larger class of applications (e.g., ArcGIS vs. all GIS or Google Earth vs. all web mapping) or a single example of a larger approach (e.g., logistic regression of lion attack sites vs. regression modeling).

Your answers to these questions must be understood by the "intelligent layperson" in GIS - a fellow professional who is reasonably well informed about a wide variety of issues in GIS but who is unlikely to have more than a passing familiarity with your application. Your job is to bring this person up to speed quickly and give them what they need to know to make decisions about the application, such as whether to use it for their research or purchase it for their employer. In the review body you can fold in more specialized details but they are always couched within a larger framework that the intelligent layperson can understand.

Two good ways to get up to speed on what constitutes a technical review:

• Read a trade magazine like GeoWorld or ESRI News. These outlets have many articles that are essentially short technical reviews. These and other journals are available online and in the library. You will go deeper than most of those found in trade journals because you will also speak to how the application deals with larger concepts in GIS.
• Another good source of reviews is the journal Computers & Geosciences, which tends to focus on geological applications but does present some good examples where researchers describe computer applications. Two examples are:
  • Lan, Hengxing, C. Derek Martin, and C. H. Lim. (2007). RockFall analyst: A GIS extension for three-dimensional and spatially distributed rockfall hazard modeling. Computers & Geosciences 33:262-279.
  • Liu, Yuhong. (2006). Using the Snesim program for multiple-point statistical simulation. Computers & Geosciences 32:1544-1563.
• Short research reports that focus on technical, applied aspects of a project are also a good bet. Many research papers focus on using a given methodology to prove a point or address a theory, but some are very focused on discussing a technical problem or describing how to use technology to answer questions. A technical review mirrors the latter category.

Preparation

In preparing for the technical review, you must first be up to date with research in the field. You must understand the larger computing ecosystem of which the application is part. If you are examining Google's web mapping application, for example, you need be familiar with web mapping as a whole in order to place your single application in a larger context. Developing this context will take some time.

Consult writing a literature review and the resources page for hints on searching the library for information, particularly books and journal articles that are germane to your application. Make special note of using UMN Library resources to conduct research.

Review Components

See writing a paper for general advice on formatting your review.

Abstract/Introduction: set out your issue in relation to the big picture and then give a short summary of your review findings.

Introduction: set out your application in relation to the broader computing environment and then give a short summary of your review findings. The introduction lays the ground work for the rest of the piece, and later sections will go into greater detail.

Body: you must accomplish the following tasks in the body of the review:

• Clearly and succinctly summarize major applications in the field and some of the intellectual history, including citations to the research state of the art.
  • When reviewing a given software system or approach, describe the bigger picture. If you are writing about a proprietary soil erosion model, for example, you need to address environmental and raster modeling in general and early models like USLE or RUSLE in particular. You do not want to go into too much depth here, but you must also convey to the professional in soil erosion that you know the field well enough in general to make adequate comparisons to other approaches and to understand the strengths and weaknesses of the application.
  • When describing a technical application, also describe the bigger picture. If you are describing how you used remote sensing to evaluate water quality, for instance, give the reader a sense of past applications that use geospatial technology to measure water quality.
  • Regardless of the focus of your paper, try to create (ideally) or borrow (if necessary) a framework for positioning your approach in a broader context. This is a chance for you to create your own typology (e.g., "there are three kinds of web mapping: open source software, ESRI products, and custom/proprietary systems") or borrow a well-known one (e.g., "according to Manson (2006), there are several kinds of complex modeling approaches, of which one is agent-based modeling."
• Critically evaluate. Each application or approach has relative advantages and disadvantages. How are they useful or not useful? Importantly, you must justify your critique.
  • If you are describing a technical application, you can develop your evaluation by demonstrating how your particular application stacks up against general research needs. Continuing the water quality example from above, maybe you want to focus on the merits of different remote sensing platforms in order to justify your eventual choice of one sensor. Or, perhaps you want to focus more on you analytical decisions, such as using regression versus a decision tree in developing water quality indicators. Consider a few large questions apply - what choices and assumptions did you make in your approach? Why did make it or use it? Who besides you will, or could, use it? How does it compare to other applications in the same field? What key conceptual issues do you deal with?
  • If you are focusing on software, , or if you want, by actually testing two or more packages head to head. To continue the RUSLE example, you could compare the ease of use and accuracy of two or three different model
  • Establish the motivations for why the application was created and the choices the developers made in creating it. Idrisi, for example, is a raster GIS that is often compared to other GIS packages, especially ArcGIS. Overall, Idrisi does not really compete with ArcGIS because it has a different target audience (e.g., academia and development situations), a different market model (i.e., not-for-profit), and assumptions of users (e.g., Idrisi is designed to work well on older machines as well as new ones in order to better serve users in resource-poor environments). At the same time, Idrisi provides some of the most sophisticated GIS solutions to problems such as multicriteria evaluation, imagery classification, spatial modeling, and landscape evaluation.
• See the page on writing a report for more details on the use of tables, graphics, figures, and so on, but keep in mind that technical reviews do well when they use tables to summarize information and flow charts and screen shots to help illustrate key features of the application. Appendices are also a good idea if you have developed code or have many screen shots.

Conclusion: this is your opportunity recap how the application fits in with the larger computing ecosystem, its underlying concepts, areas in which it stands out for better or worse, and who should use it.