Hello,
I am a self-taught python programmer and currently a college student majoring in Machine Learning / Artificial Intelligence. I have some ideas for updates to the Forms gramplet. Since I am doing a research fellowship this summer instead of an internship I will have some extra time to work with and would be interested in developing the features I have in mind.
I’m hoping to use this thread as a place to get feedback on ideas and a place to update as I progress through the development of new features.
Greater customizability of the behavior of the Forms gramplet
Mapping of form fields in the Forms gramplet to events and attributes of person records beyond just the “census” event
Template editing and creation from within the gramps interface (this would probably actually be better organized as a separate addon that simply extends the functionality of the Forms gramplet).
Specific Features I Would Like to Develop:
Dynamic selection of “Section Role” specific to each row:
Currently the form templates only allow for predefined roles to be assigned to persons in a form through the use of the “role” tag in the “section” field of the xml. This means that to allow, for instance, the roles of each individual included in a census to be added as the actual role for the census event the user must manually add new sections to the form templates with duplicate form fields but different roles. The idea would be to allow the user to select the role assigned to a person from a drop down selector of roles used in their file.
A preference menu allowing optional direct mapping of form fields from templates to gedcom event or attribute objects
Documents often contain information that can be directly applied to event definitions in Gedcom files, for instance ‘Occupation’. To maintain high levels of customizability and to prevent new users of the updated addon from all of a sudden having their trees filled with new events the ideal solution would be having form fields by default not map to any events. However, incorporating a preference selector for the Forms gramplet could provide users an option to map each form field in any of their templates to any event tag they would like that field to map to. A refresh function could then update all existing persons with attached forms to generate events based on these fields. This feature appears to have been proposed in the “Natural Transcription” GEP.
Option to disable the automatic update of the “date” field when editing census forms.
I personally like to use the enumeration date of the census as the date attached to said census instead of the default date. However, currently to change dates from default I have to go directly to the census event to change the date, and the date is automatically updated back to default each time the form is edited.
A Template editor within gramps
This one is fairly self explanatory. It could be its own separate gramplet or included as part of the Forms gramplet. It would allow Forms to be created, edited, duplicated, and saved without the use of a text editor.
I see such basic needs: 1. Multiple events
The addon can create one event only. But… When I add death, I need add two events: Death and Burial. When I add birth, I need add two events: Birth and Baptism. Or even 3,4 events if add Military Servese and Residence if additional data is available in these documents. It means, we need implement ability create multiple different events with different dates, places, types… which use ones entered data scope on a page.
As I understand, we need additional xml-tags like this:
<tabs><tab>...current xml structure...</tab></tabs>
Or maybe so:
<events><event>...current xml structure...</event></events>
2. Add drug&drop supporting
Now we need select places, people… from the list. But it is very inconvenient to use.
Whilst applauding the development and enthusiasm can I ask that this development is treated as Forms + or Forms Enhanced leaving the original alone.
Two reasons
Firstly the Forms concept is reasonably simple and encourages new users to experiment
Secondly I personally have no conceivable use for something that can enter details about multiple individual events simultaneously.
My pattern of works goes in campaigns where I will be entering a lot of census information, or a lot of births, or a lot of baptisms in groups depending upon which resources I am using to find those events.
phil
I fully support this development. If I had the time, I would have taken the Forms addon in a similar direction myself.
These enhancements should be made optional. For example, a census form may have the ability to create Occupation events from an occupation field, but it could be disabled by default. A user could open up a preference dialog to see what features are available and enable any that they choose (or none of them).
One way to make the enhancements optional would be to Fork the Forms addon… as Philip ( @comeng ) requested. (Maybe call them Surveys instead of forms?)
I have one problem with this unless all Preferences and Configuration can be saved into some form of Templates that can be used whenever a reload or upgrade of GRAMPS is required. Setting all these currently is a pain having even more would make the system demands overbearing. There is a danger here of making GRAMPS so complex/specialised you turn off casual/new users.
What about a minimalist version of GRAMPS strip it down to the bare bones (a framework/structure) that allows people to build as needed.
Zero Plugins/Addons should be the aim on the minimalist system with documents to suggest the basic needs so the new user can learn the processes needed.
phil
Since it could be two different addons, maybe it makes sence not become attached it to sources’ attributes and show unrelated forms instead of citation form as now? When it is independent on another entities, we will have ability show on the form what we wont and how we wont. For example the central entitty of the Form addon is citation. I would say we need break this limitation for the another Addon.
So, addon will be able create different entities even if no one citation should be added, but will be added something another like places, people, …
And if we need attach citation in any source, we will drug and drop that source on the form, the same as people, places, …
I 100% agree with this approach. My ultimate goal is a version of the forms addon that looks exactly the same as it does now. No changes to the underlying functionality upon immediate update.
The ideal would be the addition of menus that allow the user to change the functionality themselves if they so desire. This would make sure that anyone who is already using the gramplet and is happy with what it has to offer right now doesn’t need to worry about the updates.
Think a preferences menu that allows the user to select if they want parts of the form to be tied to new event types, instead of by default making said parts tied to events. I am hoping to come up with a mockup of what I am thinking of before I begin programming which I will post here for more feedback soon!
I will look at this as a possible direction depending on whether or not it seems best to include all this as an extension of the current forms addon or as its own independent addon.
This was the approach I took for my previous program which saved configurations. It is definitely something that I think can be saved across upgrades, as I am also not keen on having to redo all the settings across upgrades myself.
Small update: I was thinking about where the settings for the forms gramplet would best be located and I think I settled on the edit > preferences tab like the themes addon. I’m not 100% on that decision though. I would include an “Advanced Settings” button which would trigger a new window popup containing subsections of settings. I mapped out my thought process in the image attached to this post. Ideally settings could be applied to all forms at once, or the user could get down more specific with form-by-form settings.
I also have some ideas of how I can maintain full backwards compatibility with the forms addon even with added features which I will explain in more detail once I work through the specifics a bit more.
Another feature I realized I will have to consider is the “undoability” of any events created by the forms addon. That is to say: to what extent should changing a form setting (for instance if an occupation form attribute is tied to an occupation event and then untied) change events that had been created previously by that setting.
Should it be possible for the user to choose to delete the previously created events all at once? Or should this not even be an option? I believe the answer will become clearer once I get further along in the development process.
Forms is currently a Gramplet. Active Gramplets can use the Configure… to give access to a GUI for settings.
Perhaps we should discuss if the Forms would be better as an interactive Charts view. You could could have Gramplets that augment the interface… So one gramplet could a crosswalk control for selecting and tweaking of a specific form. Another could be for editing overall forms.
The gramps.ini (and the Preferences dialog) are both seriously overloaded already. Some stress cracks are starting to appear. If you can avoid it, it seems like a good choice.
An example of a “Layout” configure tab for the Pedigree view.
Another option would be something like the (massively extensive) Configuration of the experimental CardView set of view modes.
This is good to know, I think the interactive charts view could work very well. I was unsure if it would fit under that category thematically but it would be nice to have it located in the same place as most of the other gramplets.
CardView would be a good example to follow
I would like to see everything in Preferences/Configuration moved to
Templates so if there is a function you do not use or need, no
configuration is required, if you have created/modified a configuration
then need to upgrade or reload you simply reload your Templates
Narrative Web would also benefit from this approach
phil
I agree. A tab in the main preferences dialog is a good choice. We should also seriously think about integrating Forms into core Gramps at some point. They have already moved on from being a simple gramplet.
The tools menu is clearly the wrong place for preferences. Users will not expect to update settings via a tool.
The existing gramplet has a configuration tab that appears in the view configuration. It appears alongside the configuration tab for the view and any other gramplets that have are configurable. The configuration tabs are really intended to cutomise the look and feel of the view.
A Form view is an interesting idea. I was thinking of creating something similar called a Source Management view.
Try to avoid additional popup dialogs - our users are always complaining about them. A section called “General” alongside the list of forms would be one approach.
This is actually quite important. We don’t want to upset our existing users to the point where they ask for the old version of the addon to be maintained.
As I understand it, when Themes is added, it gives Gramps a new list of tabs for Preferences with Themes as the last tab. And Forms could do the same thing. But can a user install both Themes and Forms and have both new tabs added to Preferences? Wouldn’t any new Tab added by an addon need to be appended to the list of tabs in configure.py to get both (and possibly other) tabs displayed?
