Re: [lmi] tasks 2007: bug 105588, 105589 and 105590: supplemental-report

[Greg Chicares]

On 2007-2-16 12:24 UTC, Evgeniy Tarassov wrote:
> -----------
> Explain supplemental-report columns
> http://savannah.nongnu.org/support/?105588
>    Supplemental reports should say what each column means. A brief
>    list of definitions would work. A "loan repaid at death" column,
>    e.g., could use a note explaining whether it includes interest.
>    IRR columns generally treat net outlay as the payment stream; that
>    should also be documented. This would make illustrations easier to
>    understand and harder to misunderstand.
> 
> Just some thoughts: today's lmi calculation summary is represented as
> a table with a column per value requested, it would be difficult to
> squeeze column desciption into the same column (as a first row or as a
> last row), therefore it should be probably added as a separate table
> (legend?) after (or before) the calculation summary.

Yes, exactly. It should be a legend, on a different page. It would
explain each selected column; columns that aren't selected require
no explanation. It's better not to explain columns that aren't
selected, because over time we'll accumulate a very large number
of selectable columns, and we don't want to print lots of unneeded
information.

Let me clarify this further. The calculation summary itself shouldn't
have any such legend. The legend would appear only on the xsl-fo
output. That's what the users had in mind.

> One requested
> feature is to support multiple calculation summaries -- would not it
> be simplier to add such a legend as an annexe to the entire output?

I think there are several different "multiple" requests.

(1) One request is to store and reload multiple calculation summaries
(which don't need this legend at all).

(2) Another is to store and reload multiple supplemental reports, which
should have this legend--but only when printed or previewed via xsl-fo.

[Calculation summaries and supplemental reports are both mainly sets
of columns, but they're logically distinct from each other and serve
different purposes.]

(3) Yet another request is to permit more than one supplemental report
in the same xsl-fo output. That's where it becomes useful to print the
legend as a single annex, one annex per xsl-fo output file. Instead of
an output file consisting of:

  basic illustration
  supplemental report 0
  annex 0, describing each column in supplemental report 0
  supplemental report 1
  annex 1, describing each column in supplemental report 1

a single, unified annex is preferable:

  basic illustration
  supplemental report 0
  supplemental report 1
  annex describing each column in supplemental reports 0 and 1

because it takes less space and avoids repetition.

> For calculation summary we could show tooltips (or something similar)
> for column headers, or maybe to make supplemental report headers to be
> links pointing to an online page describing columns.

The calculation summary doesn't need to explain its columns.
Only the final output printed via xsl-fo should include such
explanations.

> Also generation
> of such an annexe describing column meaning could be an external
> document or an optional feature (a checkbox on the supplemental report
> tab).

Those are good ideas in general, but I think the problem domain
dictates the solution: the annex should not be optional, and it
should be part of the same single document generated by xsl-fo.

> -----------
> Allow multiple supplemental reports
> http://savannah.nongnu.org/support/?105589
>    An illustration can have only one supplemental report today; more
>    should be allowed. For example, a COLI case with distributions may
>    need a distribution report and a cash-flow report. Running them
>    separately is not a good option: they'd have two signature pages,
>    and they'd be mostly redundant.

This is the case I labelled (3) above.

> UI: Coupled with the next feature it could be implemented as an
> additional list on the supplemental report tab. Such a list would
> contain predefined supplemental report set names.
> XSL: it will be necessary to slightly modify xsl templates to allow
> arrays of column sets as input.
> Plus changes to the code to handle lists of sets of strings (probably
> to extract column set as a separate class/structure?)

C++ and xsl changes would simply be whatever the problem requires.
As for the GUI, I haven't given it much thought...maybe we'd want
to remove the current supplemental-report tab from the input
wxNotebook, and replace it with a simple selection of any reports
that the user has saved (or that we provided in the system
distribution)--then move the current supplemental-report GUI into
a new supplemental-report editor. (Or design a completely new GUI
for that editor.)

> -----------
> Save and retrieve supplemental reports
> http://savannah.nongnu.org/support/?105590
>    Let users save and retrieve supplemental reports they design. It
>    is inconvenient to select columns manually.
[...]
> For me the supplemental report column set represents a type of the
> output desired by user and not a particular instance of a document.

Yes, exactly. Today, it's conflated with the document, and that is
not ideal; we should separate these orthogonal concepts.

> Should not it be saved in some sort of persistent storage on the user
> machine

Yes.

> (configurable_settings? or another file containing personal
> user settings)?

I think separate files would be better: 'configurable_settings.xml'
is big enough already, and what we're discussing here isn't really
a matter of configuration--it seems better to think of it as
creating and managing supplemental report templates. (By "template",
I don't mean xslt--I just mean "exemplar" or "pattern".)

It is likely that we'd provide some such templates by default, as
part of the distribution, and then allow users to add their own as
well. On a *nix system, I guess that'd be /var vs. /usr or /opt .
The ones we provide might be read-only; instead of modifying them
directly, users could "clone" and save them, with modifications,
using a "Save as" facility.

> In UI it could be implemented as a an additional group
> of controls on the supplemental report tab. Something like:
> 
> |v|----Cash-Flow-|   |save+set|   |delete+set|
> 
> |v|--Column-1|
> |v|--Column-2|
> |v|--Column-3|
> |v|--Column-4|
> 
> Where the 'Cash Flow' drop down list represent a supplemental report
> column set name, and two buttons 'save set' and 'delete set' do save
> and delete currently selected set. That drop-down list should allow
> free modification of its current value so that new sets could be
> created by enetering a new label into that drop-down control and
> pressing 'save set'.

I'm not sure. What would the best GUI look like? Off the top of my
head, I would think of using "File | New | Supplemental report"
with corresponding "Load", "Save", and "Save as" options. That
would take care of |save+set| above; for |delete+set|, we could
just let users delete the file in whatever way is natural on their
platform. IOW, why not just treat these templates as ordinary files?
The system is kind of file-centric already, and the product editor
makes it even more so; I see that as a Good Thing.

A GUI for editing a supplemental-report file doesn't have to look
exactly like what we've got today. In fact, better ideas could
probably be devised: the present comboboxes are unwieldy. The
problem arises often enough in various applications: choose some
reorderable subset of a list of strings. Maybe we should figure
out one really good way to do this, and make it part of wx; I'm
sure others could use it.

> Such an information could be stored in configurable_settings as it is
> done for calculation summary columns set, or in a new file.

A new file is better. One new file for each set of columns sounds
best to me. And separate sets of files for supplemental reports
and calculations summaries.