In 1994, I sat down with the Microsoft user interface (UI) team for the product that became Windows 95. The team was excited to share with me the data it had accumulated via new usability testing procedures. This data was important because Microsoft used it to support the UI changes in Win95.
For the first time, Microsoft had made a serious effort to study the way people used its software. Using well-established techniques to examine the way users interact with the UI, Microsoft built a usability lab and spent thousands of man-hours watching computer users of different skill levels, from beginner to power user, work their way through the new interface designs.
The addition of context menus, which are attached to the right-click mouse button action, was one of the most significant introductions to Windows. Even in the face of thousands of documented usability-testing hours, I was initially skeptical. I eventually came to use the right mouse button and now expect applications to provide context-sensitive actions for that right button in almost all situations.
Let me fast-forward to 1999. I'm sitting in a technical briefing for Windows 2000 (Win2K) beta 3 with a small group of technical journalists. The presentation is on Win2K UI changes. Almost every comment is about how Microsoft is making Win2K easier to use from the Begin Logon screen to the desktop display, and that Microsoft is committed to making Win2K the easiest-to-use Windows version ever. Curiously absent from these usability discussions is any mention of context menus and right-click actions. When I bring up the subject of right-click actions, I get an interesting response: After analyzing the data from thousands of hours of usability testing, Microsoft determined that the average user doesn't use the right-click context menu. Only power users and systems administrators use the right-click feature.
That evening at dinner, I sat down with the presenter of the Win2K UI modifications and asked about the change of heart regarding the context menus. Having worked at Microsoft for only 2 years, this employee hadn't been party to the original decisions made during the Win95 UI development process. All that the presenter could say was that Microsoft's usability testing techniques are now more sophisticated and provide more reliable data. As a result, Microsoft is deemphasizing the right-click as an ease-of-use feature and repositioning it as a power-user tool (my words, not his).
So who's the target user for the new usability improvements? Let's take a look at the improvements to determine the target user. You'll see the first improvement when you boot up your Windows NT system. You'll get a little window with a description of what Press Control+Alt+Delete to log on means and an animation of a user pressing the Ctrl, Alt, and Del keys on a standard keyboard. Apparently, the Begin Logon screen presents a huge usability problem; users can't figure out that they need to hit the three keys simultaneously. So, Microsoft is providing animation showing how to log on. Still, the systems that Microsoft provided for the technical briefing (i.e., IBM ThinkPad 600 notebooks) had the Ctrl, Alt, and Del keys in a different location from those in the animation, which were all on the bottom row. Being an experienced NT user was helpful, or I might not have figured out how to log on to the system. (Hello, Tech Support? My keyboard doesn't look the same as the one in the picture. Is something wrong with my computer? Or did I just get the wrong OS?)
I am annoyed that the target market for Win2K Professional (Win2K Pro) is now the totally inexperienced user. Changing the Win2K Pro UI to make it overly simple seems to be an odd choice for a business OS. You would also think that with 80 million plus copies of Windows versions floating around, the number of people in the business world who don't understand the basic concepts of using Windows is pretty small. The next generation of computer users has mastered these concepts already; my 7-year-old daughter understands what pressing Ctrl+Alt+Del does, and I had to explain the meaning only once.
Also, designing for the lowest-common-denominator user doesn't seem to be consistent with Microsoft's strategy to push into the enterprise market. When I talk to the Microsoft employees on the server side of the house about these UI changes, they just mumble something and shake their heads. These people know that they will inherit the same UI on the server, and what makes life easy for a new user on the workstation product is often just an annoyance to knowledgeable server users who need to do their work with minimal interference. I'm hoping that I'll be able to turn off the little helpers that Microsoft thinks the end user needs. After all, I know how to right-click.
While I'm beating on Microsoft and Windows' usability, let me turn my focus to Office 2000. For the most part I do like the program, although it doesn't seem to offer a compelling upgrade from the previous version of Office. But if you're planning to make the move to Office 2000, you probably won't be disappointed.
A couple of things in Office 2000 make me nuts. The first is the installation mechanism. Although Microsoft improved the mechanism since the beta, the install-on-demand feature can be quite annoying if you don't do a complete custom installation. Although some reviewers have mentioned how easy the install-on-demand feature is to use, they obviously haven't tried to live with it. With the last beta before Microsoft shipped the gold code, I departed from my usual practice of installing the full program and selected Typical as my installation option. This choice was a mistake. At least twice a day for the first 2 weeks of using the Office suite, the Microsoft Installer launched, prompted me for the Office CD-ROM, and installed the new feature I requested. After the third or fourth time that I had to wait for a new feature to install, I was fed up with the install-on-demand feature. After 2 weeks of working with the suite, Microsoft Installer stopped launching, but I'm afraid when I choose a feature that I haven't used before, the process will start all over again. The straw that broke the camel's back was when I tried to open an ASCII text file and the installer launched because Office needed to install the appropriate file converter. Microsoft has assured me that it has changed this behavior in the final release, and a Typical installation will install a broader selection of standard features.
My last rant for this column deals with another high-profile feature in Office 2000: saving Word documents in HTML. I tried converting Word documents to HTML, although the idea had never sounded great to me. If you've standardized on Office, why do you need a platform-independent way for your intranet users to view company documents?
A friend of mine sent me a list of car camshaft profiles that I decided to post on an automotive hobby Web site that I run. Given that the list is part numbers with attached numerical information relating to camshaft performance, I didn't feel like typing all the information into an HTML table. The list had about 80 lines of text, and the ASCII file was about 3KB in size. I loaded the ASCII file into Word 9.0 (i.e., the Office 2000 Word version), made the list into a table, and saved the document as HTML. With no problem and no worries, Word 9.0 gave me an ugly, but viewable, HTML page. Word 9.0 had also turned 3KB of text into a 48KB HTML document. If you want to see the bloated code that Word created, see http://www.cgroup.com/david/cam2.htm, right-click, and select View Source. I am scared to think about how big the document would've been if I had tried to dress it up to any significant degree. A 16-to-1 inflation ratio was bad enough. Using the same information, I hand-coded the HTML to create the table and the resulting file was a little more than 5KB in size.
On the plus side, I used Word 9.0 to create a couple of HTML documents that were mixed text and graphics, and the pages came out in reasonable sizes. When saving the pages, Word organized the images into a folder and correctly created the appropriate link information. So using Word as an HTML editor might have value, but the jury is still out. Stay tuned for further misadventures.
