The Gallery for the Citation of the Event is printed if and only if the volume/page field or the date field is non-blank.
This is an extremely restrictive requirement, that frankly is buried. Wouldn’t most users expect content to be automatically INCLUDED in reports with no such references rather than EXCLUDED?
I strongly suggest that a development philosophy with a more permissive (include more content) rather than restrictive should be used. Include ALL content unless is is excluded by privacy or other boolean. We all have photos with no real source reference, nor really need a source reference to be included.
The permissive or inclusive design philosophy would put everything in the report that wasn’t excluded by a checkbox or other means. Casual users would get a more friendly experience. There could be a global configuration item to “Exclude content without a source reference” for those who are particular about this.
It important to note that the affected report is an add-on. So the contributor built it to suit their own desires, then kindly shared the code with the community.
I suspect that they used used Citations without those 2 basic attributes (Date or Vol./Page) to store unconfirmed citations.
Or that they HAD no Citations without the attributes and did not have a need to design a report notation for Citation that lacked differentiating data.
The Gramps core supports many approaches to most tasks. So most everybody has idiosyncratic styles of recording their genealogical data.
Because add-ons often evolve from a personal toy, it is frequently the case that guidelines were only given cursory attention. So new add-ons often need rework to addition to add flexibility & conformance.
Fortunately, the contributor of this report has been open to making changes.
As noted, I’m noob to Gramps so I could be miss interpreting some things.
The effort of developers and maintainers and contributors is GREATLY appreciated.
I think many software programs would benefit from a NOOB mode where a good working config would get >50% of new folks on the right path.
That’s a good point. And the 5.2 developmental version already has a significant member of enhancements specifically targeted as easing the initial user experience.
But those features would not receive as much testing in our normal beta cycle as the advanced features. (The people knowledgeable enough to install the development code are obviously past being able to see the feature with ‘new’ eyes.) So Nick has been talking about encouraging a broader spectrum of users to test the next Beta test cycle.
I use KiCad and FreeCad, both have nontrivial learning curves. It is important to consider not only that a feature exists, but whether it is enabled by default. Something 3 levels down in menus will never be found by a noob and may be a challenge for experienced users.
That’s exactly what a good number of enhancements are about: raising visibility of features just as as the newbie needs them.
The defaults are part of that reevaluating in this next beta. And they are why we need to cast a broader net for the beta test.
If we pitch a UX beta test to a motivated community (like one or more of the Genealogy Technology groups on Facebook), we could get a LOT of targeted feedback. We’d also take a lot of the usual troll fire… but that’s unavoidable these days.
