Posted at teatime on Tuesday, November 21st, 2006
Dumbing down the UI: tools vs appliances
What is an appliance? A refrigerator is a prime example: I can walk to a refrigerator in Hong Kong, and know how to use it: I open the door, put in my beer, and after passage of time, it becomes cold. Open door, take out now cold beverage. Done.
A simple Axe, on the other hand, is a tool. One needs to learn how to use it -- in experienced hands, an axe can splinter a match stick. In inexperienced hands, on the other hand, an axe hitting at the wrong angle can bounce off the wood you are chopping and take off your foot. Please note that there is nothing complicated about an axe -- so mere complexity is not what distinguishes a tool from an appliance.
An axe is a versatile tool, though. It can be used to fell trees. Firefighters use it to rescue people by going through doors. Dwarwen warriors use it as a weapon of war. It come in versions that can be lightly thrown, or wielded two handed for telling effect. And remember, the term hacker comes from those who created furniture using axes.
Tools need to be learned. However, mastery of a tool can lead to wondrous creations -- think furniture (I have never heard of any significant refrigerator-fu, I fear).
This brings us to interface design. I use my computer as a tool of my trade. It is what I do, and I have invested effort in leaning how to use it effectively. I understand there are people who want to use computers as a typewriter appliance; and proclaim they have no desire to invest time required to master computers as a tool. Please understand that this has nothing to do with novices; a apprentice may well be uninitiated in the intricacies of a tool at the inception of his career, but can still be committed to mastering it.
For the most part I can accept the view point of the people who want to use computers as appliances -- though I personally feel that is a waste of a general purpose computer. I have no interest in catering to that viewpoint. Unfortunately, there is a vast difference between user interfaces for people who want appliances, and those who want a versatile tool -- and I fear the user interfaces are being hijacked by people belonging to the former set. (Anecdote: I used to go to a travel agent, using Sabre software -- each keystroke was bound to some kind of macro,and she could scan through several alternatives through multiple airlines faster than orbitz can. Using a menu driven UI wold take me half an hour to do what she did in seconds). I see applications getting bloated with user interfaces designed for the infrequent user, with little care being given to the needs of the people who are intent on speed and ease of operation, not on flattening the learning curve down to nothing.
Update: As Tollef Fog Heen points out, the critical distinction is frequency of use: for items one uses frequently it is worth paying the cost of climbing the learning curve, and flexibility and ease of operation count for far more than the cost of learning to use the tool. For items used but infrquently, one has pay the cost of the learning curve many times over; and thus it would make sense to minimize the curve. Not all interface design ought to cater to the sentiment that these programs are used but infrequently. And, in the old days, I could learn the use of a program that best suited my needs, figure out common command switches, and script them, and never really have to re-climb the curve.
Thanks for listening.
Posted at midnight, January 2nd, 2006
First call for votes for the Sarge GR
I finally got time from my day job to set up the infrastructure for a vote. This entailed setting up a temporary vote key (the key I had set up earlier for the draft ballot had expired), adding the latest proposal (F). And set up the cron jobs, and so on.
Any way, head out over to the vote page for the juicy details. Take care in reading over the details, for this is not just a GR, it is a GR that changes foundation documents, and as the last vote has shown, any foundation doc change merits a modicum of diligence.
Posted at midnight, January 2nd, 2006
Crumbling of Rough consensus in Debian
I am not the only one to be struck with the realization that there is very little effort at building consensus going on in Debian of late. Positions are presented, the active participants rapidly become polarized, and things rapidly head to counting hands; the largest of the polarized camps then carries the day. This certainly is not how things used to be.
And it is not as if the absence of an effort to come to a rough consensus has made the lists any less acrimonious; so this reduced tendency to enter into a dialogue with people that disagree with one has not made the lists any friendlier.
I think a couple of otherwise useful institutions have contributed to this malaise; the first is the constitution. Though accepted with relief and absolute unanimity (this is the only unanimous vote we have ever had), it has its flaws: it is written in pseudo-legalese, which practically invites picayune nitpicking and contentious debate over minor points of order. We spend far more time debating over the form of the trees, and miss the forest. At the time the constitution was being crafted, we were reeling from absolutely any rules governing conduct and any delineation of powers of people in the project, we had an informally defined Project leader, and we probably did not submit the constitution to the review it required, so starved were we for any semblance of order.
The second is stems from an constitutionally defined process, the general resolution: though something like a GR mechanism is a must for a project the size of Debian, the facility with which one can vote on multiple options simultaneously has lead to people just throwing up amendments that they like, and brute forcing the most popular amendment through a vote. There is no effort to compromise, and no effort to ameliorate the tyranny of the majority. There is no effort to even begin to find a common solution, instead people seem to be offended if an option exactly matching their sentiments is not on the ballot.
Added to the growing unease about the lack of communication or
openness in the organization (with the vague muttering about
in Debian), this lack of communication (which is what this tendency
not to convince the rest of the project of the merits of one's ideas
is, really) leads to us making flawed decisions -- and then
scrambling to put Humpty Dumpty together again.
So what is to be done? I suggest that we try not to lose sight of who we are fundamentally: we are a group of people who have found common cause to volunteer our time to make the best OS out there. I would like to think we are a bunch of folks having fun -- and working together for what is still a common goal. Look at the big picture. Don't let the end goal be lost in the petty details.