Roughing in a Tree with the Pedigree chart & Gramplets

Ideas
1

After watching Ed Thompson trying to use Gramps to quickly rough in a tree, I realized that I’d never used the Charts in that way. It was intriguing … but the entry workflow he tried was awkward.

So I wondered if a complement of Gramplets, used in combination with that View mode, could be used for a lot more efficiency.

Here’s the configuration I came up with:

image
image1593×879 168 KB

The Bottombar gramplets were the surprising part.

The Biography QuickView is a great way to proofread & to determine how complete a Person’s data is. (And it makes it easy to select all, copy & paste it into an eMail!)

You can highlight any of the text (sources, places) and drag that chunk of text to fields in the Data Entry gramplet — without hassling with the copy&paste keybindings that frustratingly call up the Gramps clipboard.

The Note gramplet can be used as a scratchpad in a similar fashion. You can scrape biographical info (or an obit) from a website, paste it into the Note scratchpad, then select and drag snippits of text to fields in the Data Entry gramplet. (You can also drag a Pedigree box to the Note. This will populate the Note scratchpad with the person’s name, birth date & place, death date & place. Useful when you want to copy places & cemetery data from one family member to another.)

When you’ve structured the data, you can still save the scratchpad as an actual Note and attach that to the Source. For any data that doesn’t fit in Names, Birth & Death fields provided by the Data Entry gramplet, you can still open the Event Editor. Double-click the Pedigree box for the Person (or Family) and drag the data to the appropriate other types of events.

Things that could speed up roughing in a tree:

  • a 3rd row of Events for Burials in the Data Entry
  • clicking on a blank pedigree box redefine the relationship to active person & gender to match that of the clicked box.
  • re-configuring the Sources fields to use a Sole Source but allow different Citation Date & Page fields for each Event
  • vertical scrollbars for the bottombar gramplets
  • a way to minimize the text decoration toolbar in the Note gramplet (It eats a HUGE fraction of the bottombar space)
  • eliminating the Save & Cancel buttons in the Note gramplet (possibly by having a Clipboard icon that saves the Note object & opens the clipboard with that object. You can drop it on any object)
  • separating the fields for date & place in the Event rows
  • +/- controls in the View for zooming the Tree size configuration option
  • being able to see the great-grandparents level, a Spouse & Offspring boxes simultaneously
  • a highlighted placeholder box drawn in the position described by New Person “Add relation” in the Data Entry gramplet. (Verify the person will go where you expect!)

There are other things that would help… but would have longer lead-times because they go beyond re-arranging features that already exist.

I wonder if a new View mode that prohibits the configurable Gramplet bars might not be a good idea for something like this. Then the modules could be tied together more tightly in their own frame. (Like tab to another field and then double-click a word which copies the text to that selected field. That would eliminate the fine motor control needed for a drag’n’drop. Almost a tool like the Eyedropper in GIMP. But instead of grabbing a color from a pixel, it’d pick up the text/data. That could even pick out the object-type of data that matches the destination field from any object being clicked too.) Limiting the swapping of Gramplets would also preclude the slow-downs of resource hog gramplets from creating latency in the data-entry.

Try this combination and see if it makes a workflow that completely bypasses the learning curve. It needs a few people beating it up.

2 Likes
2

One issue is that this Gramplet is an addon and not built in.

3

It could also be a 2 second delay for autosave on edit, that way most people would not experience loss of edit at all.

4

Well, although the Data Entry Gramplet has a LOT of really nice functionalities to bypass the dialog’s popping up all over the place, it could use a bit of refining anyway. (And the ‘Biography’ Quick Report is also an add-on.)

I’d think of it as more of an inspiration than a final.

The concept that it can ‘Copy Active Data’ (name, source, dates, places, gender) in a single action is cool. And it really speeds up sibling entry. But the interface could be visually simplified with a drag’n’drop functionality… to eliminate the awkwardly named button & that 2-person-editing-at-the-same-time ambiguity.

The combination of a combined date & place text field it a step toward a natural language parsing functionality. Very cool. But it sacrifices the date validation feedback (red highlights for bad dates) which reduces typos.

The ability to create a new place or recognize a complete (or partial) hierarchical Place tree match a (without popping a couple of Place Selection editing dialogs!) is automagically
fantastic. Pure genius.

But the interface would be even better if it had some interactive breadcrumbing features. But that’s a WHOLE different discussion.

5

That’s an interesting thought. But I’d worry about accidentally creating bunches of Notes not referenced by anyone. Or dozens of Post-It style notes that would be hard to organize.

Gramps doesn’t have any other place with Scratchpad functionality. You have to ‘commit’ each object-specific snippit of data to an object before moving on to the next record. So it’d be a loss to give up that ‘commitment phobia’ flexibility of a Scratchpad.

The Data Entry Gramplet is different in that you compose a bunch of records simultaneously before commiting to any of them. You can create a Person, a relationship, 2 Events, 2 Places, & 2 Sources all in a single commit. (Adding burial Event would cover the final in the standard set of 3 rough-in items.)

But your point about all that data being at-risk during composition wasn’t something I’d even thought about. That’s a consideration to be pondered!

6

That’s easy, just a byte count or word count, less than X needs to be manually saved.
or a manually checkbox, “Do not Autosave” on the GUI for the Note Editor…
Anything is possible, if there is willingness to it…

7

that would fit the Configuration options nicely rather than add screen clutter for an infrequently changed selection.

But my biggest question is: where would an ‘auto save’ attach such a Note? To the Active Person, the not-yet-committed New Person? Maybe to the Source? Does it attach at the Person level or the Event? If you switch People, does it attach to the new Person ?

