From: Alex R. <sh...@gr...> - 2006-05-22 03:53:24
|
Hello everybody, There have been many requests in the past to enable filtering for all exports and all reports. We want to do it right in 2.2. Here's a set of questions that we don't know how to answer. If I export with a certain filter, and I have a family with husband H and wife W, and only H is matched by the filter, 1. Should this family be exported? 2. Should the other member of this family, W, be exported (versus <emtpy>/unknown/etc)? 3. Should the events of this family be exported? 4. Sources of those events? 5. Should the children of the family be exported, with their events, sources, and the whole thing? This can go on for many pages, but the main question is: how restrictive should the filtering be? Same goes with filters in reports. This is something that is hard to answer right away, so maybe we should take our time and have a nice discussion. I would like to note a couple of things to have everybody on the same page: 1. This is not the privacy issue. We have separate set of privacy controls in exports, and we're erring on the safe side there: anything that can possibly expose sensitive data is removed/hidden.=20 Instead, this is the data selection issue, so maybe erring on the "more data" side is warranted here? 2. In 2.2 there will be filters for all kinds of primary objects, not just people. In other words, it will be possible to define filters for Family, Event, Source, Place, Media, and Repository objects. So far they are planned to be used in the Views to limit the displayed data. Can these and should these be used for exports? Can we avoid having 7 menus for each object type? Please feel free to voice your opinion. This is a complex issue and we need all the ideas we can get. Thanks, Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Michael L. <mic...@ca...> - 2006-05-22 12:58:22
|
On Monday 22 May 2006 13:53, Alex Roitman wrote: > Hello everybody, > > There have been many requests in the past to enable filtering > for all exports and all reports. We want to do it right in 2.2. > Here's a set of questions that we don't know how to answer. > > If I export with a certain filter, and I have a family with > husband H and wife W, and only H is matched by the filter, > 1. Should this family be exported? > 2. Should the other member of this family, W, be > exported (versus <emtpy>/unknown/etc)? > 3. Should the events of this family be exported? > 4. Sources of those events? > 5. Should the children of the family be exported, > with their events, sources, and the whole thing? > In almost all cases I would want all 5. I have several "family interest" contact groups for which I periodically want to send updates of our common interests. For example my mother's family (BURNE) has branches in England (several parts), Australia and New Zealand. I periodically want to send a GEDCOM of just the BURNE part of my database to the contact list I have for them. I currently use a filter which will select the descendents of the common ancestor but I would really like to be able to include disconnected people in this GEDCOM (there are only a few isolated ones at the moment so I just include them as detailed person reports.) The problem is about to become more serious for my own name where I currently have two separate trees of the LIGHTFOOTs of Cornwall which I am confident that I will be able to connect, plus some isolated generations going back to the late 16th century. Being able to export all these in one lot would be very useful. I can also see the need for options to restrict what is included and would support a default of everything, but the ability to "turn off" bits of the filter so that side branches only include one generation, or just the "one name" bits if people want that. -- ================================== Michael Lightfoot mic...@ca... ================================== |
From: Sarolite <cal...@ya...> - 2006-05-22 14:49:07
|
--- Alex Roitman <sh...@gr...> wrote: > Hello everybody, > > There have been many requests in the past to enable filtering > for all exports and all reports. We want to do it right in 2.2. > Here's a set of questions that we don't know how to answer. > > If I export with a certain filter, and I have a family with > husband H and wife W, and only H is matched by the filter, > 1. Should this family be exported? > 2. Should the other member of this family, W, be > exported (versus <emtpy>/unknown/etc)? > 3. Should the events of this family be exported? > 4. Sources of those events? > 5. Should the children of the family be exported, > with their events, sources, and the whole thing? Personally, if we have to pick, I'd vote for going one step out from whoever matches your filter. That would be parents, spouse, and children. Spouse's parents or childrens' spouses wouldn't be returned, because if you go too far out, why filter at all? Best case scenario, I'd like a checkbox for this, or even a number of jumps to go outward. "Return people ______ steps removed," or something to that effect. If I said 3, it would export/return/print person, person's parents, person's grandparents, person's siblings (one step to parents, another back down to the other children, person's children, children's children, children's spouses, spouse, spouse's parents. I'd even like to see in there spouse's siblings. I'd consider sibling a direct relationship rather than indirect (both children of the same set of parents). Perhaps this is best done as a function of the filters themselves rather than a function of the export: [filter] [invert checkbox] [steps removed (defaults to 0)] [apply button]. That way you can preview what will be exported. -sarolite __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: <jul...@gm...> - 2006-05-22 18:30:10
|
2006/5/22, Alex Roitman <sh...@gr...>: > Hello everybody, > > There have been many requests in the past to enable filtering > for all exports and all reports. We want to do it right in 2.2. > Here's a set of questions that we don't know how to answer. > > If I export with a certain filter, and I have a family with > husband H and wife W, and only H is matched by the filter, > 1. Should this family be exported? No. > 2. Should the other member of this family, W, be > exported (versus <emtpy>/unknown/etc)? No. > 3. Should the events of this family be exported? No. > 4. Sources of those events? No. > 5. Should the children of the family be exported, > with their events, sources, and the whole thing? No. By default filters should do what they are defined to do. You may predefine filters in export like currently done or provide flags to add those additional people because, if exports export more people than that matched by the filter, how do you get the current behaviour back? All that said, my most common export filter is has three steps: - Select a number of start people (typically one) - Add all people related in some way to those people (typically, having a common ancestor with) - Then add spouses and their parents to the mix (because a name is barely meaningful unless we disambiguate it, this typically involves mentioning the parents). So I am very sympathetic with those who may want more data on export. But I want precise control on what I export. Of course I have no objection on any enhancement that makes life easier to others as long as what I do does not become impossible. > 1. This is not the privacy issue. We have separate set > of privacy controls in exports, and we're erring on > the safe side there: anything that can possibly expose > sensitive data is removed/hidden. It may be a privacy issue. I choose to have sensitive information in my database and I share information with several families that are related to us but not related between themselves. I have information in my database that can be shared inside a family, but would be indiscreet to leak to another family. If privacy were an all or nothing switch, I would have to remove all that from my database. I reserve the privacy flag for information that I don't want *anyone* to see, either because they are notes to myself or because they are truly toxic. Anyway, GRAMPS may be too coarse for me already. Probably what I did for my local copy of phpGedView is closer to what I have in mind. PGV already separates people in three sets: those who are shown in full, those who just show their names and those who are not shown at all. The replaceable privacy module in PGV decides where each people belongs. The standard module has many options, like whether taking into account if the person is alive or not, level of proximity to the user, level of access for anonymous users, etc. I.e., things that make sense for a web program like that. But for GRAMPS, what I think I would like is to have two filters: one to select the set of people included and another to further filter the selection to the set of people for whom full details (modulo privacy settings, etc.) are given/shown/exported, etc. But wait, I want more!!! :-) I alse want to select those people whose names are scrambled or hidden (i.e their existance is shown but not even their names are leaked). Well, maybe that's too much. I am not even sure I would use it :-) Best regards, Julio |
From: V. D. <mic...@gm...> - 2006-05-22 19:25:23
|
I will only address the last question Alex brought up: On Sun, 2006-05-21 at 20:53 -0700, Alex Roitman wrote: > 2. In 2.2 there will be filters for all kinds of primary > objects, not just people. In other words, it will be > possible to define filters for Family, Event, Source, > Place, Media, and Repository objects. So far they are > planned to be used in the Views to limit the displayed > data. Can these and should these be used for exports? > Can we avoid having 7 menus for each object type? I don't see how this would be useful. If you need a list of all sources that meet a certain condition, e.g. for research purposes, that is something you could write a report for. However, if you *export* a set of data, you're going to export to a genealogy software file format, which means, I think, that the data will be used in a program that is centered around a family tree, or at least around a set of people. Therefore, exporting data based on filters for people can be useful, exporting based on other filters probably is not. Also, I like Gramps to be feature rich, and I'm not in a position to say this, but I think it's better to focus on things Aunt Martha will use. Michaël |
From: Alex R. <sh...@gr...> - 2006-05-23 16:14:24
|
On Sun, 2006-05-21 at 20:53 -0700, Alex Roitman wrote: > If I export with a certain filter, and I have a family with > husband H and wife W, and only H is matched by the filter, > 1. Should this family be exported? > 2. Should the other member of this family, W, be > exported (versus <emtpy>/unknown/etc)? > 3. Should the events of this family be exported? > 4. Sources of those events? > 5. Should the children of the family be exported, > with their events, sources, and the whole thing? >=20 > This can go on for many pages, but the main question is: > how restrictive should the filtering be? Same goes with > filters in reports. So what we got in response was essentially the complete spectrum between "include everything", "include something", "make it an option", and "nothing but sticking to the filter". I personally tend to agree with the last option, but not completely. Here's why: Imagine H and W situation where only H matches the filter. W will not be exported. But the fact that W does not match says *nothing* as to whether their family object should be exported. A family object may contain such data as events, attributes, source references, and media references. Would we do right to make this all not appear in the export? The real answer depends on the researcher and what the purpose of the filtering is. It is possible that these data contain something interesting that should be exported. It is also possible that these data will leak information about the W (notes in family events, pictures) in which case the whole filtering W out is defied. The point is, person-based filter says nothing about the family object. So either decision will be inferring things on our part, which may or may not serve the user. Should we have a single option, indicating whether the family data should or should not be exported if a single family member matches? Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Duncan L. <du...@li...> - 2006-05-24 10:28:01
|
On Tue, 2006-05-23 at 09:14 -0700, Alex Roitman wrote: > > Should we have a single option, indicating whether the family data > should or should not be exported if a single family member matches? Does anyone using gramps have much experience of using the family 'tab' I mean not many people on this user list are running 2.1/2.2 much. Could you give some more info as to what types of issues you think this would create. Either way, I still say that making it more options means people can check the results and see if it's what they expected, if not they can alter the options. In my limited experience of writing code (php) I'd have thought that making something an option is only marginally more work than implementing it as a non-optional feature. Is python different in that regard? Duncan |
From: Alex R. <sh...@gr...> - 2006-05-24 16:10:46
|
Duncan, On Wed, 2006-05-24 at 12:28 +0200, Duncan Lithgow wrote: > On Tue, 2006-05-23 at 09:14 -0700, Alex Roitman wrote:=20 > >=20 > > Should we have a single option, indicating whether the family data > > should or should not be exported if a single family member matches? > Does anyone using gramps have much experience of using the family 'tab' > I mean not many people on this user list are running 2.1/2.2 much. Could > you give some more info as to what types of issues you think this would > create. It's the same as in 2.0.x. Look at the Marriage/Relationship editor (double-click on a spouse in Family View in 2.0.x). > Either way, I still say that making it more options means people can > check the results and see if it's what they expected, if not they can > alter the options. I don't think it is practical to have that many options: 1. Export family 2. Export family events 3. Export family attributes 4. Export family notes 5. Export family sources 6. Export family images 7. Export family LDS ordinance info and then more for members of the family that are not matched: 8. Export non-matching spouse 9. Export non-matching children 10. Export families of non-matching children ... Besides, even that many would not be enough, because you may want to export one thing in some families and not the others, and another thing in the others. So should we have this per-familiy, for each family? > In my limited experience of writing code (php) I'd have thought that > making something an option is only marginally more work than > implementing it as a non-optional feature. Is python different in that > regard? Python is better :-) But it's not about the language. It's about not overwhelming the user with that many options. I would prefer controls of the type "err on more data side" vs "err on less data side" or "export family when only one spouse is matching" and do the right thing. Users like Julio would uncheck that and strictly stick with the filter. Other users will check that and enjoy more data. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Sarolite <cal...@ya...> - 2006-05-24 17:15:35
|
More thoughts on this subject: That does sound complicated. (Sorry for top posting, btw.) If the user knows who they want to export (or for reports, etc) but is trying to match it with filters, how about manual selection capabilities? You can go into pedigree and right click, pick select person (one person), select family (person, spouse, and children), select person and descendants, or select person and ancestors. In the name list, you can click a button in an optional column (much like a flag column in email), or right click and select the person. Perhaps when you run a filter, you can pick "select all" to go from there and manually add other people. Then when you go to a report or export, you can choose "flagged people" as one of the filter options. I think that all sources should definately export whenever you export somthing with sources. Events (including LDS), I suppose, are negotiable, but in my personal preference I'd like to export a person's events with them (esspecially since births/deaths are, from what I see, going to be events rather than personal attributes in future versions). Notes are normally important. I'd say export the notes unless they're marked private. Images should be a user-selectable option. -sarolite ----- Original Message ---- From: Alex Roitman <sh...@gr...> To: du...@li... Cc: Gramps users <gra...@li...>; Gramps developers <gra...@li...> Sent: Wednesday, May 24, 2006 9:10:41 AM Subject: Re: [Gramps-users] Re: export and filters Duncan, On Wed, 2006-05-24 at 12:28 +0200, Duncan Lithgow wrote: > On Tue, 2006-05-23 at 09:14 -0700, Alex Roitman wrote: > > > > Should we have a single option, indicating whether the family data > > should or should not be exported if a single family member matches? > Does anyone using gramps have much experience of using the family 'tab' > I mean not many people on this user list are running 2.1/2.2 much. Could > you give some more info as to what types of issues you think this would > create. It's the same as in 2.0.x. Look at the Marriage/Relationship editor (double-click on a spouse in Family View in 2.0.x). > Either way, I still say that making it more options means people can > check the results and see if it's what they expected, if not they can > alter the options. I don't think it is practical to have that many options: 1. Export family 2. Export family events 3. Export family attributes 4. Export family notes 5. Export family sources 6. Export family images 7. Export family LDS ordinance info and then more for members of the family that are not matched: 8. Export non-matching spouse 9. Export non-matching children 10. Export families of non-matching children ... Besides, even that many would not be enough, because you may want to export one thing in some families and not the others, and another thing in the others. So should we have this per-familiy, for each family? > In my limited experience of writing code (php) I'd have thought that > making something an option is only marginally more work than > implementing it as a non-optional feature. Is python different in that > regard? Python is better :-) But it's not about the language. It's about not overwhelming the user with that many options. I would prefer controls of the type "err on more data side" vs "err on less data side" or "export family when only one spouse is matching" and do the right thing. Users like Julio would uncheck that and strictly stick with the filter. Other users will check that and enjoy more data. Alex -- Alexander Roitman http://www.gramps-project.org |
From: Sarolite <cal...@ya...> - 2006-05-24 17:35:00
|
Side note: My database is still under 200 people right now, so I have some idea who people are in general. This may not scale as well to larger databases, but for my purposes it would be nice to manually select people and then have those people added to a custom filter. (I guess it wouldn't be a filter at that point, then, but rather a stored list.) I have currently custom filters for each of my four major lines and two of my husband's, but each time we find new people I have to edit the filters because they're "ancestors of <me>" or "descendants of <furthest back ancestor>" plus families thereof... If I could start with the descendant and ancestor filters plus a list of people, I wouldn't have to get as creative with my filter crafting! ----- Original Message ---- From: Sarolite <cal...@ya...> To: Alex Roitman <sh...@gr...>; du...@li... Cc: Gramps users <gra...@li...>; Gramps developers <gra...@li...> Sent: Wednesday, May 24, 2006 10:15:25 AM Subject: Re: [Gramps-users] Re: export and filters More thoughts on this subject: That does sound complicated. (Sorry for top posting, btw.) If the user knows who they want to export (or for reports, etc) but is trying to match it with filters, how about manual selection capabilities? You can go into pedigree and right click, pick select person (one person), select family (person, spouse, and children), select person and descendants, or select person and ancestors. In the name list, you can click a button in an optional column (much like a flag column in email), or right click and select the person. Perhaps when you run a filter, you can pick "select all" to go from there and manually add other people. Then when you go to a report or export, you can choose "flagged people" as one of the filter options. I think that all sources should definately export whenever you export somthing with sources. Events (including LDS), I suppose, are negotiable, but in my personal preference I'd like to export a person's events with them (esspecially since births/deaths are, from what I see, going to be events rather than personal attributes in future versions). Notes are normally important. I'd say export the notes unless they're marked private. Images should be a user-selectable option. -sarolite ----- Original Message ---- From: Alex Roitman <sh...@gr...> To: du...@li... Cc: Gramps users <gra...@li...>; Gramps developers <gra...@li...> Sent: Wednesday, May 24, 2006 9:10:41 AM Subject: Re: [Gramps-users] Re: export and filters Duncan, On Wed, 2006-05-24 at 12:28 +0200, Duncan Lithgow wrote: > On Tue, 2006-05-23 at 09:14 -0700, Alex Roitman wrote: > > > > Should we have a single option, indicating whether the family data > > should or should not be exported if a single family member matches? > Does anyone using gramps have much experience of using the family 'tab' > I mean not many people on this user list are running 2.1/2.2 much. Could > you give some more info as to what types of issues you think this would > create. It's the same as in 2.0.x. Look at the Marriage/Relationship editor (double-click on a spouse in Family View in 2.0.x). > Either way, I still say that making it more options means people can > check the results and see if it's what they expected, if not they can > alter the options. I don't think it is practical to have that many options: 1. Export family 2. Export family events 3. Export family attributes 4. Export family notes 5. Export family sources 6. Export family images 7. Export family LDS ordinance info and then more for members of the family that are not matched: 8. Export non-matching spouse 9. Export non-matching children 10. Export families of non-matching children ... Besides, even that many would not be enough, because you may want to export one thing in some families and not the others, and another thing in the others. So should we have this per-familiy, for each family? > In my limited experience of writing code (php) I'd have thought that > making something an option is only marginally more work than > implementing it as a non-optional feature. Is python different in that > regard? Python is better :-) But it's not about the language. It's about not overwhelming the user with that many options. I would prefer controls of the type "err on more data side" vs "err on less data side" or "export family when only one spouse is matching" and do the right thing. Users like Julio would uncheck that and strictly stick with the filter. Other users will check that and enjoy more data. Alex -- Alexander Roitman http://www.gramps-project.org ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Gramps-users mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-users |
From: Don A. <don...@co...> - 2006-05-24 12:09:28
|
On Wed, 2006-05-24 at 12:28 +0200, Duncan Lithgow wrote: > On Tue, 2006-05-23 at 09:14 -0700, Alex Roitman wrote:=20 > >=20 > > Should we have a single option, indicating whether the family data > > should or should not be exported if a single family member matches? > Does anyone using gramps have much experience of using the family 'tab' > I mean not many people on this user list are running 2.1/2.2 much. Could > you give some more info as to what types of issues you think this would > create. I'm not sure I understand what you are saying. Could you clarify this? I believe Alex was talking about filtering data for export. I'm not sure how this relates to the Family View. >=20 > Either way, I still say that making it more options means people can > check the results and see if it's what they expected, if not they can > alter the options. >=20 > In my limited experience of writing code (php) I'd have thought that > making something an option is only marginally more work than > implementing it as a non-optional feature. Is python different in that > regard? >=20 > Duncan Language has little to do with anything. The problem with options boils down on several issues: 1) Requests for features are many. The number of developers is few. We have to prioritize what we do. Unlike some OSS programs, we have no corporate sponsorship - no one gets paid. All work is volunteer, and the developers have jobs and families. So the amount of time that developers can contribute is limited.=20 2) The number of options increases the number of cases that have to be tested. Assuming that all options have only two possibilities, you find that the number of test cases is 2^n, where n is the number of=20 options. 1 option =3D 2 test cases. 4 options =3D 16 test cases. 8 options =3D 256 cases. And suddenly the possibilities for errors=20 explodes and the code starts getting difficult due to the many possible branches. Don --=20 Don Allingham <don...@co...> |
From: V. D. <mic...@gm...> - 2006-05-24 14:33:14
|
I would like two point to Don's list: On Wed, 2006-05-24 at 06:09 -0600, Don Allingham wrote: > Language has little to do with anything. The problem with options boils > down on several issues: > > 1) Requests for features are many. The number of developers is few. We > have to prioritize what we do. Unlike some OSS programs, we have no > corporate sponsorship - no one gets paid. All work is volunteer, and > the developers have jobs and families. So the amount of time that > developers can contribute is limited. > 2) The number of options increases the number of cases that have to be > tested. Assuming that all options have only two possibilities, you > find that the number of test cases is 2^n, where n is the number of > options. 1 option = 2 test cases. 4 options = 16 test cases. 8 > options = 256 cases. And suddenly the possibilities for errors > explodes and the code starts getting difficult due to the many > possible branches. 3) There's no point in adding features and say: "if it's not what the user expected, he can always go back, tinker with the options, until it's ok". Each option that goes into Gramps should be the best solution for an existing problem. Let me clarify, because I understand this point sounds as if I'm not worried about your concerns. The problem is, it is véry easy to design features in the export & filters area that don't make sense for *anyone*. (Especially if you start thinking about the sources that are linked to a person, and point to other people as well, etc... Or this one: filter for all males, and then provide an option to include their wives and families -on export, not in the filter itself-... I guess there's a point, but it's not very compelling.) Features that don't make sense for anyone are a burden on the program and its usuability. 4) Also, even if options are included, Aunt Martha will thank you if the defaults are right for her. Therefore, options are not the end of the debate. In any case, nothing is lost by thinking about this issue... and I don't think we're there yet. Also, my views are not very relevant, since I'm quite sure I'm never going to use anything like this. This was my last e-mail about this issue written without understanding what it's about. If there will ever be a next e-mail, I promise it will bring more to the debate! :-) Michaël |