Family Historian User Group

[request withdrawn]

ID:4188

Personally I make different use of all those items and would be loathed to lose any of them.

Flags are switches and control diagrams etc.

Lists can have extra text attached for To Do lists.

Just because you don't want a feature does not mean it should be removed.

[message withdrawn]

I agree with Jane on this.  Given that the Individual record is the fundamental building block of any tree, it makes sense for FH to have its present Flag functionality which applies only to Individuals.

The use of Keywords to facilitate filtering of multimedia is also a useful new facility in version 4, but I cannot understand how it could be used for other record types.

Lists are implemented quite differently from Flags and Keywords: there is no field added to any record to indicate list membership.  Each List is maintained separately in the GEDCOM file and contains none, one, or many record IDs.  Any type of record can be added to any List, with or without an associated note.

The standard GEDCOM flag REFN is already used for all six of the main record types, for the field labelled 'Custom Id', and I can see more difficulty than benefit in trying to use it to do the existing disparate work of Flags, Keywords, and Lists.

[message withdrawn]

Sarah, you're not out-voted. I too agree that having all types of records flagable and listable and keywordable would be a nice thing to have. I have already put in a request for a similar feature, though mine wa a request to allow all types of records to be flagged. See #371 'Allow Flags on all records, not just individuals' at http://www.fhug.org.uk/wishlist/wldispl ... lwlref=371

All types of record are already 'listable', i.e. can be added to any List, even the Header Record.

[message withdrawn]

I've only just picked up on this thread, and realised that I said (or at least meant) exactly the same thing in a small part of my recent rant about usability on another topic... so Hear hear Sarah. Why have two (or more) different ways of having to think about doing essentially the same thing in different contexts. I think 'lists' is probably a more meaningful term (to most potential users) than 'flags' though. It seems a pity that lists weren't extended to do what flags do now rather than inventing a whole new concept. And I've never really found a use for keywords, but sure, they're just another way of doing the same thing, that is categorising records for whatever purpose. It gets my vote.

There is also the _Type tag used to categorise source types which could be argued is similar to having a flag/list/keyword. I do agree that there seems to be a variety of different functionality could have been combined into one mechanism which would have simplified things for Calico as well as the users.

So rather than having a flag called '1881 UK Census' applied to each individual it would be a list called '1881 UK Census' with each individual a part of that list. Similarly rather than having a _Type applied to a source as 'Birth Certificate', a list 'Birth Certificate' could have been created with each appropriate source a part of that list. I don't use keywords, but again each keyword could be a list with the appropriate multimedia added to the list.

Yes this makes sense to me and does seem a very good suggestion unless I'm missing something obvious.

Nick Walker said:
...
So rather than having a flag called '1881 UK Census' applied to each individual it would be a list called '1881 UK Census' with each individual a part of that list. Similarly rather than having a _Type applied to a source as 'Birth Certificate', a list 'Birth Certificate' could have been created with each appropriate source a part of that list. I don't use keywords, but again each keyword could be a list with the appropriate multimedia added to the list.
...

How would this work with diagrams where flags are used to customise the appearance of boxes?

[message withdrawn]

Gerry Newnham said:
How would this work with diagrams where flags are used to customise the appearance of boxes?

A flag is a true/false value: you either have a flag or you don't. The same applies to list membership: you're either in the list or you're not. So there's no difference really.

I'm not suggesting this would work as it currently stands, I'm just agreeing that it would be easier if these different mechanisms were merged.

I'm sure Nick is probably correct that, logically, Flags for Individuals and Keywords for Multimedia could be implemented by the List mechanism.  However, this would deprive interested users of the ability to view or edit Flags or Keywords directly in the GEDCOM file, since they would no longer appear as fields linked to the relevant records. Currently Lists are only really usable with the Records Window, whereas Flags and Keywords can also be used straightforwardly in the relevant Property Boxes.

Peter,

It's not about how it's implemented in the data, but how it's presented to the user. If there are arguments for using the flag mechanism (though personally I would never edit the Gedcom except in case of dire emergency), then fine, use the flag mechanism to represent list membership. It shouldn't matter to the user.

I for one would like to vote for this in principal... Can it be un-withdrawn or has someone got to start it all again?

Chris, if you have the time, could you create a new Request from the bones of this one, I will then be happy to move it over to the main list when I have do the next batch.

PeterR said:
However, this would deprive interested users of the ability to view or edit Flags or Keywords directly in the GEDCOM file...

I always feel that if a user has to resort to editing a program's data outside of the program than that program has failed in providing the user with the required functionality. That said, no matter what the data format is for a particular program, it should be published to allow support programs to be written to complement and enhance the original program. FH fails on both aspects - it forces the user to edit/view the file occasionally through missing/awkward functionality and it doesn't publish it's data format. It does use Gedcom which is published, but Calico Pie hasn't published it's extensions - developers have had to reverse engineer the extensions.

