Microsoft design bloopers move control from the user to the software program
Over the last few months, I've been startled by a couple of peculiar events on my PC.
The Case of the Sorcerer's Update
The first curiosity came to my attention when my PC firewall announced that a process was trying to reach the Microsoft Web site -- and was trying to connect every five minutes. Apparently I had inadvertently clicked on the icon for "Windows Update" in my Start Menu bar and thus activated an automatic update function for the Windows operating system. But why could I not change the frequency at which the program was polling the Microsoft Web site? And how could I turn this function off? Investigation in the Microsoft Knowledge Base turned up a report http://support.microsoft.com/support/kb/articles/Q224/4/20.ASP describing how this program works. Basically, it checks for a live Internet connection every five minutes; if it doesn't find one within an hour it decreases its checking to once an hour. When it succeeds in checking for critical updates, it waits 24 hours before checking again.
The only flexibility in scheduling is that one can click on "Notify Me Later," which delays further checking for 24 hours. There is no other way to modify the schedule: "Question: Can I change the scheduled behavior of Windows Critical Update Notification? Answer: No, if the scheduled task is modified, the tool reverts to the default settings the next time Windows Critical Update Notification runs. Note that this behavior is by design to ensure that you are notified of updates in a timely manner."
In fact, according to Microsoft, once launched, there is no way to turn off the Windows Update program except by uninstalling it and rebooting the system.
The Case of the Superior Linguist
The second incident was the discovery that my new Microsoft Office 2000 programs disagreed on what language I was supposed to be writing in. MS-Word and MS-PowerPoint both accepted U.S. English as my default language; however, MS-Excel and MS-Access insisted that I was using European French -- and refused to let me change that setting.
I maintain a database using MS-Access called the INFOSEC Year in Review where I classify issues in information security and write abstracts about the key points of several thousand news reports during the year.
Shortly after upgrading from MS-Office 97 to MS-Office 2000, I was surprised to find that my familiar keyboard macros were not functioning in the Access database. I define these macros using the AutoCorrect feature, which has a list of frequently-misspelled words and a facility for adding one's own favorite misspellings or keyboard macros.
The program insisted that I was writing in European French. There was no option for changing this language setting. MS Excel also exhibited this unusually Eurocentric attitude. In contrast, both MS Word and MS PowerPoint did allow control over the language setting.
Investigation by a Microsoft technical-support representative revealed that both MS access and MS XL determined the language of their user by reading the keyboard driver settings. Because I use a Microsoft French Canadian keyboard to write in English as well as in my native language, these two programs assumed that I must be using French, not English. Worse still, they both incorrectly read the keyboard settings and claimed that I must be writing European French instead of Canadian French (Canadian French allows accented uppercase letters whereas European French does not).
The technical support representative sheepishly admitted that the only workaround for this feature was to change the language parameter for my keyboard to U.S. English. This change unfortunately would make it harder to type quickly: the position of most of the special characters would be quite different from their marked location on my keyboard. Another alternative was to buy a U.S. English keyboard.
Another excuse diffidently proffered by the Microsoft tech-support rep was that neither Excel nor Access was intended for large-scale text input, and so limitations on the user choice of language somehow made sense. I responded that MS XL allows for 32 kilobtye text fields, and that's how I use the product -- using text fields.
Finally, the poor fellow tried one more defense: after all, he said, it was understandable that the design engineers might have to restrict functionality in a tradeoff for better performance. I retorted that this excuse might sit better if millions of users had not been subjected to Easter eggs in Microsoft products (see, for example, "Easter Eggs and the Trusted Computing Base" ) http://www.nwfusion.com/newsletters/sec/0327sec1.html.
* * *
There is a lesson here for everyone who designs software or who teaches software engineering.
� First, let us be clear that the behavior of Windows Update and the linguistically stubborn Office 2000 programs cannot be called bugs. They really are features: in each case, the error is not in the program, it's in the design. Someone deliberately decided to constrain user choice. Had they made their choice a suggestion, I don't think anyone would have minded. But they didn't stop at a suggestion: they forced the issue and prevented the user from changing the option to something more useful.
One or more systems analysts, programmers, documentation specialists, quality assurance engineers, and product managers presumably all felt that they could best serve their users by moving the locus of control from a living human being to an obstinate program.
Lesson: Decisions distant in time and space should not override the here-and-now needs of a user. If you automatically make a best-guess choice of an option, allow an override by your user.
These foolish design bloopers may eventually be taught to a new generation of programmers. Perhaps someday we will hear a heartwarming response when someone proposes removing control from a user: "Oh," one of the brighter youngsters will say, "now don't go pulling a Microsoft."
M. E."Mich" Kabay is security leader in the INFOSEC Group of "AtomicTangerine"; he can be reached by e-mail at [email protected] and by phone in his Vermont office at 802-479-7937. Copyright � 2000 M. E. Kabay. All rights reserved.