July 26, 2002
Knowledge in the fingertips
My new job means I have to use Delphi. I've used Visual Studio and its precursors since Visual Basic 1, so adapting to Delphi has been a painful experience. My fingers know that F5 means debug and F9 means breakpoint, and no amount of knowledge in the head will convince them it's the other way round.
I thought this was down to my fingertips having ten years of usage drummed into them, but now I think they're a lot more fickle than that. After just a week and a half of using Delphi every day, I turned back to Visual Studio.NET, and my fingers instinctively stabbed at the Delphi keys. Worse still, even though I knew I was writing in C#, when I came to common constructs, my fingers started typing in Pascal. (Needless to say, at work they still insist on typing in C#, curse them.)
On the other hand, as long as knowledge in the fingertips still works, it takes a long, long time to die. Windows has used sensible Mac-style keystrokes for Cut, Copy and Paste since 3.1, but when I need to copy and paste, my fingers still reach for the cryptic and contortionist CUA combinations. Believe me, I couldn't even tell you for certain what the CUA keystrokes are, except that they involve various combinations of Ins and Del. The head doesn't know. But the fingertips do. So I still use them, and expect to carry on using them until the Standardisation Fairies finally take them away to Sleepytown.
What does this mean for user interface designers? First, consistency is relative. People who use different applications in different ways have different knowledge in their fingertips. In particular, people who already use your application may have very strong subconscious expectations of how a new version will behave. Second, being consistent enough to let the fingertips work their magic really does make a big difference in those critical first two weeks. But third, forget about two weeks: even ten years is not enough for migrating really common UI idioms. If your users use a feature several times a day, they will never move over to your new design until you get rid of the old one. Either you have to support their old UI for ever, or at some point their fingertips have got to take the pain.
The fingertips are powerful. In the short term, the fingertips always win. If you ask your focus groups, you'll probably find the fingertips telling you to keep things the same.
But, in the long term, fingertips are fickle. Give them two weeks, and they'll have settled into the new idiom and will find it hard to go back. In fact, if they're using a feature intensively enough, it can take just hours for knowledge to migrate off the screen, into the head and down the arms. The most painful adjustments can, in the end, be the fastest and easiest.
How to shoot yourself in the foot with copy protection
New Scientist: "Spider-Man's copy protection does not stop people copying but it does prevent them from accessing Sony's promotion for the movie."
July 23, 2002
What Dot Net?
Seattle Times (via The .NET Guy): "What happened to .NET? Microsoft's flagship strategy for "any time, anywhere computing from any device" has sunk like a stone. By now we were supposed to be seeing initial .NET applications, but the new rallying cry seems to be for Palladium, a security initiative that has met with the same skepticism and resistance from the developer community that .NET inspired."
Answer: we're less than six months from version 1.0 of .NET. Where were the DOS applications six months after 1.0? Where were the Windows applications six months after 1.0? Where were the Java applications six months after 1.0? Where were the Web applications six months after Mosaic 1.0? Have DOS, Windows, Java and the Web "sunk like a stone"?
Actually, most of the author's points are perfectly reasonable, just the sort of thing analysts -- and software architects -- need to know. "How are Windows and Office XP upgrades going? What is Microsoft doing about the international trend toward open software? What is the acceptance outlook for Microsoft's new subscription-based upgrade policies?" In that context, a question about the adoption rate of .NET makes sense. How is takeup going? What is Microsoft doing to promote further takeup? When can we expect .NET to move from the intranet to the Internet? What factors do customers say are affecting takeup? When can we expect the so-called .NET Enterprise Servers and the .NET Building Block Services? What information can I give my team, right now, to enable us to make strategic choices for the next twelve, twenty-four, thirty-six months?
And the author is right to point to scepticism within the developer community. For Windows developers, .NET is a huge step forward from Visual Basic, Delphi and MFC. But because it's a huge step, people are cautious about taking it. Will my COM components still work? How much of my VB application will I have to rewrite? Do Support know enough about installation, configuration and monitoring to support this new technology in the field? Can I afford that risk? Anyone who isn't sceptical is doing their business and their colleagues a disservice.
But there's a big gap between being sceptical and being negative. The sceptic insists, "Convince me." The negativist says, "I don't want to be convinced." Within the Windows community at least, I don't hear much of the latter, the main sources being the very vocal VB.Classic loyalists. If the community as a whole is sceptical, good. If the community as a whole were negative, then Microsoft would have a problem and the author might have a case. (But don't bet on it. You'd have been hard pressed in 1985 to find anyone who didn't run a mile from Windows 1.0, and look where we are now.)
Myself, I try to be sceptical: I'm worried about the risks, the immaturity of the platform, the lack of tools, the lack of well-documented best practices, the support issues, yadda yadda yadda. But I'm more positive than negative: I believe that .NET technology, even at this early stage, is worth considering, provided you understand the risks.
And to write off .NET because we haven't seen major applications within six months seems ludicrously premature. No technology that requires a dramatic shift of developer focus has done so, at least not in the PC era. Ask the questions, definitely. Prejudge the answer, no.
July 09, 2002
Why music does or does not sell
New Scientist: "Last year, two big music markets bucked the global sales trend: Britain and France. How come? Both countries have produced home-grown, non-manufactured acts that have committed fan bases built up through the traditional virtues of performing and regular new songs. Instead of expending all its energy stamping out piracy, some observers believe that the industry should stop pushing manufactured, anodyne music that many feel no compunction about stealing, and rediscover the art of nurturing bands worth paying to hear." (I've linked to the home page as the article is currently available only in the 6 July print edition.)
July 08, 2002
Khwaja Ghulam-us Sayyidain on education
Hussain Rizvi quotes Khwaja Ghulam-us Sayyidain: "Instead of laying out beforehand plans of what the child is to be and to do and what learning and skills are to be taught to him -- that is, casting him in a preconceived mould -- the school must recognize that every child is a unique and vigorous little individual who has to be consulted, as it were, about his own future and allowed to shape his own course of development under tactful and understanding guidance."
Real education is about the thrill of discovery
Richard Dawkins savages "the stifling effects of exams, and the government obsession with measuring a school's performance by them" in this weekend's Guardian. By comparison, he relates several stories of F. W. Sanderson, a 19th-century headmaster who, for example, left the doors to the chemistry labs and workshops unlocked so pupils could work on their own projects as they wished.
Needless to say, this led to a few, er, accidents, and eventually Sanderson was forced to lock the rooms again. But he had established such a culture of enquiry and action that disappointed pupils just started studying locks instead. "We made skeleton keys for all Oundle... For weeks we used the laboratories and workshops as we had grown accustomed to use them, but now with a keen care of the expensive apparatus and with precautions to leave nothing disorderly to betray our visits. It seemed that the head saw nothing; he had a great gift for assuming blindness -- until Speech Day came round, and then we were amazed to hear him, as he beamed upon the assembled parents, telling them the whole business, 'And what do you think my boys have been doing now?'"
It seems the Hacker Ethic goes back further than we thought.
Zbigniew Michalewicz and David B Fogel, How to Solve It
Despite the title, this is not really in the tradition of Polya's classic. Whereas Polya offered a toolkit of intellectual strategies for tackling problems, Michalewicz and Fogel focus on computational strategies for intractable problems, primarily optimisation problems. However, like Polya's work, this is far from a simple cookbook. It offers an armoury of heuristic techniques for your toolbox, but stresses that they are strategies and concepts rather than trying to offer you a canned implementation. When you consider that, for example, neural network get just one chapter out of 15, it's clear that the authors are trying to give you breadth not depth.
That said, I did think there was too much focus on the authors' three specimen problems (satisfiability, the travelling salesman problem and non-linear programming). It would have been nice to see the techniques applies to a wider range of problems. To be fair, though, the specimen problems are representative of a pretty wide field of intractable problems, so the information on applying strategies to particular problems should be applicable to the majority real-world situations.
So well worth reading alongside, not instead of Polya. Polya will help you figure out how to use the tools at your disposal, but Michaewicz and Fogel will help you ensure you have the most up-to-date tools.