Quantcast

Report Interface

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Report Interface

Douglas S. Blank
I've been using GRAMPS for a few years now, and have found most of GRAMPS
pretty intuitive. However, one place that I have always been confused is
the interface to the reports. One reason I'd like to have a better
interface to the reports is that it may end up being *the* interface to a
few things I'd like to add to GRAMPS.

So, in the spirit of looking at the interface critically and then making
it better, I offer some points where I have gotten confused, and some
suggestions.

First, I suspect that users usually either have an idea of a particular
kind of report that they would like to run (something to show 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.

1a) 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?

1b) 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.

3a) Options could be changed, and the report would refresh the screen.

3b) Make it so that you can print all reports, even those that originally
just went to the screen.

3c) Make the export options the same (or mostly the same) for all reports.

Now, I'm not sure what it would take to implement all of these, but some
are surely easier than others. I think most of this hinges on #2, which
would be a rendering in gtk objects of a report. Hard, but possible, yes?

Perhaps these ideas will spark other ideas on improving the report
interface. Just thinking out loud...

-Doug


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

bm-5
I have the impression some things are possible, some not.

You are right that finding a report can be difficult.
I would stick to reorganization of the menu/reports, eg with seperator (as
ordering is best alphabetic in groups). We will not have the manpower to
reorganize good working reports so they look more alike (although it is
a valid
goal).

Code generators is indeed not a good category, as eg gramps writes ODF, and
without an office suite you can also do little with that file. I think
it means
to the user: beware - dragons here, so more of an expert option.

Textbuffer is indeed an awful name. Print on it might be nice. The idea now is
indeed you need to copy/paste if you want to print quick report.

Please, do a full proposition of how the report menu could be organized, like
that we have a basis for discussion.

About unsupported, I don't think that is present in the official version, it
should only be visible in development versions if all works ok (I think).

Benny


Quoting "Douglas S. Blank" <[hidden email]>:

> I've been using GRAMPS for a few years now, and have found most of GRAMPS
> pretty intuitive. However, one place that I have always been confused is
> the interface to the reports. One reason I'd like to have a better
> interface to the reports is that it may end up being *the* interface to a
> few things I'd like to add to GRAMPS.
>
> So, in the spirit of looking at the interface critically and then making
> it better, I offer some points where I have gotten confused, and some
> suggestions.
>
> First, I suspect that users usually either have an idea of a particular
> kind of report that they would like to run (something to show 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.
>
> 1a) 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?
>
> 1b) 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.
>
> 3a) Options could be changed, and the report would refresh the screen.
>
> 3b) Make it so that you can print all reports, even those that originally
> just went to the screen.
>
> 3c) Make the export options the same (or mostly the same) for all reports.
>
> Now, I'm not sure what it would take to implement all of these, but some
> are surely easier than others. I think most of this hinges on #2, which
> would be a rendering in gtk objects of a report. Hard, but possible, yes?
>
> Perhaps these ideas will spark other ideas on improving the report
> interface. Just thinking out loud...
>
> -Doug
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Eero Tamminen-3
Hi,

On Wednesday 03 October 2007, [hidden email] wrote:

> I have the impression some things are possible, some not.
>
> You are right that finding a report can be difficult.
> I would stick to reorganization of the menu/reports, eg with seperator
> (as ordering is best alphabetic in groups). We will not have the manpower
> to reorganize good working reports so they look more alike (although it
> is a valid
> goal).
>
> Code generators is indeed not a good category, as eg gramps writes ODF,
> and without an office suite you can also do little with that file. I
> think it mean to the user: beware - dragons here, so more of an expert
> option.

Or instead of renaming the code reports to "Expert" category, the reports in
the code category could be folded to the non-code reports and e.g.
"Intermediate GraphViz .dot format" offered just as an output format for
Relationship report.

Users ignore the output formats they don't understand and the reports
remember the last used (e.g. format) options, so I think this would be
the best option.


> Textbuffer is indeed an awful name. Print on it might be nice. The idea
> now is indeed you need to copy/paste if you want to print quick report.
>
> Please, do a full proposition of how the report menu could be organized,
> like that we have a basis for discussion.
>
> About unsupported, I don't think that is present in the official version,
> it should only be visible in development versions if all works ok (I
> think).

