Computers don’t have emotions; I don’t need to worry insulting the vast majority of S3 objects when I defensively check integrity every time. But humans are different; when we design a human system around uncommon cases, we do need to consider the ramifications on the majority.
We can hide the complexity in computer systems even engineer the risks of it out, this is not the case in human centric systems. That complexity will endanger everyone involved.
KISS is a good principle generally, but it's the most important principle in humans systems, sometimes even ahead of completeness.
> when we design a human system around uncommon cases, we do need to consider the ramifications on the majority
This is how I feel every time some new service asks me which pronouns I prefer. I'm happy that some people get to choose the pronouns they feel represent them (or avoid the pronouns they feel disservice them), but it seems like it is both pushing an agenda and adding additional friction to the process. Just leave the option setCustomerPronoun() available without making it a necessary step.I've chosen a contentious example, but there are dozens of others. Just for another example, if I was born in 1977 (above age of consent), what does the forum software care my exact date of birth and err when I don't want to provide it?
Same with the Last Name field. I happen to know someone who doesn't have one. Why isn't he accommodated?
How about colour blindness? Why isn't there a colour-blind accessibility option in the sign up form? Is making colour-blind people's options the same level in the UI as regularly-sighted people a bad thing?
I think that my point is made.
Having a separate first-last name is often brought up as a UX failure for exactly this reason, and UX designers often design websites so that colourblindness doesn't hamper usability (in my experience working with designers at big companies). The Christmas one isn't as much of an issue because AFAIK very few people are meaningfully put out by seeing Christmas decorations on websites from majority-Christian countries. In other countries these things often /are/ turned off depending on cultural sensitivities.
We should be trying to design our processes to fit the world around us, not rejecting the parts of the world we don't like.
The obvious solution is to just not use pronouns - it's a messy part of the language that is currently in flux, so why wade in?
Obviously, some sites are dedicated to these issues, so they can justifiably ask on sign up, but if you don't _need_ to care about people's personal details, better not to ask at all.
Forms of address --- Mr., Mrs., Miss., Ms., and often professional titles (Dr., in German Ing. (engineer), esquire (lawyers), Reverand, etc.) is at least fairly common if not entirely standard practice.
I suspect, again, some motivation on the part of a requestor. A magazine's circulation department, for example, might want to know the number of lawyers and doctors among its subscribers as a proxy for advertising value.
Many business information request forms provide detailed rosters of who you are, what you do, and your company title. For similar reasons, I suspect.
(I also feed those bogus information as a matter of course.)
The New York Times formally adopted use of "Ms." as a title, distinct from "Mrs." (a married woman, often referred to by her husband's full name, e.g., "Mrs. John Q. Smith"), or "Miss" (an unmarried woman or girl, addressed by her given and maiden names, "Miss Jane Q. Jones"). Ms. Magazine was a direct and deliberate challenge to that practice, and was launched in 1971 by Gloria Steinem. Interestingly, all three words, "miss, "missus", and "mizz" originate from "mistress", which was at one time the single title applied to any woman, adult or child, married or not.
(For men, the terms "Master" (unmarried child) and "Mister" were both represented as "Mr.".)
And then as now, "Ms." resulted in much gnashing of teeth, changing of forms, and updating of databases.
https://en.m.wikipedia.org/wiki/Ms.
https://www.nytimes.com/2009/10/25/magazine/25FOB-onlanguage...
There's virtually always the option to leave the option blank, or to make up a garbage or meaningless value. The first system on which I recall the option being offered was Google+. My response was "trans-krell", playing of my pseudonym's character.
For age, I usually try to find the earliest possible birth year acceptable to the system. For Google this seems to be about 140 years prior to the present date. Again, I avoid providing this information if possilbe (most of my various little-used Google accounts have either no value provided or a ridiculously early age).
I'm of the view that we don't need to be formulated, sprawling on a pin, within some global surveillance database(s). If I can evade classification and feed garbage to the system, I will, for as long as that is viable, and probably for some time after that point.
The gendering or nongendering agenda concerns me far less than the Total Information Awareness agenda. Services demanding anything from me other than some random username and password (I tend to use password generators to create both values), and possibly a contact email address ... tend not to get used.
As I just commented to a friend a few days ago, I can't remember the last time I did create an account, with the exception of some recent Mastodon and Diaspora* migrations in the past year or two.
For my most recent Android device (the Android aspect of it being among the least attractive characteristics), I bailed out of Google Play Store registration, which requires creating a Google account. (Even if not formally associated with other identities I have, those could all but certainly be trivially linked.) Instead I'm relying on F-Droid, APK-Mirror, and the Aurora Store. I've kept actual app installations to a bare minimum, and most of those through F-Droid. There are I think three apps with actual accounts associated to them, though only one has been so configured.
My use of the Internet dates to the 1980s. I've seen a lot. And am disliking increasing amounts of it. Read Dan Geer if you haven't recently.
> There's virtually always the option to leave the option blank, or to make up a garbage or meaningless value.
Right, but it's an uncommon option that relates to a controversial subject. That's why I mentioned to leave the option setCustomerPronoun() available without making it a necessary step: show it in the UI options but it doesn't have to be front and center in the sign-up form. > The gendering or nongendering agenda concerns me far less than the Total Information Awareness agenda.
Sure, without a doubt. I may have inadvertently picked a flamebait example! > Read Dan Geer if you haven't recently.
Thanks, added to the list.As a human, can you please tell all of us what these abbreviations are?!
...TFA: The Featured Article
a.k.a. (also known as) OP (original post(er))
This is one “human corner case” I have no shame working around. Wouldn’t want to convey hostility where none exists.
I prefer "TFA" to "OP" as the latter may be ambiguous as to whether it refers to the article or, more typically in my experience, commentary on it. Even here, "OP" might reference either a thread root or the parent of the post immediately being replied to.
In the second case, if I were to say "OP" here, I'd be referring to your comments parent, by tchalla, https://news.ycombinator.com/item?id=30345056
It refers specifically to the submitted article, and carries an overtone, sometimes tongue-in-cheek, sometimes subtle, sometimes more blunt, that the person being referred to ought to read the specific submitted work more closely. Perhaps at all. And without crossing HN's guidelines against specific accusations.
That is, the meanings are similar but different. "TFA" is more concise and specific. All of which make it the more fabulous ;-)
It turns out I do use both terms fairly frequently, as my comment history shows. The distinction is largely as I've described above. "The article" usually refers to some additional or other reference rather than the HN submission. "TFA" in the context if "you/I should have read that closely".
TFA: https://hn.algolia.com/?dateRange=all&page=1&prefix=true&que...
"the article" https://hn.algolia.com/?dateRange=all&page=1&prefix=true&que...
The real problem with crypto is that usually what is asked for is a ledger, and the crypto and distributed parts are just bloat.
Unlike code that triggers (hopefully) only when something weird happens, the cost of the special instructions and the dysfunction that followed was ultra high.