Difference between revisions of "GEPS 007: Report Reorganization"

From Gramps
Jump to: navigation, search
Line 5: Line 5:
 
== Motivation ==
 
== Motivation ==
  
== Some ideas ==
+
(This from a [http://www.nabble.com/Report-Interface-to13012651.html#a13012651 gramps-dev discussion])
 +
 
 +
Users usually either have an idea of a particular kind of report that they would like to run (something to show their ancestors), or they are browsing to see what reports are available. However, the first set of categories that the user encounters are: Code Generators, Graphical, Text, View, Web, Unsupported, and now Graphviz (maybe that is just a temp category?). These are a mixture of what is in the report (graphics vs. text) OR where it is going (web vs. View) OR what is used for (code gen) OR its supported status.
 +
 
 +
Those categories don't make any sense to a new user, and even after using GRAMPS for a while, I have to stop and think. But even beyond that, these categories are largely arbitrary and irrelevant. If a text-based report includes pictures, does that then make it graphical? The Ahentafel report can go to the web, but it isn't in the webpage category, it is in Text.
 +
 
 +
After a user selects a report to generate, the very first questions are: Filename, open in, and output format. Some reports can be saved as PDF, others as images, LaTeX, RTF, Textbuffer, and a host of others. What determines the output options? It isn't clear why all output options aren't available for all reports.
 +
 
 +
Finally, there are some strange (to the user) limitations. If I select the View reports, (or if I select TextBuffer (which the word would have zero meaning for Auntie M)) then there doesn't seem to be a way to print it. This also seems to be true for Quick Reports---can't print those out either. (I can cut and paste, I guess).
 +
 
 +
Some suggestions to help make this easier to use:
 +
 
 +
# Create categories that are more meaningful to the user, not the programmer. Or just get rid of all of these categories and have a list of the 20-some reports.
 +
## Why are unsupported reports there? Remove or support them. Maybe there should be a category of "Third Party", "Additional", "Personal" but not unsupported---those sound dangerous and yet GRAMPS comes with them?
 +
## Perhaps all reports should have an example image to indicate what it will look like if you run it.
 +
# When you select a report, it automatically runs and displays on the screen. Because these go to the screen, names are clickable and would change the active person in the main window (interactive reports). Other clickable items could also be defined.
 +
# After the report is displayed, all reports should then have 3 options, "Options", "Print", and "Export"---and you can do each multiple times.
 +
## Options could be changed, and the report would refresh the screen.
 +
## Make it so that you can print all reports, even those that originally just went to the screen.
 +
## Make the export options the same (or mostly the same) for all reports.
 +
 
 +
== Plan ==
 +
 
 +
Rearrange the menu
 +
 
 +
Suggest grouping reports by conceptual relations, rather than output format.

Revision as of 01:38, 14 December 2007

Proposed changes for enhancing GRAMPS reorganizing the Reports menus and dialogs.

Motivation

(This from a gramps-dev discussion)

Users usually either have an idea of a particular kind of report that they would like to run (something to show their ancestors), or they are browsing to see what reports are available. However, the first set of categories that the user encounters are: Code Generators, Graphical, Text, View, Web, Unsupported, and now Graphviz (maybe that is just a temp category?). These are a mixture of what is in the report (graphics vs. text) OR where it is going (web vs. View) OR what is used for (code gen) OR its supported status.

Those categories don't make any sense to a new user, and even after using GRAMPS for a while, I have to stop and think. But even beyond that, these categories are largely arbitrary and irrelevant. If a text-based report includes pictures, does that then make it graphical? The Ahentafel report can go to the web, but it isn't in the webpage category, it is in Text.

After a user selects a report to generate, the very first questions are: Filename, open in, and output format. Some reports can be saved as PDF, others as images, LaTeX, RTF, Textbuffer, and a host of others. What determines the output options? It isn't clear why all output options aren't available for all reports.

Finally, there are some strange (to the user) limitations. If I select the View reports, (or if I select TextBuffer (which the word would have zero meaning for Auntie M)) then there doesn't seem to be a way to print it. This also seems to be true for Quick Reports---can't print those out either. (I can cut and paste, I guess).

Some suggestions to help make this easier to use:

  1. Create categories that are more meaningful to the user, not the programmer. Or just get rid of all of these categories and have a list of the 20-some reports.
    1. Why are unsupported reports there? Remove or support them. Maybe there should be a category of "Third Party", "Additional", "Personal" but not unsupported---those sound dangerous and yet GRAMPS comes with them?
    2. Perhaps all reports should have an example image to indicate what it will look like if you run it.
  2. When you select a report, it automatically runs and displays on the screen. Because these go to the screen, names are clickable and would change the active person in the main window (interactive reports). Other clickable items could also be defined.
  3. After the report is displayed, all reports should then have 3 options, "Options", "Print", and "Export"---and you can do each multiple times.
    1. Options could be changed, and the report would refresh the screen.
    2. Make it so that you can print all reports, even those that originally just went to the screen.
    3. Make the export options the same (or mostly the same) for all reports.

Plan

Rearrange the menu

Suggest grouping reports by conceptual relations, rather than output format.