Maybe:
- Generate web site...
+ Calendar reports >>
   - Birthday and anniversary list
   - Calendar
   - Timelines
+ Relationship reports >>
   - Ahnentafel report
   - Ancestor graph
   - Complete Individual report
   - Descendent chart
   - Descendent report
   - Detailed Ancestral report
   - Detailed Decendent report
   - Family Group report
   - Fan chart
   - Relationship graph
+ Statistics >>
  - Current person ancestors
  - Statistics chart
  - Database summary
- Report book...

I.e. Move "Book report" to top level as it's actually a book of reports in
the submenus, fold code thing to Relationship chart output option,
rename "view" to statistics and move Statistics chart under it, suffle
others under relationship and calendar related items.  The report
names might be change a bit too.

It would be also nice to be able to get all reports (including database
summary) into Report book for completeness sake.

The unsupport stuff could move under Tools -> Experimental if it's
not removed.


        - Eero

> Quoting "Douglas S. Blank" <[hidden email]>:
> > I've been using GRAMPS for a few years now, and have found most of
> > GRAMPS pretty intuitive. However, one place that I have always been
> > confused is the interface to the reports. One reason I'd like to have a
> > better interface to the reports is that it may end up being *the*
> > interface to a few things I'd like to add to GRAMPS.
> >
> > So, in the spirit of looking at the interface critically and then
> > making it better, I offer some points where I have gotten confused, and
> > some suggestions.
> >
> > First, I suspect that users usually either have an idea of a particular
> > kind of report that they would like to run (something to show
> > 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.
> >
> > 1a) 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?
> >
> > 1b) 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.
> >
> > 3a) Options could be changed, and the report would refresh the screen.
> >
> > 3b) Make it so that you can print all reports, even those that
> > originally just went to the screen.
> >
> > 3c) Make the export options the same (or mostly the same) for all
> > reports.
> >
> > Now, I'm not sure what it would take to implement all of these, but
> > some are surely easier than others. I think most of this hinges on #2,
> > which would be a rendering in gtk objects of a report. Hard, but
> > possible, yes?
> >
> > Perhaps these ideas will spark other ideas on improving the report
> > interface. Just thinking out loud...
> >
> > -Doug
> >
> >
> > -----------------------------------------------------------------------
> >-- This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Gramps-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

annelist
I suggest a few minor modifications to Eero's proposal, to do with the
naming of the reports. If they are listed alphabetically, then the first
word is important to help find them. Where possible, the first word
should describe the high level report type (don't know how else to
describe what I mean). For example:

Not "Complete Individual report" but "Individual Complete report"

Not "Detailed Ancestral report" but "Ancestral Detailed report"

Cheers,
Anne.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

bm-5
Can someone make a feature request on the tracker for this?

Thanks,
Benny

Quoting Anne <[hidden email]>:

> I suggest a few minor modifications to Eero's proposal, to do with the
> naming of the reports. If they are listed alphabetically, then the first
> word is important to help find them. Where possible, the first word
> should describe the high level report type (don't know how else to
> describe what I mean). For example:
>
> Not "Complete Individual report" but "Individual Complete report"
>
> Not "Detailed Ancestral report" but "Ancestral Detailed report"
>
> Cheers,
> Anne.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Douglas S. Blank
On Thu, October 4, 2007 6:01 am, [hidden email] wrote:
> Can someone make a feature request on the tracker for this?

Yes, I'll summarize what is currently easy, possible, and generally agreed
upon. Anyone else have comments on a report re-organization?

Thanks all for the feedback!

-Doug

> Thanks,
> Benny
>
> Quoting Anne <[hidden email]>:
>
>> I suggest a few minor modifications to Eero's proposal, to do with the
>> naming of the reports. If they are listed alphabetically, then the first
>> word is important to help find them. Where possible, the first word
>> should describe the high level report type (don't know how else to
>> describe what I mean). For example:
>>
>> Not "Complete Individual report" but "Individual Complete report"
>>
>> Not "Detailed Ancestral report" but "Ancestral Detailed report"
>>
>> Cheers,
>> Anne.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