That worry is why I floated the idea of a Note object that is only be created with a Clipboard button push. You might be able to drag’n’drop the Note onto a Person, Marriage or other drawn element in the Pedigree chart.

On the other hand, maybe a Scratchpad could be integrated at the bottom of the data entry Gramplet. That would combine all the ‘comittment phobic’ features together & make the bottombar available for the Biography quickview.

8

Auto Save would be a function for the Editor, not depended on where or what the Note or “whatever” was attached to…

Its a just an Editor function, just like the autosave in i.e. Zettlr, Obsidian, or a magnitude of other text/notes editor/notebook software.

Its saving the Note’s text, but it could as well have been added to any editor window in Gramps, since there is an “Editor” type for each type of Objects/Subjects in Gramps, and you can actually create individual Objects in Gramps without connecting/relation them to anything at all.

Most Editors, Text, Video, Photo etc. has some kind of autosave function for changes, some save every 5 min, some you can set to what you like, some save ANY changes and other autosave ever 2-10 sec (like Obsidian and some other Markdown Notebooks)…

It doesn’t matter what it only save what has been edited, if you have made a relation between the object, it will be saves, just as it would be saved if you pushed the save button…
There are absolutely no “Hocus Pocus” about this.
Its as simple as if you push the Save Button every few second/minute/hour.
The only difference is that the autosave doesn’t close the editor window, so that if you should have a crash or something, you wouldn’t lose any data in other Editor Windows not saved and closed…

Its up to the user to connect what ever she/he is doing, the only thing the autosave would do is to make sure you don’t lose added data.

9

Wouldn’t that work better as an adjunct to the Undo buffer? And a variant of the session log? While Undo steps are cached in memory in reverse order, this could cache to disk and match the order of operation.

New cache-to-disk session would be started after each (manual or timer driven) backup.

So, if you lost a session, you’d just load the same Tree file and play the session log back in… then probably stop at the last operation & warn if it doesn’t log a successful completion. That sort of feature would even let you step through the operations.

Ugly thought: you could probably eMail a session to another user with the same Tree. Then
THEY could step through the operation, approving as they go.

Bear in mind that this is Blue Skying. The current session log in Gramps only reports a tiny percentage of what Gramps does.

What I like about the ‘Roughing in’ idea is that 95% of the functionalities already exist in Gramps today. But it is a truism that first 95% and the last 5% of the work EACH take 95% of the projected time for completion. (Sometimes the last 1% takes another 95%!)

11

Sorry,
How something is/can/should be implemented, is something I no longer engage in.
I’m just a user that looked and hoped for a software that had or would get the feature I needed

12

May be something that make possible to save and restore right and bottom bars gramplets position and configuration to easily set that disposition too. Some kind of gramplet configuration bookmarking function. It could be installed by default with gramps installation as a proposed configuration to beginners

1 Like
13

There is a Restore to Defaults feature that does something similar.

(As Dave correctly points out, the Data Entry gramplet isn’t a built-in. So the selection of built-ins might have to be expanded with an eye towards onboarding users. As enhancements, rather than bug fixes, that sort of thing would have to wait for 5.2 or 5.3 version.)

The labeling of Toolbar icons & Navigator sidebar would also be beginner option. Since reclaiming screen space by not showing labels is an experienced user mode. And one of those is in the Themes add-on.

The Report in the Quick View gramplet that Ed stumbled across in his review wasn’t configured for the Biography either. (As a new user, he was confused why that particular data format & target person was a ‘QuickView’, unaware that the Gramplet was a shell for polling a variety of normally static reports based on the Active object. He intuitively sussed out that it was related to the Active Person. But never realized that different QuickView reports could be chosen.)

The View Configuration (separate from Preferences, separate from the Gramplet bar configuration, separate from the Plugin configuration, separate from the Themes add-on configuration, separate from Reports configuration) was one of his ‘new user’ confusions.

His summary heavy-handedly points out that Gramps is ‘highly configurable’. He says that with a sense of admiration, awe … and intimidation. He notes that new users need to make MANY configuration changes before starting to use Gramps… when they have no idea what choices do and which are necessary.

14

As the Data Entry gramplet can be used to enter parents, siblings, children, the Graph view could be more suitable as it displays them all:

image
image2162×1447 524 KB

1 Like
15

The Pedigree view has three advantages over the Graph View for Data Entry:

  1. The gramps Pedigree view mode has placeholder boxes for the next generation of Ancestors
  2. Blank pedigree form seem to be the worksheet format genealogists have been conditioned to fill in
  3. It is clean & unambiguous

It makes intuitive sense that clicking the box lets you add a Person in that relationship spot. So a GUI for relationship building probably needs a clickable box instead of (or in addition to) a descriptive label in a form.
There are natural places in the Pedigree form to add placeholder boxes for a missing spouse, daughter & son.

But I agree that Graph View’s inclusion of extended Family (spouses, sibs, aunts/uncles, cousins, step, in-laws) gives a more comprehensive overview. (Although any blended families make a very confusing & cluttered display.) I wonder how placeholder boxes could be added?

16

Just because it has been used for ages doesn’t mean it’s the best or most correct way to do thing…

A really good example for that is the gedcom format, that in many cases are directly lossy as a format.

One of the absolute primary benefits of Gramps is that things are done in a different way and that you can register and store a multitude of data/information because of it…

It’s more important to tell people of the benefit of doing things in other ways, than to stick to a really old and limited mindset.

1 Like
17

Why should our admirable variety of methodologies preclude the traditional?

2 Likes