An alternative to the textual critiquing supported by CT would be a graphical report. For instance, a critiquing system could report overlapping widgets graphically by displaying the layout and highlighting the critical area (see Figure 6). Graphical reporting works well when a simple figure can illustrate the problem, and when the reporting subsystem can generate such figures automatically. Potentially, critiquing systems can produce reports that contain combinations of text and figures (similar to simple technical reports). The architecture of such critiquing systems, however, must include an advanced reporting module that takes advantage of the input data to the critiquing system.
Figure 6:
An example of graphical reporting of design critique. The report consists
of a generated sketch that explains the problem.
In addition to generating static text and figures, critiquing systems can produce interactive reports. Hypertext reports, for example, allow readers to follow links to get further information about critique points. Pictures, too, can provide active regions that give additional information to the user. Moreover, links can refer to the input data to the critiquing system. For example, a critique report that mentions a flawed class definition can allow the user to edit this class directly in the ontology editor. Also, links to the window-layout editor could allow the developer to correct layout problems quickly.
Although several sophisticated reporting techniques are available, the most important messages from the critiquing system to the user are what the detected problem is, and where it occurred. Depending on the development work cycle, designing critiquing systems provides additional assistance that helps the user understand and correct the problem rapidly.