--
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Brian Matherly
In reply to this post by Douglas S. Blank
Doug (and everyone),

>I've been using GRAMPS for a few years now, and have found most of GRAMPS
>pretty intuitive. However, one place that I have always been confused is
>the interface to the reports. One reason I'd like to have a better
>interface to the reports is that it may end up being *the* interface to a
>few things I'd like to add to GRAMPS.
>
>So, in the spirit of looking at the interface critically and then making
>it better, I offer some points where I have gotten confused, and some
>suggestions.
>
>First, I suspect that users usually either have an idea of a particular
>kind of report that they would like to run (something to show 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.

Currently, the reports are (roughly) categorized by the method used to generate them. It might seem arbitrary to a new user, but after learning about the various options that Gramps has to offer, it comes to make a lot of sense (with some exception).

>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.

What determines the output options is the method used to generate the report. The "Graphical" reports use the "DrawDoc" interface (with the exception of the relationship graph). Therefore, all "Graphical" reports have the same options available for output format (PDF, ODF, PS, etc).

>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).

In my experience, if a user doesn't understand a feature, they learn quickly to stay away from it. I expect that Aunt M would try the TextBuffer format once, find it to be not useful for her, and never try it again.

>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.

This could make it even more confusing. One report will provide a certain set of output formats, and the one right under it in the list will provide completely different output formats. It will seem random.

>
>1a) 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?

Unsupported reports are not included in official releases.

>
>1b) Perhaps all reports should have an example image to indicate what it
>will look like if you run it.

Or a quick link to the help page that included an example image.

>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.

"Interactive reports" is an oxymoron. Reports, by definition, are not interactive. User interfaces are interactive. If a person needs to interact with, navigate, or manipulate their information, they should use a tool for that.

>3) After the report is displayed, all reports should then have 3 options,
>"Options", "Print", and "Export"---and you can do each multiple times.

But the options are required before the report can be generated. Also, we can't provide an exact preview of how Openoffice will render a report If the user selects "ODF" as the output format. Openoffice might make different pagination choices than we do. So at best, the preview would be an approximation of the final export depending on the output format.

>3a) Options could be changed, and the report would refresh the screen.

Be warned: some reports take a long time to generate.

>3b) Make it so that you can print all reports, even those that originally
>just went to the screen.
>
>3c) Make the export options the same (or mostly the same) for all reports.

Some reports use Graphiz to render the report. No matter what we do, Graphiz will never be able to export as ODF. Not only that, but it uses a completely different method to generate PDF than the text reports (for example). This is just one example of how this might be mostly out of our control. And how would it make sense to export the Narrative web report as PDF?

>Now, I'm not sure what it would take to implement all of these, but some
>are surely easier than others. I think most of this hinges on #2, which
>would be a rendering in gtk objects of a report. Hard, but possible, yes?
>
>Perhaps these ideas will spark other ideas on improving the report
>interface. Just thinking out loud...
>
>-Doug

While I agree that your ideas sound like a great improvement, I'm very skeptical about the feasibility of most of them. Different reports work differently because they have different uses cases and different technology generating them. There are certain aspects of them that simply can not be unified. I think Aunt M is smart enough to find and use the reports that she finds useful and ignore the ones that she doesn't.

What I do agree with is this:

