Privacy violation caused by inability to de-select death date status

Question

I know I posted something a long time ago about the need for 1 more option on the radio buttons for birth/death date status.  Because the way radio buttons work is that they start out with none selected but as soon as one is selected, it is not possible to return to none - the only change that can be made is to select a different option.  For this reason, I asked for the addition of another option to be called "none of these" in order to effectively de-select all existing options.

The problem I anticipated has now occurred.  I discovered a profile of someone who was born in the "1920's", has no death date, and is orange privacy.  When I looked at the edit page (I'm on the trusted list), as expected, the "about/uncertain but non-living" button is selected.  I pulled out all the stops trying to find sources that either show her as having died or as being still alive, but came up empty.

This profile needs to have its privacy changed to Unlisted but that is not an option because she is designated as non-living.  All the other options are equally wrong, since nothing is known about her death or lack thereof.  I am not identifying the profile here because it should not be accessible, but I am sending email to a team member identifying it so that they can take appropriate action … that is, if they can figure out something to do that is both possible to do and also appropriate.

Comments

Maybe change the label on the 'still living' button to 'still living/status unknown?'  Negligible programming effort required.

---

In this case, status unknown is correct and still living is not correct.  A new button that says "status unknown" would be a good solution and would not be any programming effort beyond adding the button.

By the way, a sysop replied to my email in less than 5 minutes and said that the profile is now Unlisted.

---

Glad that the profile status is fixed. Now we need that explicit "unknown" option for the death date (and also death place), in order to override mistaken entries in the checkboxes...

---

When I see "still living/status unknown" That tells me either they are still alive OR if they are dead you don't know it. Seems to me that covers both options and should allow it to be unlisted? Maybe that is just too simple a solution???

---

To me, "still living/status unknown" would only communicate confusion. "Still living" means exactly that -- we are reasonably sure this person is living. "Status unknown"  means we don't know.

But when the two statements are linked together, I'm confused. Maybe it means the person is living, but we don't know their marital status...

---

I'm with Ellen on this.  We have enough things that are confusing to members without deliberately adding the ambiguity of two statements meaning different things as one single selection.

---

Steven, that's what I had in mind.  I also considered suggesting 'not proven dead,' but that seemed a bit harsh.  For somewhere it is written that we have to assume anyone born less than a century ago is alive unless proven otherwise.  Such a radio button would be consistent with that policy.

---

I draw a clear distinction between (1) people who I know to be living (or at least they were living as of two weeks ago...) and (2) people for whom I have next to no information, and I don't have a clue if they are living or dead. The first category includes known relatives and notables. The second category includes profiles I created for distant relatives or to help connect an unconnected profile to the Big Tree; maybe I have an obituary that says the person was alive in 1994, but I have no more recent information.

---

Ellen, I understand your point, but I think for privacy purposes it's a distinction without a difference.  A person you know is alive has to be Unlisted.  A person who could be alive and you can't prove otherwise also has to be Unlisted.  You can always expand in the biography, which no one will see anyway because privacy.

Adding a button might be more desirable, but changing an existing button's label is much more doable and much more likely to happen.

---

Herbert, I don't agree that changing the existing button's label is any easier than adding a new button.  As far as the needed coding goes, there is essentially no difference, since the new button is not adding an additional value to the range - it will only remove whatever is currently selected.

---

Gaile, I speak from my ancient outdated experience writing code in Fortran and C++, where changing the text inside a pair of quotes would have been an order of magnitude easier than adding and testing code for another option.  But I defer to your expertise.

---

Herbert, I'm starting to feel like a dinosaur too - been officially retired since 2005, although I've had my own web development business since then.

The way radio buttons work is that there is a field in the database record to store a value.  The possible range is whatever number of selections you put on your form (for that radio button, of course).  The field starts out with a value of zero.  When you make a selection, it's assigned value is stored in the field.  All they have to do is add the new radio button to the form, with something like "none of these" for the option description, then when that button is clicked, instead of storing its value in the field, they can convert the line of code that stores the value in the field to an if-then-else line, namely: if value=x then {fieldname} = 0 else {fieldname} = value.  Easy peasy.

---

Thank you Gaile.  The problem with radio buttons as implemented here is that they are a trap.  Once you pick one, you are stuck with the preset choices, and you lose 'none of the above.'  When radios had buttons, they didn't work that way.  Pressing a button twice would clear the selection and put you back to 'none of the above.'

How ironic that modern programmers build a function named for something they've never seen, and implement it in a way inferior to its mechanical origins.

---

It's not just how they're implemented here on WikiTree - that's the way they're defined in the HTML specification.

You're right about that trap - when I do stuff, I almost always allow ability to select a "none of these" kind of choice to restore the original unselected state, as I described above.  As you can see, it's a no-brainer to do.  An easy alternative is to use a selection box - a dropdown that has predefined values and you can include an empty selection there.  You could also use a bunch of checkboxes instead of radio buttons, but there are 2 bad things about that - first is that there is nothing stopping someone from selecting more than 1 of the checkboxes and the other is that the programming is more complicated to go through the whole range of checkboxes to see which one is checked (hopefully ONLY either none or 1), then write that value to the field, plus you have to handle how to deal with multiple selections.

Edited to add:  uh-oh … when I saved, I saw that my name isn't showing - for the record, I'm Gaile logged in to the Holocaust project account where I'm finishing up getting the Nazis out of the project.

Answer 1

Nice catch, Gaile, and I hope the powers that be will now listen to you, and find a fix for this problem.

Have a wonderful evening.

Comments

THANX,Cheryl.  it's too late here to wish you a wonderful evening - hope you have a wonderful morning!