Chad Perrin: SOB

22 November 2006

simplifying choices

Filed under: Cognition,Geek — apotheon @ 06:47

Joel Spolsky (of Joel on Software), famous ex-employee of Microsoft and chronicler of his own opinions on software development, has some opinions about choices. He thinks choices are bad, that they make people unhappy. As he puts it, Choices = Headaches. Leaving aside for a moment the logical absurdity of a programmer, talking to other programmers, using an assignment operator in the languages with which he is most familiar in that manner, he makes some excellent points.

The really salient and accurate point underlying his superficial points about the importance of simplicity in an interface is that being able to choose exactly what you want from a pool of as few options as possible is, all else being equal, a net win. Having to make the decision does not make you happier. On the contrary, it is likely to make you less happy. The absurdity of the redundant and poorly presented array of options available to users of Microsoft Windows Vista for taking Windows out of a fully-operational mode when not actively using the thing is aptly illustrated by his description of the situation. He’s right that the process could, and should, be significantly simplified.

Joel conflates having options with having to choose between them, however, at least to some extent. The end result is that he ends up settling on a solution to the problem of choosing how to shut down the system that is reminiscent of mid-’90s Macintosh design philosophy: automate everything you possibly can to save the poor widdle easily-confused heads of the users, and prevent those users from meddling with it. Personalizing the Mac should be limited to deciding between laptop and desktop, and choosing a case that matches the drapes. Our users can’t handle any real critical thinking tasks, so don’t curse them with options.

Obviously, this is not the philosophy to win the hearts, minds, and happiness of human beings. It didn’t work. Things have changed at Apple — and they have changed for the better — as a result of the lessons of usability and marketing hard-won by the depressing Mac sales figures of the previous decade.

There are really two ideal approaches to your system interface, both of which draw on the lessons almost taught in Joel’s recent essay, and also on the contradicting lessons of the open source movement: people want options, as we discover in the proliferation of Linux distributions, BSD versions, and legions of open source utilities and applications, but they don’t want to have to choose among them over and over again all the damned time. In combination, this is a lesson that may be far more understandable to your average sysadmin than to your average programmer. After all, programmers spend all day trying to create software that they think answers users’ needs. Sysadmins, meanwhile, know exactly what the needs are, but have to decide on the best way to achieve them and, when they figure out what works best for them, they script it in Perl (or whatever) so they don’t have to choose the same things over and over again every time an oft-repeated task is needed.

The point here is that people like to have the options that allow them to pick out an ensemble that best suits their needs and preferences, but they don’t like to have to select all the garments and accessories that make up that ensemble over and over again (to abuse a metaphor). This is really what happens, to some extent, with open source software: one puts together a preferred system configuration by an iterative process of tweaks and nudges approaching perfection (as defined by the user), then uses that well-configured system happily. Apple takes an opposite, but equally valid, approach with MacOS X: there is a default, feature-rich user experience ready and waiting, but it is easily dismantled bit by bit and altered to suit the needs of the user. One is the cook-from-scratch approach to the perfect soup, and the other is the reduce-from-gumbo approach. It is easier to cook the perfect soup from scratch than to reduce a gumbo, but at least with a premade gumbo you have something already edible, which greatly lowers the bar for entry to the wonderful world of serving soup.

I’m full of bad metaphors today, apparently.

So, we have two unavoidable options, really, because there will always be a need for both approaches to choosing the right user environment. You can’t really abstract those out to reduce to one single option. When building a system from something approaching scratch (such as by way of a minimal install of your favorite Linux distribution, on which you install all the software you really want and not one whit more), you put yourself in the position of having to make a lot more decisions before you even really have a very usable, productive environment — but the beauty of the exercise is that, when you’re done and all is ready, you are done making those decisions, the only exception being when you need to create a user environment again (and even that is simplified by already knowing your own software preferences).

