[Main topics] [Navigation]

Explanations for problem report to Adobe

This page helps you to fill in a problem report defined by the form (you most likely come from).

The problem report calls for various information. You might not be familiar with the terms and what is expected under these headings.

You may either get acquainted with this business and read this page as a whole, print it out for later study or just go back to the form (with your browsers BACK button) after reading one section.

You may also be interested in complete sample error reports.

[To top/bottom of page] General issues

Keep in mind, that a problem report must compete with a large number of others*), and that a product responsible must be able to justify the effort of any work. Essential for a good problem report are:

When creating a problem report, ask yourself:

[To top/bottom of page] Formatting the text

In the text fields you may enter nearly any HTML code. For example you can separate paragraphs by <p> tags and enclose pieces of code in the two lines <pre> and </pre>:

     It would also be more user friendly to show the actual characters in use:
     ; Smart Quote Characters
     ;English       ‘   ’   “   ”
     ; SmartQuotes=\xd4\xd5\xd2\xd3
     ;German        ‚   ‘   „   “
     ; SmartQuotes=\xe2\xd4\xe3\xd2
     ;French        ‹   ›   «   »         v-- activated
     ;Swedish/Finn. ’   ’   ”   ”
     ; SmartQuotes=\xd5\xd5\xd3\xd3
     ;Italian       ‘   ’   “   ”
     ; SmartQuotes=\xd4\xd5\xd2\xd3

[To top/bottom of page] Version and build

This information normally can be found by the menu item Help > About in the product.

Examples for this information:

International version 5.5P4f
French version 5.1.1
UNIX versions with X-windows 1.1

[To top/bottom of page] Title of problem

The title should provide a brief description to give hints about the category of the problem. People entering the case into the problem data base need some hints...

Examples of titles

Bad examples

[To top/bottom of page] Severity of problem

Please indicate the severity of the problem in the description: severe problem, problem, annoyance. Even an annoyance with a good justification may give a hint for improving the product).

[To top/bottom of page] Problem description

Example 1

Many of the the default values in menus and selection lists can be set in the Xresource files. Many settings are documented in the online-manual "Customizing FrameMaker Products (UNIX), other are documented "by example" in the resource file itself.

However, there is no indication, whether

It is, for example, not possible to set the default value for "Download fonts to printer" to NONE (because even strange fonts are installed in the printer already).

Example 2

When working with word processors or graphic programs, it is not possible to define a display ratio of 1, that is, display the object in its true size. It is only possible to define a zoom value. Working with the same tools on a variety of output devices (VGA, XGA and larger) further adds to the problem.
For example, it is not possible with the current behavior of Windows to judge layout even on a big screen, because adaptation of the application to a 1:1 scale is not possible at all. In addition, many applications do not support scaling or zooming.

Example 3

Opening the print dialog takes 10 - 15 seconds, in rare cases even more than 2 minutes. The delay is only slightly influenced by network load. In addition, the list contains the double number of printers on the network.

Bad description

Change menu item File > Imbedding to File > Inclusions
(This is not a description, but a proposed solution. Avoid this sort of bit-and-byte nit picking in any case. You will not be able to make a business case for it.

[To top/bottom of page] Justification

If something is of concern to you, then the value of getting the problem fixed can be justified. Then the author can define a business case for the solution of the problem. A business case consists of: Include benefits in terms of business, technical or financial implications. Demonstrate better usage of the product or service, if the requirement will be solved. Quantify the value of the solution to your business.

Examples of justifications

Bad examples for justifications

[To top/bottom of page] Operating system

The items in the drop-down list may reflect environments not valid for the product or a valid environment my be missed. Provide additional details, such as Service Packs installed in section "Operating system version".

[To top/bottom of page] Additional information

If you think your environment is somewhat unusual or needs a detailed specification, give more details here:

[To top/bottom of page] Circumvention

A problem may cause work deep down in the code. If you have found a circumvention, this will be beneficial as an intermediate solution also to other customers using the product.

Examples of circumvention

[To top/bottom of page] Proposed solution

If possible, provide the idea for a solution, but keep in mind, that this is only a suggestion. The entry here should be as general as possible, open for other system implementations.

Examples of proposed solutions

[To top/bottom of page] Notes

*) Good products will of course not generate a huge number of problem reports. But keep in mind, that only «shelfware» does not create any problems!


[Main topics] [Navigation]
 URL:  Created: 1996-12-28  Updated:
© Docu+Design Daube, Zürich    
  Business of Docu + Design Daube Documentation issues Sharing information Klaus Daube's personal opinions Guests on this site Home of Docu + Design Daube To main page in this category To first page in series To previous page in series To next page in series To bottom of page To top of page Search this site Site map Mail to webmaster To bottom of page To top of page