Multi-access keys need a different approach than dichotomous keys

I am close to deploying a reasonably large online multi-access (Lucid) key and find myself fretting how it will be received by the user community. Obviously people may have different preferences for how exactly a key should look like and what features it should or should not have, but one concern I have in particular is that taxonomists used to writing traditional dichotomous keys may be disappointed with some of the choices I made.

To recapitulate, just in case it isn't immediately clear, there are two very common types of identification keys in systematics. The traditional ones are dichotomous and single-entry, because that is what works in books. As an example, consider the Craspedia key in the KeyBase repository (click on bracketed or indented to see the full key). The user has to start at couplet 1 and then answer one pair of leads after the other.

Crucially, to allow all species to be keyed out in such a dichotomous key the author has to find enough characters so that every single species differs in some clear way from at least one other species. There may consequently be lots of characters mentioned in the key, but it doesn't look that way because few of them are mentioned for all species. In the present case, couplet 9 asks if the leaves are sticky-glandular to differentiate Craspedia adenophora, but the trait is irrelevant for all other couplets because only the leaves of that one species are sticky.

The other, increasingly common type of key is multi-access and electronic. As an example, I have just basically at random clicked on the key to the Restionaceae of Western Australia. The user can enter whatever characters they have at hand in whatever order they want, and the key software will kick out all species that don't match. In this case there are also options to narrow the selection down by geography, flowering time or genus (if already known).

While working on my multi-access key (and a previous one before that) I have had conversations with colleagues on the lines of "what about this character, have you considered using that?" for characters that are sometimes very obscure and accordingly hard on the user or, and that is my main point here, serve only to differentiate a single species.

A character like that is often very important when writing a dichotomous key. Imagine the taxonomist working away, shuffling species around like so and so, perhaps ending up with a stubborn pair of species that clearly go together in the key but are hard to differentiate. And then they realise, ah, one of them has woolly hairs on the bracts, and the other doesn't! We have a contrast!

And that is great. But if, for example, the species with the woolly hairs on the bracts is the only one in the entire group with that trait, then the character works only to differentiate that one species. That is not a problem in the dichotomous key because the character is only presented to the user at the moment where it is actually relevant, while they will never see it in any other part of the key.

But in a multi-access key all the characters will be visible right from the start, even the ones that only work to differentiate a single species from the other 99 or so. And if we try to do that for all species we end up with a hundred characters, plus dozens of characters that differentiate 40 from 60 or suchlike. And now imagine the poor user being faced with a table of a bazillion characters - they won't even know where to start, the key will just look terribly daunting.

There is a reason why the ideal couplet in a dichotomous key is commonly said to mention perhaps two to three characters; when faced with too much choice or too much information at the same time the human brain just goes into Blue Screen of Death mode. For shopping decisions, for example, there seems to be some evidence that consumers are less likely to make a purchasing decision at all if a shop presents too many options.

What is more, the beauty of electronic multi-access keys is that it is not necessary to differentiate all species from each other. Yes, that is necessary in dichotomous keys printed on paper, but in our newfangled multi-access keys it is all about reducing the number of possible species to a comfortable three to five, and then the user can look at pictures and click on links or species profiles to make the final decision.

Well, I shall see what feedback I will get, but what I want to say here is that the habits that work for one type of key cannot simply be transferred onto a completely different type. The user experience would actually suffer from overloading the interface with dozens of characters each of which will hardly ever be useful.