* Move all the Graphiz related reports under one category (which I've already started working on)

* Let's nitpick the names and make sure they describe the report as well as possible.

* Add more context sensitive help to prompt the user.

~Brian




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Brian Matherly
In reply to this post by Douglas S. Blank
>> I have the impression some things are possible, some not.
>>
>> You are right that finding a report can be difficult.
>> I would stick to reorganization of the menu/reports, eg with seperator
>> (as ordering is best alphabetic in groups). We will not have the manpower
>> to reorganize good working reports so they look more alike (although it
>> is a valid
>> goal).
>>
>> Code generators is indeed not a good category, as eg gramps writes ODF,
>> and without an office suite you can also do little with that file. I
>> think it mean to the user: beware - dragons here, so more of an expert
>> option.

>Or instead of renaming the code reports to "Expert" category, the reports in
>the code category could be folded to the non-code reports and e.g.
>"Intermediate GraphViz .dot format" offered just as an output format for
>Relationship report.

I agree that code generators is not a good category. I have already
started an effort to unify all Graphiz dependent reports under a common
interface. Right now the category is called "Graphiz" perhaps there is a better name - "Graphs"?

>Users ignore the output formats they don't understand and the reports
>remember the last used (e.g. format) options, so I think this would be
>the best option.

Right. Most users only have to try something once to decide that it is not useful for them.

>> Textbuffer is indeed an awful name. Print on it might be nice. The idea
>> now is indeed you need to copy/paste if you want to print quick report.
>>
>> Please, do a full proposition of how the report menu could be organized,
>> like that we have a basis for discussion.
>>
>> About unsupported, I don't think that is present in the official version,
>> it should only be visible in development versions if all works ok (I
>> think).
>
>Maybe:
>- Generate web site...
>+ Calendar reports >>
>   - Birthday and anniversary list
>   - Calendar
>   - Timelines
>+ Relationship reports >>
>   - Ahnentafel report
>   - Ancestor graph
>   - Complete Individual report
>   - Descendent chart
>   - Descendent report
>   - Detailed Ancestral report
>   - Detailed Decendent report
>   - Family Group report
>   - Fan chart
>   - Relationship graph
>+ Statistics >>
>  - Current person ancestors
>  - Statistics chart
>  - Database summary
>- Report book...
>
>I.e. Move "Book report" to top level as it's actually a book of reports in
>the submenus, fold code thing to Relationship chart output option,
>rename "view" to statistics and move Statistics chart under it, suffle
>others under relationship and calendar related items.  The report
>names might be change a bit too.

I agree with the "Book report" idea. It shouldn't really even be a plugin as it is tightly coupled with the report generation system.

But some other things concern me. Now, users will wonder why they can choose "Postscript" for the calendar report, but not the birthday report.

>It would be also nice to be able to get all reports (including database
>summary) into Report book for completeness sake.

For some that's possible - for example, the database summary could be rewritten to use a text document generator. But the graphiz and web reports will never be able to be included in books.

>
>The unsupport stuff could move under Tools -> Experimental if it's
>not removed.

Unsupported reports are not included in the release.

Thanks to Doug for starting this topic and everyone else for participating. I'm seeing some really good ideas floating around. Don't be discouraged by my negative comments - I'm just trying to frame in what is feasible and what is not.

~Brian




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

bm-5
In reply to this post by Brian Matherly
Quoting Brian Matherly <[hidden email]>:

>
> What I do agree with is this:
>
> * Move all the Graphiz related reports under one category (which I've
> already started working on)

Yes!

>
> * Let's nitpick the names and make sure they describe the report as
> well as possible.

Yes! Good short names, always a problem in programming. The report tool called
from toolbar could include an image. The top entry in the report menu could be
this tool. I think many users don't know the toolbar button, and have never
pressed on it.


> * Add more context sensitive help to prompt the user.

Indeed.

Something else, we have some unsupported plugins, they should fit in any new
categories created.
Eg, I wrote something that generates a kml file usable in eg google
earth. This
is in code generators. Code generators is a bad name, but we need a category
for these reports that write out a file (file.dot, file.kml, ...) with the
intention of being processed by another application (even if we can do this
processing on the fly in the background).
However, please don't break the code registration api to much :-)


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Don Allingham-3
In reply to this post by Brian Matherly
On Thu, 2007-10-04 at 05:20 -0700, Brian Matherly wrote:
> >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).

Please note that the TextBuffer interface was created solely for the
Quick Report feature. It was not intended to show up as a standard
document interface. That happens purely because it follows the GRAMPS
document interface, and gets loaded and registered automatically by the
plugin system. My recommendation is to remove it from this list. If this
is agreeable, I will do so when I reorganize the plugin system.