Attempting to pick up on a list for which the original post has disappeared, but here goes... Note also I'm not an experienced user.

My current thinking is that both flags and lists are useful, and the key is to think in terms of what users are likely to be doing, and what might offer the most straightforward & easy user interface. If any development is required in FH, its possibly to have better integration between flags & lists.

By way of example to support the use of both, my own use of flags includes a flag (and associated lists) for 'believed alive'. The flag is used to tag individuals who have undefined birth / death dates, but whose other information suggest they are probably alive. The use is when publishing to the web, when for these individuals, I remove details that ought not to be made public. I then copy individuals with the flag to a list. The benefit of the list feature is that I create multiple lists over time, so forming an audit trail of my manual setting of flags, and allowing me to revert to a previous list if at any time I make an error. This approach might not be the most elegant, but avoids having multiple flags (which might be confusing to some).

In summary, I believe both are extremely useful, and concur with Chris - its not about the technical solution, but about presenting an easy to use interface.

regards,
Dave.

Jane said:
Chris, if you have the time, could you create a new Request from the bones of this one, I will then be happy to move it over to the main list when I have do the next batch.

I think it would be a pity to start a new thread and lose track of all the comments on this one. I think the request should read something like:

A single mechanism to incorporate he functions of Named Lists, Record Flags and Keywords

Chris Bowyer said:
A single mechanism to incorporate the functions of Named Lists, Record Flags and Keywords

I'd add Source Types to this list too.

Cheers

Nick

I'm not quite so convinced about types in general, the difference being that they're typically mutually exclusive... i.e. a record has a single type (in any particular category), but as many flags (or list memberships) as you like. But that's not really a reason not to consider them in terms of user consistency.

I agree with Dave's comments above (as well as with Jane's on 02/12/09).

For completeness I suppose one could also add Marriage Status into the discussion.  As Chris said above about Source Type, a Family can really only have one current Marriage Status, but can belong to any number of Named Lists.

I have not yet seen any possible benefit for users (much less been convinced of any) in the suggestion of somehow merging the separate mechanisms currently in place.

Chris Bowyer said:
I'm not quite so convinced about types in general, the difference being that they're typically mutually exclusive... i.e. a record has a single type (in any particular category), but as many flags (or list memberships) as you like. But that's not really a reason not to consider them in terms of user consistency.

Exactly, there's no particular reason for a source type to be mutually exclusive, I suppose if you had a source which was a book of baptisms and burials you could mark it as being type 'baptism' and type 'burial'.

PeterR said:
I have not yet seen any possible benefit for users (much less been convinced of any) in the suggestion of somehow merging the separate mechanisms currently in place.

There have been people requesting flags for other types of records (e.g. sources, family records, etc.). Clearly some people use flags to, for example, mark individuals that they need to research further, while others will use lists. Using flags has the advantage that you can show icons in a tree very easily, but then you can't record the extra information about what you need to research like you can with a list. So then to get round this people will use both list and flag to mark the same thing which can lead to inconsistency and generally is just more complicated. Hence the suggestion to merge these facilities.

If you're going to merge the list and flag concepts then this means that effectively multimedia can be flagged (as multimedia can be added to a list) and as this is similar to the keywords feature then keywords could also be merged with flags and lists. The same argument applies to Sources and source type, if sources can be flagged what's the point of the source type?

If I'm honest I have no major bee in my bonnet about this, I don't use lists or source types or keywords particularly, but when this idea was suggested I felt it was very neat and made sense.

As mentioned briefly elsewhere (http://www.fhug.org.uk/cgi-bin/index.cg ... y&num=4181) the Source record already has additional fields and sub-fields in FH.  These are Data, Events Recorded, Date Period, and Place; (it is this Place field that doesn't work like other Place fields in FH, for no apparent good reason). From the GEDCOM Standard:

EVENTS_RECORDED: = {Size=1:90}
[
, ]
An enumeration of the different kinds of events that were recorded in a particular source. Each enumeration is separated by a comma. Such as a parish register of births, deaths, and marriages would be BIRT, DEAT, MARR.

I much prefer to use standard GEDCOM facilities where possible, as in this case to record the type of events covered by a particular source, rather than an FH extension or (even worse in my opinion for this sort of thing) list membership.  Unfortunately (and as I also mentioned to Simon) FH doesn't yet implement Events-Recorded properly - as you can see it allows only a single value (correctly constrained) rather than a comma-separated list.

As you probably gather, I think there is considerable merit in using Flags, or other extensions (Source-Type, Keyword, Marriage-Status, etc.) for information which is intrinsic to the record to which it is attached, and in using list membership to provide a means of grouping essentially arbitrary sets of records, e.g. for 'Work in Progress' or 'To check at RO'.