"Software suppliers are trying to make their software packages more user-friendly... Their best approach, so far, has been to take all the old brochures, and stamp the words user-friendly on the cover." - Bill Gates
After decades of user feedback and research there are still many issues with the ever-changing Microsoft® Windows™ user interface.
Responsiveness
First a short explination of how computers can do many things at one time. Single processor personal computers and servers can technically execute one instruction at a time. Techniques in most operating systems provide for the execution of multiple programs by quickly swapping instructions for each program through the processor, called multiprocessing. The same technique within one process, allowing multiple paths of (virtually) simultaneous execution, is called multithreading. Multiprocessing is what's used to allow users to run more than one program at a time, such as a web browser plus a word processor. Multithreading is used to have a program perform more than one operation at a time, such as letting the user type while searching text.
That being explained, a pleasing user experience can be created using multiprocessing and multithreading. User interface design is all about providing what the user wants or needs in the most pleasing manner. In theory, a user never needs to be blocked from interacting with the entire user interface. Actions which the interface needs to perform can be forked so it can still react to user input. Usually a wait of more than 0.3 seconds by a user is considered long. Beyond that delay most users consider the system's response to be slow.
Part of the basic design for window managers of the X windowing system (used on Linux, Unix, and variants) has application window borders execute in a process separate from the application itself. This means while the application process is busy, the user can still resize and move the window containing it. Within a program many applications are written to let the user interact at any possible moment, sometimes even during heavy hard disk usage.
Microsoft® Windows™, however, has never adapted these fundamental designs in user interface. Technically, applications are executing Windows' windowing APIs within their own thread of execution. The implementation of the APIs does not use a separate process or thread to draw the user interface. Therefore if a program is processing something time consuming, such as reading or writing to the hard disk, the user is not able to resize or move the windows. In fact, the window will not even redraw itself if overlapped, at least keeping aesthetics pleasing. Microsoft applications themselves also do not appear to be multithreaded. For example, pressing the F1 key in any application will cause hard disk activity, sometimes extensive, preventing the user from continuing in their activity such as typing. While a user is typing documentation could be searched in another thread or process to accomodate the user and appear when ready. Microsoft doesn't appear to have learned from user feedback or the examples presented by other successful projects in how to keep the user interface responsive.
The most frustrating example might be the main interface application itself. The Explorer application (not exactly Internet Explorer) is responsible for maintaining desktop icons, the background, the task bar, file browsing, and a few other things. Its lack of multi-threading or multi-processing for the user interface becomes a problem when it's busy with other work, such as browsing files over a slow network connection or determining the options for the "New" file menu.
User Interface Design
Good user interface design is very much a matter of personal taste. Many things, however, can be agreed upon by most. There is a variety of counter-intuitive and wasteful design features in Microsoft® Windows™.
Inconsistencies
While Microsoft touts the virtues of clear and consistent interface design to software developers it does not follow its own suggestions. Some common interface functionality, such as file open and save windows, are built into the desktop of the operating system to free application developers from constantly recreating them. If the operating system is upgraded the common functionality across all applications can be improved with no changes needed to those applications. Yet each major revision of Microsoft's desktop applications show very different interfaces. The file open and save windows are not being created by the Windows OS as Microsoft suggests. The menu design is also different and unique. Microsoft's desktop applications having a unique interface often causes inconsistencies when compared to custom applications or applications from other vendors adding to user discomfort and confusion. The Windows design guidelines published by Microsoft are not consistant across major Windows releases, forcing software developers to drastically modify applications if they want to fit into each Windows "experience." Otherwise they face users seeing their application interface dated when upgrading Windows.
Users should be free to choose a desktop look and feel they like. The applications they use should conform to their choices. In other words, the common features such as application windows, menus, and file operation windows should be controlled by the desktop and the user's preferences. Applications should only call upon the desktop to create these common features instead of drawing them independantly. This provides a much more pleasurable user experience within desktops such as Gnome and KDE. The lack of this consistency causes confusion among Microsoft applications.
Windows XP Taskbar and Application Windows
Most applications running outside of focus must be clicked once to get focus and again to perform the desired action. A user often can't close a background window, for example, by clicking the close button once. Even worse, this isn't true of every application; each may act differently. The Start menu seems to have a similar problem. Often items in the root of the Start menu must be clicked twice to launch.
A visible application can usually be minimized by clicking on its button in the taskbar. However, some applications, such as Outlook XP and Word XP, do not respond to this action. It's another inconcistancy that frustrates users.
Also, there are still applications which can not be accessed from the Start menu after a default installation. The only two ways to access the Task Manager without manually launching the executable is to use the Ctrl-Alt-Delete key combination or to right-click in an unused portion of the Taskbar.
The Start Button
Click on "Start" to raise a menu of programs and common tasks. Also click on "Start" to log off or shut down. Having to "Start" in order to end is counter-intuitive.
Ctrl-Alt-Delete
The Ctrl-Alt-Delete keyboard combination has traditionally been used to instruct a personal computer to reboot. This seemingly odd combination of keys was chosen so a reboot instruction could be sent directly to the computer hardware with the software being very unlikely to use the same combination for anything. Microsoft decided to change this by capturing this keypress, starting with Windows 95 on home computers and Windows NT on workstations. This odd key combination grew to be a requirement for logging into a Windows operating system, and can later be used to bring up some system options. It's odd that after so many years of development the awkward combination of Ctrl, Alt, and Delete is still a requirement for using Windows. The only reason for still requiring its use is reluctance to break from the past.