The Quick Report was not designed to be a general purpose reporting
system. It was designed to provide a quick display of interesting
information which may not be directly visible on the current dialog box
- kind of a selectable, super-tooltip. This is why it does not support
tables, images, and many of the other features that the regular document
system provides.

Don



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

bm-5
Quoting Don Allingham <[hidden email]>:

> Please note that the TextBuffer interface was created solely for the
> Quick Report feature. It was not intended to show up as a standard
> document interface. That happens purely because it follows the GRAMPS
> document interface, and gets loaded and registered automatically by the
> plugin system. My recommendation is to remove it from this list. If this
> is agreeable, I will do so when I reorganize the plugin system.

aha, this clears up a lot of confusion.
I agree to remove it. The gtk print preview is sufficient for previewing. The
copy/past functionality is nice, but with no columns/tables/images, that is
broken anyway.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface

Douglas S. Blank
On Thu, October 4, 2007 9:01 am, [hidden email] wrote:

> Quoting Don Allingham <[hidden email]>:
>
>> Please note that the TextBuffer interface was created solely for the
>> Quick Report feature. It was not intended to show up as a standard
>> document interface. That happens purely because it follows the GRAMPS
>> document interface, and gets loaded and registered automatically by the
>> plugin system. My recommendation is to remove it from this list. If this
>> is agreeable, I will do so when I reorganize the plugin system.
>
> aha, this clears up a lot of confusion.
> I agree to remove it. The gtk print preview is sufficient for previewing.
> The
> copy/past functionality is nice, but with no columns/tables/images, that
> is
> broken anyway.

Actually, I'd like to do the opposite of removing it: I'd like to make
this an option for all (or most, or some) reports, and be used for Quick
Reports.

Here is what I would like to try: create a gtk "report" that operates the
same way as TextBuffer but has clickable parts, supports tables (with
interactive, sortable columns), most of the rest of the docgen options,
and also be able to be printed.

I would like to have a prototype in place for GRAMPS 3.0 alpha.

-Doug

> Benny
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>


--
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface (long)

Douglas S. Blank
In reply to this post by Brian Matherly
On Thu, October 4, 2007 8:20 am, Brian Matherly wrote:

> Doug (and everyone),
>
>>I've been using GRAMPS for a few years now, and have found most of GRAMPS
>>pretty intuitive. However, one place that I have always been confused is
>>the interface to the reports. One reason I'd like to have a better
>>interface to the reports is that it may end up being *the* interface to a
>>few things I'd like to add to GRAMPS.
>>
>>So, in the spirit of looking at the interface critically and then making
>>it better, I offer some points where I have gotten confused, and some
>>suggestions.
>>
>>First, I suspect that users usually either have an idea of a particular
>>kind of report that they would like to run (something to show 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.
>
> Currently, the reports are (roughly) categorized by the method used to
> generate them. It might seem arbitrary to a new user, but after learning
> about the various options that Gramps has to offer, it comes to make a lot
> of sense (with some exception).
>
>>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.
>
> What determines the output options is the method used to generate the
> report. The "Graphical" reports use the "DrawDoc" interface (with the
> exception of the relationship graph). Therefore, all "Graphical" reports
> have the same options available for output format (PDF, ODF, PS, etc).

Yes, but my point was: who thinks about that first? Let's try to match
user's expectations.

>>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).
>
> In my experience, if a user doesn't understand a feature, they learn
> quickly to stay away from it. I expect that Aunt M would try the
> TextBuffer format once, find it to be not useful for her, and never try it
> again.

Sure, but what if we tried to make TextBuffer even more useful?

>>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.
>
> This could make it even more confusing. One report will provide a certain
> set of output formats, and the one right under it in the list will provide
> completely different output formats. It will seem random.

I already have that confusion. One of the things I'm suggesting is to
unify all of these formats as best we can.

>>
>>1a) 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?
>
> Unsupported reports are not included in official releases.
>
>>
>>1b) Perhaps all reports should have an example image to indicate what it
>>will look like if you run it.
>
> Or a quick link to the help page that included an example image.

Sure!

