Interface, GUI Annoyances

Interface, In Your Face, and Assorted OS Annoyances

Gripes Get GUI

Most people who discredit the Mac have never used one. If I am to be any different (that is, more credible) in my critical appraisal of Windows, then, it must come from using it. Well, I have and I do. I have no choice: if you're going to build pages for the Web, you have to test them, not only on different browsers, but on different operating systems as well. Furthermore, much of my database development is for Windows-based networks. And lest we forget, most technical supported required by end-users is for Windows OS platforms and related hardware-connectivity snafus.

That all said, Windows® has steadily improved in its evolution and, in many ways, is more Mac-like. But don't get me wrong: it still cannot be mistaken for the MacOS.

Why? Not just because it runs on Intel, AMD and Cyrix processors instead of those by Motorola. No. One of the primary shortcomings of Windows, both 95, 98 and NT (whose subsequent iteration also adopted the a year-based moniker, Windows 2000®) is this: its GUI (graphical user interface) is not just flawed, but is incomplete in its execution. For example:

You must go to the "START" button to find the "SHUT DOWN" command. Unless you acclimate yourself to the notion of "starting to shut down," either the command is in the wrong place or the "START" button should be called something else.
The FIND function often turns up incomplete finds. And, yes, it even falls down when you remind it to "search subdirectories." Files I know exist consistently turn up absent in the find function's results window. Now that the MacOS can find text within files and even across the Net, Windows has got some major catching up to do.
The Windows task bar may be a nice "innovation" — but it's a flawed and incomplete execution. Considering that Windows supports drag-and-drop, it is logical that you should be able to drag a file icon onto an appropriate application button on the task bar, but doing so does not launch the file in that application. Instead, Windows gets confused and complains that something was done wrong. Yeah: it was done wrong in Windows, by Windows itself.

A small Mac shareware developer called Proteron recognized the value of the task bar, if only it were completely designed and executed. The result is "GoMac™" (now owned by PowerOn Software)— a Windows task bar for the MacOS that succeeds where Windows own task bar falls short.
While there may be one benefit of having no icons of volumes mount on the Windows desktop (that is, you can't accidentally copy and bury a file across volumes by accident) there a more considerable shortcomings. Most notably, it is more time-consuming having to launch Windows Explorer™ or open your "MY COMPUTER" icon to see your volumes. Furthermore, it may be the only way to confirm whether a volume, such as a floppy disk, is even resident (i.e., mounted) in your drive. The incomplete use of the desktop metaphor adds steps to the end-user process and, in some cases, even leaves the end-user clueless. (However, this is more easily gotten used to, as users of the new Mac OS, OS X, have the option of doing — that is, removing volume icons from the desktop.)

Of course, you might contend that an operating system's merits come from its core code, infrastructure and functional efficacy — and that a GUI is merely a superficial skin. Fret not: Windows' problems lie beneath its surface skin as well. Consider these:

Windows' fundamental reliance on file extensions leaves it too easily fooled. I know that users don't necessarily have to follow the DOS World's "8.3" extension anymore but, underneath, it's still there. This file-mapping scheme is primitive, at best, but also makes it unreliable. Don't forget that vintage WordPerfect^® documents defaulted to the ".DOC" before the venerable ".WPD" came on the scene. But what is the current default extension for Microsoft Word^® documents? You got it: ".DOC." There are yet worse examples that have rendered files unopenable by the otherwise proper application, merely because of a file-mapping problem.
The MacOS, on the other hand, is fundamentally immune to this problem, unless you are a power user who enjoys playing with type and creator codes that are otherwise invisibly and inextricably linked to a file and its icon within a file's resource fork. (Or, with Apple's new Mac OS X, then file forks can likewise will give way to a UNIX-based file system more similar, although more powerful, than the DOS-based Windows file-naming system.)
It provides users a "DLL Hell" without equal. No other major operating system allows "dynamically linked library" files to wreak such havoc on applications as does Windows. Not even NT properly addresses the consequences of an installed app with, say, "abc123.dll [version 1B]" overwriting another application's successful use of "abc123.dll [version1A] — suddenly rendering the latter application either unstable or unusable. The MacOS is only occasionally victimized by a shared library crisis, and the various iterations of UNIX and even OS/2^® have far superior means of averting DLL conflicts, overwrites or other incompatibilities. Has Microsoft no competitive incentive to fix this problem?

As I have said elsewhere in this site, I believe OS X has matured into an incredible operating system: Its Panther iteration is a great blend of sophistication, speed and integration of UNIX with a well-devised GUI. The added features of Tiger (as of 10.4.2) simply give Windows more to try and catch up with when Vista is released, presumably at the end of 2006.

It is interesting to watch how the interface conventions of OSX have evolved as a result of continuing feedback from a growing user base. The original Rhapsody development version paid little homage to the evolved interface conventions of the legacy Mac OS. The OS X Beta release of 2000 showed that Apple was listening, but had a long way to go. When the first public release of 10.0 came in March, we saw the promise of the new OS, along with many significant improvements to the user interface and how it permitted facile access to the operating system despite its UNIX underpinnings and Mach kernel. Too bad Windows hasn't shown an equivalent amount of maturation in this regard, although I must confess to having far fewer complaints about the OS since the launch of a cleaner, robust, NT-derived Windows 2000. Even when I must use XP, I prefer to change the desktop and GUI to the cleaner, classic look.