The moral of the story is that options are good, excellent really, and necessary to happiness, despite Joel Spolsky’s statements to the contrary. They just need to be presented in a sane way, such that there are ways to avoid making more than the absolute minimum number of decisions, to choose how many decisions you really want to make, and to make as many of them as possible only once.

Start with a default feature-rich environment with all the bells and whistles, but with the actual choices at your fingertips minimized to the specific options most likely to be most favored by the most people. Allow for an option to throw away everything, and build from scratch. Allow for an option to change defaults. Allow for an option to remove stuff. Perhaps above all else, allow for an option to minimize the visible options, reducing things to only what the person actually wants to see, when an ideal configuration is reached and decided on (with, of course, an option that opens up all the previously hidden opportunities).

Don’t overburden us with unnecessary options all the time whether we want any of them or not. At the same time, though, don’t actually eliminate the options — just let us decide which options we want to see.

People — like Joel and, one supposes, Jim Allchin — seem to have the mistaken impression that they must choose between giving us all options in front of our faces all the time or only those options we are most likely to want according to some imaginary measure of the average end user. They should simply learn to trust us to know what we want, both in allowing us to choose from all the options, and in allowing us to tell some of those things we decide against to go the hell away and never return to pester us in the middle of typing an email or, for the love of gob and all that’s wholly, trying to turn off the damned computer.

20 November 2006

being quoted

Filed under: Cognition,Metalog — apotheon @ 06:36

William Marshall Sanders III said:

once again i’m taking a government class…this time GOVT II I assume you again don’t have any objections to me quoting you in my research paper?

It’s nice, from time to time, noticing someone is paying attention. Whee. I’m a primary source.

15 November 2006

the deal about portability

Filed under: Geek — apotheon @ 04:22

Every language is portable, as long as you always use the same machine platform.

With C/C++, this means using the same physical machine platform and the same operating system, because C/C++ compiles to native code.

With Java, this means using the same virtual machine, because Java compiles to bytecode that is run on a VM, which meanwhile is compiled to native code, thus providing a “bridge” between bytecode and the physical machine.

Similarly, with Perl, this means using the same JIT-compiler/interpreter environment. With Ruby, the same interpreter environment. Et cetera.

The reason C/C++ and Perl both seem more portable than Java to everyone except those writing internal enterprise applications for environments entirely within the control of the IT department’s policy decisions is simple:

C/C++ is portable because the compiler can turn the same source code into native machine code for any machine. Perl is portable because the JIT-compiler/interpreter environment is the same on every platform.

Java is not so portable because Sun screwed around with licensing and hidden specs for so long that eventually people started trying to reverse engineer it to produce pseudo-workalikes, and the end result is a bunch of incompatible VMs. This wouldn’t be regarded as such a big deal if it wasn’t for the fact that Java is distributed in bytecode form with the “write once, run anywhere” marketing hype attached to produce unrealistic expectations of supreme portability. Now, Sun is finally releasing Java as open source software. Sun has settled on an open source license: the GPL (a problem, but not to be addressed at this exact moment). Too little, too late — the damage is done.

If you really want your Java to run “anywhere”, you need to compile it to bytecode separately for every VM available for it. Then, of course, you need to convince your users to pay attention to what they’re using to the extent that they can choose the correct bytecode-compiled Java application blob.

It’s difficult enough getting people to notice what hardware architecture, operating system family, and version of OS they are using so that they can pick out the right software. Now, you’re asking them to remember what VM, and what version of it, they are using just for the sole purpose of selecting the correct application install or download to use just for applications written in one stinkin’ language. Languages should not even be recognizable to the end user. The end user should not be able to differentiate between a system utility or application written in C, C++, OCaml, Haskell, Java, Ruby, Common Lisp, Perl, or Erlang. Out of all those languages, I can have a program written in any one of them sitting on my hard drive on this Linux system that has its executable bit set that I can run just by calling it by name, without having to worry about whether I have the right version of the parser on my system — except one.


Write once, run nowhere.

« Newer PostsOlder Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License