Family Historian User Group

Quick follow-up to my off-topic comment about the Plugin Store: I've reported the issue with apparently too many results when searching for "Family", and also made the suggestion of arranging plugins into categories, or using tags or keywords to allow filtering. Calico Pie responded very promptly, a...

Many thanks, Mike - this latest version 0.6 seems just right to me, and the change of name seems appropriate.

I'll follow up the plugin store issue as you suggest.

Doesn't the Plugin Store have a search capability? "Family" wouldn't have to come first in the name. Yes it does, but "Family" doesn't seem very helpful as a search term. Currently there are said to be 76 plugins in the store, and when I tried searching for this I got 25 results, which is still qui...

PeterR wrote:It's handy that the current plugin name begins with "Q" thus allowing the use of the keyboard shortcut Alt T Q.

Having a rarely-used initial letter does help for the shortcut, but would it be easier for people to find in the Plugin Store if it started with Family?

I will try putting the (m.1789) format after each = Spouse NAME but probably only when No BMD Facts option is chosen. That seems reasonable. BTW: Now that such Spouse NAMES are always bold and often coloured, is the = prefix needed? I feel it helps, but what do others think? Are you still looking f...

Arthur, the other aspect I forgot to mention is the scroll-bars on the separate panes. Especially when there are many Siblings or Children , then their panes can be scrolled independently from the parents, whereas it is not clear how that would work in your example screenshot. Good point - one that...

Perhaps I've been a bit too dismissive of Mike's efforts - on further thought, the options regarding BMD events do help considerably in making a more compact output, so unless it's thought preferable to re-arrange things as per my suggestion, I'm happy to let it drop and leave Mike to continue on th...

Birth/Death facts seem fine in the latest version (0.5), thank you. Arthur , I suspect your layout gets more complex with facts included. Each person needs Birth/Baptism/Death/Burial, and leaves the dilemma of where to put Marriage/Divorce. I was anticipating that Birth/Baptism/Death/Burial would go...

This is coming along nicely, though I'm not getting any Birth or Death details on any of the options. Meanwhile, while you were producing this, I've been experimenting with a mock-up in Word to see if I could reduce the duplication I mentioned before. (I didn't try to replicate the outlines of the p...

Discussion has moved on a little since I was last here, but here are a few thoughts, if they're not too late: Are the letter/digit points before each person's name needed any more, now that the names are bold and coloured? No, probably not. If each person's name is moved against the margin, should t...

Thanks, Mike, this latest version makes it a lot easier to see who's who, especially the children of different partners. It would be tricky to put everyone in one pane, because then the scroll-bars would not work satisfactorily for large families. Fair enough, and if the contents of more than one pa...

I was also thinking of including Partner/Spouse details alongside the root Individual (so they would sit under Father & Mother). That might make it a bit clearer - more like the Focus window arrangement. I know this is still experimental, but it seems to me that the amount of information offered co...

I've been giving this plugin a spin, and initial impressions are that it will be a real time-saver. However, I have a couple of comments. First, one of my families is currently showing 21 children (further research might reduce this a little), and I've noticed a problem in the siblings list when the...

Brent's technique of using the [[ privacy brackets ]] is a novel one that has merit. It not only differentiates otherwise identical Addresses , so that Work with Data global changes can be made, but it automatically avoids duplicating overlapping parts in Reports . This is an idea that I came up wi...

Sorry, but life's too short. Each to her own... but it sounds like Rootsmagic has provided templates without any guidance (which is a recipe for disaster! or at the least turning people off the approach). There may be some guidance somewhere, but I started out with free-form sources and (from memor...

Sorry, Helen, I misunderstood you then. But I'm afraid I really balk at the kind of thing that Evidence Explained leads to. For example, RootsMagic, which has adopted this approach, offers no less than 10 templates for Cemetery Records. Under "Cemetery Records" are: Abstracts (card file) Abstracts (...

But if the KB Item is about Author, Publication and Repository, then I worry that we're trying to start a UK version of Evidence Explained.... Well said, that man! I totally agree with this. One of the things that attracted me to FH was that it wasn't forever pushing over-complicated source templat...

I've had a couple more thoughts which may or may not take the discussion further. First, with BMD certificates, it's possible to obtain these from local register offices as well as the GRO. The GRO work from copies sent to them from the local register offices, so it might be possible to argue that t...

Of course these days we often don't need to go to a physical Repository, and the most useful information for another researcher will often be 'which website did you find it on?' So we have to shoe-horn that into the Gedcom structure somewhere (some of us use Publication Information, some use Reposi...

Thank you very much, Mike. It would have taken me hours to get there by myself - it's quite some way beyond my current expertise.

I have created a Memorial attribute, and am trying to write a sentence to cover all eventualities. I am using the fields as follows: Place - location of cemetery etc (eg Anytown) Value - name or description of memorial (eg Smith family memorial) The following sentence works reasonably well: {individ...

Thanks for these thoughts. The Place and Date on a Birth Certificate is contemporary 1st hand data because it was recorded at the time of the event. Whereas, those details on a Census Return (or a Death Certificate ) are NOT contemporary and thus less reliable. I'm aware of the issues relating to pr...

Arthur wrote: if the conflicting place information is only in the Birth notes, the place concerned is not going to appear in the Places list. If the place is already in your Places list (i.e. there is a Place Record with that place name) it will still remain there even if you delete all instances o...

Still ploughing through an import from RootsMagic (not full-time - other things intervened!), I've come up against this old question of multiple Birth events and conflicting evidence etc. My imported data contains a number of individuals with alternative birth data. I'm not sure whether it's native ...

It's up to you, but making a more readable copy of the image you've given here is relatively easy with a free graphics/image editor, such as those mentioned in fhugdownloads:graphics|Downloads and Links ~ Graphics Packages I used to mostly use IrfanView for this kind of thing, but I now prefer many ...