>>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.
>
> "Interactive reports" is an oxymoron. Reports, by definition, are not
> interactive. User interfaces are interactive. If a person needs to
> interact with, navigate, or manipulate their information, they should use
> a tool for that.

I'm trying to work with you guy here :) Benny says that he doesn't like
probably-alive in the sidebar filter and Don doesn't like an alive-in-year
column in the People View. I've been told: "these should be quick
reports". Ok, I'll try that. But, as you say, reports are much less useful
than the rest of the interface, because they aren't part of the
"interface". They are just reports.

But wouldn't it be cool if you could see a calendar "report" on the
screen, notice that a person's birthday is wrong, click on their name, and
be taken to their data in the main screen? Every report could be an
interface. I think it will be very useful, and maybe even warrant a name
other than "report".

>>3) After the report is displayed, all reports should then have 3 options,
>>"Options", "Print", and "Export"---and you can do each multiple times.
>
> But the options are required before the report can be generated. Also, we
> can't provide an exact preview of how Openoffice will render a report If
> the user selects "ODF" as the output format. Openoffice might make
> different pagination choices than we do. So at best, the preview would be
> an approximation of the final export depending on the output format.

Fine, I'd be thrilled with an approximation!

>>3a) Options could be changed, and the report would refresh the screen.
>
> Be warned: some reports take a long time to generate.

I have some ideas on that, but is an implementation detail. (The rendering
of a report is completely independent of the output device. It would be
very easy to save in memory the rendered report in an abstract "report"
format, so that it could be re-rendered to another device (or screen).)

>>3b) Make it so that you can print all reports, even those that originally
>>just went to the screen.
>>
>>3c) Make the export options the same (or mostly the same) for all
>> reports.
>
> Some reports use Graphiz to render the report. No matter what we do,
> Graphiz will never be able to export as ODF. Not only that, but it uses a
> completely different method to generate PDF than the text reports (for
> example). This is just one example of how this might be mostly out of our
> control. And how would it make sense to export the Narrative web report as
> PDF?

The user doesn't need to know some of this. We won't export the "Narrative
Web report" as PDF, but you might export the "Narrative Report" as PDF.

(On a related point, I think each main view (Relation, People, etc.)
should have an associated report, and a print option. You can export now,
and then print, but we can make it easier and more intuitive.)

>>Now, I'm not sure what it would take to implement all of these, but some
>>are surely easier than others. I think most of this hinges on #2, which
>>would be a rendering in gtk objects of a report. Hard, but possible, yes?
>>
>>Perhaps these ideas will spark other ideas on improving the report
>>interface. Just thinking out loud...
>>
>>-Doug
>
> While I agree that your ideas sound like a great improvement, I'm very
> skeptical about the feasibility of most of them. Different reports work
> differently because they have different uses cases and different
> technology generating them. There are certain aspects of them that simply
> can not be unified. I think Aunt M is smart enough to find and use the
> reports that she finds useful and ignore the ones that she doesn't.
>
> What I do agree with is this:
>
> * Move all the Graphiz related reports under one category (which I've
> already started working on)
>
> * Let's nitpick the names and make sure they describe the report as well
> as possible.
>
> * Add more context sensitive help to prompt the user.

I'm going to think outside the box for a bit more...

-Doug

> ~Brian


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface (long)

bm-5

> I'm trying to work with you guy here :) Benny says that he doesn't like
> probably-alive in the sidebar filter and Don doesn't like an alive-in-year
> column in the People View. I've been told: "these should be quick
> reports". Ok, I'll try that. But, as you say, reports are much less useful
> than the rest of the interface, because they aren't part of the
> "interface". They are just reports.

Ok, this is not directly related to the original subject, but I feel
obliged to
react.
I understand your gripe. However, as I remember the discussion: for probably
alive you need a year: 'Probably alive in <year>'. A quick report has no
interaction before construction, so you cannot set the year, so a quick report
is out.
You can do a report where year is an option, or a custom filter where year is
the input. The advantage of a report: you can give more info, so not only that
a person was alive, but his age. I can understand that you want to run such a
report on the textbuf, as it is lookup and throw away. However, the gtk
printpreview can serve the same function, and print is a click away.

