Question Choosing a GEDCOM tag from a list

Hi to everybody!

To help users, I think it would be fine if webtrees could let them to choose fact tags from the list of the standard ones, for example in the Edit options section of the editconfig_gedcom.php page.

What I'm thinking is a new page opened in the same way as the "look for an individual ID" functions, but with all data preloaded and immediately searchable (since the tag list is not so long).

To better understand what I mead I wrote a little page that implements it... Just copy it to the root of the webtrees and launch it.
It contains some note, and it should be greatly rewritten to be used in webtrees (themes support and look & feel integration), but I think it gives you the idea...
You can also show pre-selected values by passing them in the query string with a key of curTags (for example: pick_fact.php?curTags=BIRT,MARR,CUSTOM).

Ciao!
Michele

Thanks Michele. I've already added this to webtrees (only INDI_FACTS_ADD at this moment)

Not quite working fro me yet Lukasz. The list of tags in the pop-up window is empty.

This is probably related to a js error I have on that popup:

document.filterfacts.filter is undefined

Could you post what you see?
At this moment this functionality is working only for INDI_FACTS_ADD filed (GEDCOM Configuration->Edit options->Facts for Individual records->All facts). There is the keybord icon which open a new window.

Interesting idea!

We have all been using the gedcom tags for many years, so we forget that others might not know them!

Of course, not all tags can be used as INDI facts. e.g. LATI, VERS, MARR, etc.

I guess we need a list of all possible tags for each record type (i.e. INDI facts, FAM facts, SOUR fats, etc.)

Until then, perhaps just a simple filter

preg_match('/^_[A-Z0-9]+$/', ...

This will remove the "special" tags, such as BIRT:PLAC and _DEAT_CHIL

Oh, and we need to change the colours.

Nigel,
If you enter
on line 443 of find.php file does it solve the problem?

No, I'm afraid that makes no difference at all. Still the same JS error, and no tags listed.

Looking further, it seems to be theme related. It doesn't display in webtrees, colors or cloudy, but is fine FAB and xenea.

On my system it is displayed in all themes.

Try to change line 1020:

No that doesn't fix it.

The problem is on any theme that uses a dark background and white text for the style "list_label". On the pop-up it changes the background colour to pale colours, so the white text becomes invisible.

The problem disappears if you add "color:black;" to the two tags "#tabDefinedTags tr.sel" and "#tabDefinedTags tr.unsel".

But black is not the best look. It should really be different for each theme - so all this css code should be moved from find.php to the theme style sheets, something we should always try to do anyway, to be consistent.

If you already had this working on all your themes, then perhaps your theme files are not up to date?

If you already had this working on all your themes, then perhaps your theme files are not up to date?

They are up to date.

At first I thought it was broken (white text on almost-white background), but it worked for me.

No JS errors.

But I did need to CTRL-F5 to make firefox reload the .JS / .CSS

fisharebest wrote:

At first I thought it was broken (white text on almost-white background), but it worked for me.

No JS errors.

But I did need to CTRL-F5 to make firefox reload the .JS / .CSS

I've fixed the white text on pale backgound issue in svn, and the JS error has gone away. Not sure if they were linked.

kiwi wrote:

I've fixed the white text on pale backgound issue in svn, and the JS error has gone away. Not sure if they were linked.

There's no link between the css and the script code: the whole correlation between them is that the JS assign a css class name to the selected/not-selected rows.

I've added the possibility to view only the selected tags, since there are a lot of selectable items and viewing the currently chosen ones is not immediate.
In the attached archive you'll find the new find.php, based on the current webtrees-8339 (the new version is the file find-8339-new.php ).

One more thing. I've noticed a strange effect when editing, for example, the field GEDCOM configuration page > Edit Options tab > Facts for Individual records -> Unique facts field.
With the help of find.php I updated this field. After having clicked the Accept button on that page, the field has been updated.
But, if I open the find.php window a second time for the same field, the selected tags are the original ones (the ones that were set when the page was loaded), and not the ones selected by the use of find.php.

Ciao
Michele

Thanks Michele,
I've already added this patch to SVN and correct the bug with selected tags.

I love the idea of this feature, but worry that we may be introducing more complications, and a lot of new questions to answer.

Looking at the list of available tags for the INDI record for example, it lists 4 different tags that can be used for "email address". How is a user to know which is "right"?

We also have tags that (I think) should only be used in a level 2 context, not level 1; and many that are unique to certain other software packages. At the very least, I think a few more words may be needed in the "Description" column.

Greg said earlier:

I guess we need a list of all possible tags for each record type (i.e. INDI facts, FAM facts, SOUR fats, etc.)

I think thats right. Perhaps a list of "Recommended" tags (taken from the GEDCOM spec?), and leave all the others off. Any user that needs the more obscure software specific ones etc, would know what they are and be able to add them manually. The same list could include better descriptions.

On a much less important issue - I don't feel the "keyboard" icon is quite right for this, but can't think what else, except perhaps this one: Any one got any other ideas?

Your icon looks better.

I just wanted to contribute my two cents: I love the idea and initial execution of this feature. It simplifies and streamlines this for the user (beginning admin) immeasurably.

So with respect to kiwi's comment:

I love the idea of this feature, but worry that we may be introducing more complications, and a lot of new questions to answer.

Looking at the list of available tags for the INDI record for example, it lists 4 different tags that can be used for "email address". How is a user to know which is "right"?

... I would say that you're decreasing frustration, so making happier users. Keep it. As for managing the subtleties, then it's the job of the software to expose the right subset of tags appropriate to the context, and the job of the designers to explain the use of each email address tag and to suggest a default.

and the job of the designers to explain the use of each email address tag and to suggest a default.

This last point is exactly what I was referring to. At present the solution doesn't make any recommendation, or explanation. It just presents (for example) four different email tags. The system IS a great improvement. It just still needs a little more work yet.

It does look nice, but it doesn't say "keyboard" to me. And it may not look as nice in context, depending on the theme's colors and other icons.