Some time ago I had made an inquiry with Tess support about the possibility of altering the potential values of the gender dropdown in the application. The answer at the time was that making such a change wasn't possible in the current application, but that some consideration might be given to it in the design of the NextGen product.
This morning I came across a blog post from one of the developers on the Diaspora project. (Diaspora is intended to be a Facebook-esque social network in which the backbone consists of "nodes" installed onto servers by the users of the system.)
The blog post, Why Gender is a text field on Diaspora, is a brief look at the developers thought process in making gender a very flexible piece of data.
Four years ago, at my first rails job, I worked at a company with a mostly-*** customer base. It turns out, in that context, knowing if someone is “male” or “female” gives you almost no useful information. The *** community has other widely-accepted categories of gender, but the company’s internal order tracking software — a well-known package from a national vendor — offered only male or female.
...
I made this change to Diaspora so that I won’t alienate anyone I love before they finish signing up.
The comments seem to be running about 50/50 between "So happy you've done this!" and "Meh".
I know there are a lot of design considerations being made in the planning for the NextGen project. Just wanted to share this link as a bit of a thought provoker and conversation starter. I suspect that some Tessitura licensees find themselves with unique constituent populations that might benefit from this type of flexibility.
-Levi
Levi -
My husband (who donates to and follows Diaspora development) was just mentioning this to me over the weekend which started our own weird dinner conversation. The question that it raised for me, is why do we want/need the gender column? (In a kind of big picture question, not actually saying to get rid of the gender value). In my own organization we currently use it for three reasons:
1. For the box office/phone room: to know that 'Pat' is actually a 'she' or 'he' when calling or speaking to the person in question.
2. To help generate formal salutations or custom text (i.e. if gender = 'female' then 'her')
3. For any sort of grant reporting we might eke out of some statistical info.
Granted, since we don't often ask the gender question unless there's something unusual, we mostly use it for reason #1.
If we go down the Diaspora way of a free text field, what we gain in flexibility we lose in any sort of data integrity. Even the Diaspora blogger recognizes that she's going to see answers like 'have not checked today', 'man-boy', etc. Like another commenter on the blog, that leads me to ask, why ask for gender? Why not a random question? Is the moon made of cheese?
Now, I'm just playing devil's advocate here as you wanted to start a conversation... So I'm obliging. But I really do have a serious question for all the organizations out there.
Why gender?
It seems to me that we have to answer the question of why it is stored before we can determine how it is stored.
- Heather
Heather -
I completely agree that a free text field makes the data worthless in a Tessitura environment since we want to use that information for other purposes (reporting for grants is the one I was thinking of in particular). For a social networking site, I can see it being more user friendly to be free text.
As for the need for gender as a field at all, I'm a fan of getting as much demographic information as possible. If for no other reason than to make programming decisions. Age, gender, zip code and income level are pretty powerful tools to analyze your customer base with.
While alternate gender values might not make up a large percentage of the constituent base, I would think that development departments would find that information even more valuable in their efforts to make a more personalized (and potentially less embarrassing or offensive) donation ask.
I was, frankly, a little surprised at the vehemence of the "No! There are only 2 genders!" comments on the original blog post. So I may be underestimating how sensitive of a topic this is. But if the goal of the organization is to create the best and most personal customer experience possible, it seems like it would be advantageous to have the ability to gather as much information as easily as possible. Of course, that has to be balanced with ease of use in the software and on the web.
Thanks for chiming in Heather, always fun to have questions to think about!
Beth,
Thanks for a marketing take on things. Being a DBA means I love data and its always good to see how it is being used by different disciplines.
My hope would be that the gender field would become something that organizations could customize to their needs (either through system tables or something similar).There will obviously be organizations who never touch the default values, but for those who do see a need to customize it, it would be a great tool to have.
There was some follow up to this conversation on the web through a few other blog posts. The most interesting one I saw was from Metafilter.com. One of the DBAs did some quick analysis on their database. It is a realtively small sample size (< 10,000 records with a value entered for gender) but even with a free text field in place, they were still able to identify over 75% of the values as indicating a preference for being identified as either male or female. The full comment has a detailed breakdown of the remaining values (along with his caveats), but it is interesting to see what kinds of things people will enter when left to their own devices.