We rejected derived columns for the views for several reasons. I didn't
want to
add extra boxes to the filter sidebar as a general solution to quickly edit
custom filters is needed, instead of cluttering the filter view.

I do have an idea on how to realize the quick edit of a filter, but not
the time
to implement. I try to get 3.0 finished up and 2.2.8 bugfree.

About the interactive TextBuf, I suppose you can implement a derived class for
this, that specific reports could use. We plan to implement active objects for
all primary objects for 3.0, which would be usefull for this.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Objects? (was Report Interface)

Douglas S. Blank
[hidden email] wrote:

[snip]

> About the interactive TextBuf, I suppose you can implement a derived class for
> this, that specific reports could use. We plan to implement active objects for
> all primary objects for 3.0, which would be usefull for this.

What are "active objects"? Can you point to an example, or discussion?

-Doug

> Benny


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface (long)

Brian Matherly
In reply to this post by Douglas S. Blank
Douglas,

>>>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.
>>
>> This could make it even more confusing. One report will provide a certain
>> set of output formats, and the one right under it in the list will provide
>> completely different output formats. It will seem random.
>
>I already have that confusion. One of the things I'm suggesting is to
>unify all of these formats as best we can.

Right. I can agree with that. But what I'm saying is that they are probably about as unified as they can get with the exception of the Graphiz based reports - which we are working on.

>> "Interactive reports" is an oxymoron. Reports, by definition, are not
>> interactive. User interfaces are interactive. If a person needs to
>> interact with, navigate, or manipulate their information, they should use
>> a tool for that.
>
>I'm trying to work with you guy here :) Benny says that he doesn't like
>probably-alive in the sidebar filter and Don doesn't like an alive-in-year
>column in the People View. I've been told: "these should be quick
>reports". Ok, I'll try that. But, as you say, reports are much less useful
>than the rest of the interface, because they aren't part of the
>"interface". They are just reports.

Who said reports are less useful? They are less useful if you are
trying to navigate or edit data, but that is NOT what reports are for.
Reports have a very specific purpose - to allow people to get their
data out of Gramps. That's it. Not navigation, not editing data, just
getting data out in a human readable format.

>But wouldn't it be cool if you could see a calendar "report" on the
>screen, notice that a person's birthday is wrong, click on their name, and
>be taken to their data in the main screen? Every report could be an
>interface.

I like the idea of what you are proposing, but PLEASE stop calling them reports. Call them "navigation tools" or "exploration tools" or "context sensitive data explorers" or anything other than reports.

>I think it will be very useful, and maybe even warrant a name
>other than "report".

Yes! Please use a different name. What you are describing really is a tool. Some of the existing tools in Gramps have export options that allow the user to export the data they have been viewing with the tool. For example: run the event comparison tool. It has an export option (Save As...).

>>>3) After the report is displayed, all reports should then have 3 options,
>>>"Options", "Print", and "Export"---and you can do each multiple times.
>>
>> But the options are required before the report can be generated. Also, we
>> can't provide an exact preview of how Openoffice will render a report If
>> the user selects "ODF" as the output format. Openoffice might make
>> different pagination choices than we do. So at best, the preview would be
>> an approximation of the final export depending on the output format.
>
>Fine, I'd be thrilled with an approximation!

Done. We have print preview for most reports.

>I'm going to think outside the box for a bit more...

We need that. I think you're doing a great job. Keep it up.

~Brian




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Report Interface (long)

Duncan Lithgow-2

On Thu, 2007-10-04 at 21:57 -0700, Brian Matherly wrote:

> Who said reports are less useful? They are less useful if you are
> trying to navigate or edit data, but that is NOT what reports are for.
> Reports have a very specific purpose - to allow people to get their
> data out of Gramps. That's it. Not navigation, not editing data, just
> getting data out in a human readable format.
And I am rather very particularititiously gratly fond of them. How else
do I check my data with my 90 yr old grandparents? Send them a CD? (they
wouldn't know how to log in to a PC)

So many thanks Brian and all who work on reports.

Duncan
--
Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Loading...