Choices == Headaches ?
I've recently enjoyed this article from Joel :) No, the beginning of the article was sensible, but the end was...If we follow him, then we must conclude we don't need shampoo for the hair and gel for the body. One is sufficient, and don't blame if you get a dandruff thereafter...
We also don't need a soup and the main course served to you one after another in the restaraunt. What you really need is some stuff mixed together in one plate with one device to eat instead of spoons, forks and knives... And yes, don't dare to ask for the desert because it was already included...
Also urge the authors to write only one book during their life. If you have something to say, say that once. And don't try to write about anything that was ever written before...
Finally, don't even try to reboot your computer to boot Linux instead of Windows because Joel says the only thing you can ask your computer to do is to say "bye bye"...
I can continue my examples for ages.
What I would like to say here is that it is useful to get things to their extreme to study them (like Hegel used contradiction and negation to study the properties of the unity). But it is not sensible to apply extremeness in every day though. And that's exactly what Joel does.
Looks like Barry Schwartz's book The paradox of choice became a catalyst for this article. I haven't read the book yet but I've listened to the Google video The Paradox of Choice, why more is less. The book is on its way from the online store already but from what I heard and read it's not going to be significantly different in core ideas from the lecture.
Barry's lecture was excellent and thoughtful but it seems people (and Joel too) missed "Choice is Good" part of it. The whole idea of "The Paradox of Choice" seems for me not "Choice is bad" or "Choice == Headaches" but rather "Too much choice is bad". Schwartz stresses many times but his message seems to be missing. People just like to pick up the easiest but extreme ideas.
Of course we shall remember of "too much choice is bad" and use that knowledge. But how to make sense from "Paradox of Choice" and not fall into utter oversimplification? I've thought about that for a while and this is what I think about it.
Overcoming the Paradox of Choice
First, let's look at "choice" in its everyday meaning. Say, we can have one of four things. Let's call them A, B, C and D. This statement in terms of logic would naturally beA or B or C or DSometimes in the real life we can have not only one of these things but a combination of them. This would become
A or B or C or D or AB or AC or AD or BC or ... or ABCDThat is the choice represented in terms of some formal system S based similar to (human) logic.
So far so good. Now let's imagine situation when we must have all A, B, C and D. We must have them maybe because they serve different purpose or just we like them, whatsoever. In terms of S this situation would become
A and B and C and DDo you recognize the difference between choice (represented by "or" operator) and this phenomenon (represented by "and"). I'll give the new phenomenon the name "chance". Chance might not be the best word but it's colourful enough to stress my point here.
So we as people in our everyday life have "choices" and "chances". And that real world situation perfectly transforms into the world of computer programs. Sometimes we are given a choice to do either A or B or C or D, but sometimes we need a chance to do A and B and C and D. If we apply ideas from "The Paradox of Choice" we might want to not give our users too much choice. But at the same time we certainly want to give our users more chances! For example, if your media player don't have a playlist, it certainly revokes your chance. But if it has two or more playlists or player windows (remember noatun?) then it's giving you choice, in this case too much choice.
From this perspective software development looks like the process of giving users maximum number of chances and at the same time not too much choice!
You could say here that the chance and choice are elusive and sometimes it's not possible to draw a distinct border between them. Indeed, if we look at Joel's example of shutdown options - which ones are chances and which one are options that only give a choice. But nevertheless I believe there's a way to tell a difference between them. Applying common sense might help. Basically A and B takes place when:
- A significantly differs from B
- A serves the different purpose than B
- A gives results different from B
Now let's get back to Joel. First he says there're 7 different shutdown options in Vista:
W(sWitch user) L(Log off) C(loCk) R(Restart) E(slEep) H(Hibernate) S(Shutdown)
He starts to place operators between them:
CWL=(W or L or C) R EH=(E or H) SThen he simply puts "or"'s everywhere and simplifies the expression to just one thing
B'Bye=(CWL or R or EH or S)
Was there a fault in his derivation of B'bye? In my opinion yes because he considered the set of options from only one point of view - the "too much choice is less" point. He didn't try to look at those options as at chances. If we carefuly did, he might have ended up with something different, for example with
CWL and R and EH and SOf course, another interpretations are possible and you might derive another formula (like Vista developers who put "and"'s everywhere).
That's finally all I wanted to say today :) I hope you got a chance to read this post to the end and you understand my idea that as a software developer you don't have a choice between A(giving your users less choice) and B(giving them more chances) - because A and B are your chances ;)
5 comments:
In that case I would say, let's have an additional option: that proposed by Joel :-)
Wouldn't that be too much choice? ;)
I gotta say, I think Joel hit the nail right on. I follow your attempt of deductive and inductive reasoning but I am not sure it applies to software construction.
Let's say a programmer needs X, Y AND Z (IDE/component/library/tool/ORM/webservice layer etc.). Each has 10 equally valid and known options. Now in order to choose you need to investigate and commit to a configuration among 1000. After you are done, you hope you made the right choice such that maintenance and further development is not undermined by deprecation and that you will not experience a technology lock-in.
The tragic thing is however, a programmer - especially in Java - needs to make far more choices than just X, Y and Z.
I was talking more about what options we present to the user in our programs and not really about our own options that allow to implement the program. I think Joel (and I too) were referring to the case when you are making a product and the user sees chances and choices in your product. Only in this case you can apply my method.
I don't have the recipe that would tell you how to choose and what options to use. That's indeed hard. But I pretend that if you think about "and"'s and "or"'s in your product, you might end up giving the user not too much choice and at the same time not too few chances.
Right, the usability issue is complex indeed mostly because the users have different opinions. Joel's specific case (Vista) has to meet expectations from legacy users and cutting down on buttons is more Apple's style than Microsoft’s. More to his point, Microsoft COULD have disabled some of the buttons per default and allowed them to be explicitly turned on by the user – no argument there. In my previous post, I took the “open source movement” as a reference to there being too many choices in software construction as well, which I as a Java developer know only too well.
Post a Comment