3

A PC program lets the user work on a large amount of sets of data. A new feature will be the generation of report files. The user, while viewing or editing one of the sets of data in a quite complex GUI, will have the possibility to generate a "report file" which is actually a PDF document created and opened automatically. This PDF has all the important data neatly organized, and should become very useful in printing, and sharing the data.

When clicking on a button equivalent to "generate report", the following happens:

  • A PDF document is created on the hard disk
  • The PDF document is opened with the default program the operating system has assigned to it (for example, Acrobat Reader)
  • the most common use case is that the user prints the document, or saves it to a preferred location with a preferred name, and closes it.

However, how should those PDF documents be handled? Multiple solutions come to my mind:

  1. Always generate one document (e.g. "report.pdf"). The problem is, if the user wants to generate a new report, and forgets to close the old, it will not be possible to generate the new one. I think opening an alert box in this situation would be to annoying.

  2. Generate the document unique for the dataset in question. (e.g. "report_datasetname.pdf"). The problem is, the number of documents will increase to an unmanageable level.

  3. Generate a temporary document (e.g. "a4ryg4uee5tw.pdf", or "000001.pdf"), and clean all the temporary files at exiting or on the next start. Possible problems: not a friendly name, and the user might not expect that the document will be lost if the program is exited. Maybe he wants to generate the report file, and look at it later. An opened PDF document does not have the features that most editors have (a star after the name, a prompt asking to save if I try to closing it) when holding temporary data.

Are there very important advantages/disadvantages of any of these options? Is there an "accepted standard" way of doing it?

3 Answers 3

1

We ask the user what he wants to do before generating the report: save, print or email. The email and print options result in the report being created as a temporary file that either gets attached or printed. The save option results in the report file being generated at the place and with the name selected by the user (though we do suggest one, of course).

3

It is really important to use human readable and meaningful name for a report. Time (date) can be used to make report name unique and provide additional value (it will be much easier for the user to manage downloaded report).

So the recipe is:

  • human readable name
  • relevant and meaningful name
  • time or date
2

There has to be clear and unambiguous relationship between the state of the dataset and the generated report. This means, after printing out the report, one shall be able to a) quickly find the dataset which the report refers to; b) navigate, if necessary, to the exact state of the dataset at the time the report was generated, replicating all and sundry commands and settings along the way. Otherwise this leads to needless waste of time and lack of traceability.

Re: names. Must say that providing a human-readable default name is a very sensible requirement; however please consider also setting up metadata in the generated PDF file, in case users prefer to rename the file into something else than the default option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.