Article 11222 of comp.sys.mac.system:
Path: doug.cae.wisc.edu!uakari.primate.wisc.edu!ames!ncar!hsdndev!yale!umich!terminator!potts
From: potts@itl.itd.umich.edu (Paul Potts)
Newsgroups: comp.sys.mac.system
Subject: Windows 3.0 review - LONG
Message-ID: <1992Feb20.220202.20648@terminator.cc.umich.edu>
Date: 20 Feb 92 22:02:02 GMT
Sender: usenet@terminator.cc.umich.edu (usenet news)
Organization: Instructional Technology Laboratory, University of Michigan
Lines: 921
Originator: potts@helen

Presented for your entertainment and aggravation:

This is a LONG article which is basically a review of Windows 3.0.
It was written almost a year ago, from the perspective of a then-
primarily Mac user who was interested in seeing how DOS and Windows had
progressed. Now, I spend much of my time working on instructional multimedia
apps for the DOS/Windows platform, and the latest version of Windows I am
using is 3.1 release candidate 1 (not yet shipping), with Multimedia
Extensions. Quite a few of the problems listed in the article below have been
solved, but a number have not. Some of the comments I made at the time, I
have since found are incorrect. For example, Windows doesn't support
preemptive multitasking between applications. The cooperative multitasking
scheme that it does use is similar to the one used by the Macintosh, with
segmentation and memory protection. Also, a number of things have changed:
for example, there is a now a Word for the Mac export filter in Word for
windows 1.1a. However, for some reason I still can't get it to write a
file with graphics that Word for the Mac can import.

I am posting this because I received numerous requests for my "30-page article"
on Windows. Despite various strategies, I have been unable to import the
file from Word for Windows 1.1a to Word for the Mac (4.0). I'll give 5.0 a
try. Without the pictures, the file isn't nearly 30 pages in length, but
there also isn't much point to providing it with elaborate formatting.
Therefore, here's the text-only version. While posting it, I noticed a few
typos, but I'm not going to go back and fix them at the moment.

If you would like a Word for the Mac version of this file, without pictures,
please send me e-mail. I can also provide a Word for Windows version, with
pictures, but will have to provide it as a Binhexed Mac file. You will need
a utility like Apple File Exchange or DOS Mounter to get this file onto a PC
disk after un-binhexing it. 

Without further ado, here is the file "Confessions of a Windows User" (without
graphics, and without apology).

--------------------------------

  CONFESSIONS OF A WINDOWS USER

(Written roughly a year ago)

I design instructional software for the University of Michigan. In
my short career to date I have had limited contact with DOS. My area of
specialty is the Macintosh. However, when I accepted my current job, my
new boss offered to loan me a Zenith 386 machine with eight megabytes of
RAM, a 150 megabyte hard disk, and a color VGA monitor, in order to give
me a chance to familiarize myself with the recent developments in the
world of IBM-compatibles. When he mentioned that it would come with a
mouse and Microsoft Windows, I jumped at the chance to see what all the
talk was about.

In this article I will talk informally about what I found, from
the perspective of someone who designs programs to be used by novice
computer users. In some ways I was extremely pleased with the
improvement to the DOS platform that Windows 3.0 represents. In others,
though, I am not. I am here to present a view that is, I believe,
balanced somewhere between the PC publications, which welcome Windows 3
as if they were welcoming the second coming, and the Mac publications,
that ridicule Windows as a cheap clone of the look, if not the feel, of
the Mac. The truth can be found somewhere in between, and I believe both
sides can benefit from listening to some of the compliments and
complaints of the other. Perhaps someday we will be able to choose a
user interface which combines the best of both worlds.

A GRAND SLAM HOME-RUN MAKES US ALL WINNERS?

Let's begin by taking a look at an example of the hype surrounding
the Windows launch. Michael Jones, in the introduction to the Vol. 2 No.
1 Windows Shopper's Guide, entitled "Windows 3.0: A Grand Slam Home-Run
Makes Us All Winners!" has this to say:

"Oh, what a relief and joy it is -- to
witness the rare occasion when a product lives
up to, and even surpasses the expectations and
the hype; [sic] delivering on the promise and
hinting at exciting things to come...

Thanks to Microsoft Windows 3.0 and over
800 applications from over 500 vendors; [sic]
all of us PC-based DOS users can now participate
in the GUI (graphical user interface) revolution
that is taking the computer world by storm....

...The reduced costs and efficiency [sic]
are there because Windows creates a standard
interface that only needs to be learned once..."
(page 1-2).

Ignoring the grammatical problems for now, I don't think I will
shock too many readers in either camp when I suggest that it is time for
a reality check. Pick up a PC magazine and look through the PC
Connection advertisements. How many applications that have been
specifically written to support Windows 3.0 are shipping? (Hint: the
number is nowhere near 800). To run well, Windows requires some pretty
flashy PC hardware, and flashy hardware is expensive. I don't think that
"all of us PC-based DOS users" have upgraded to the 386 machines which
are a necessity for true multi-tasking of DOS applications, or have put
in the extra RAM required to run Windows effectively in 386 enhanced
mode. So, Windows is not going to do much for the vast numbers of 8086-
and 80286-based PCs which are the workhorses of many, many offices.
But if you've got the iron, Windows does have a lot to offer.
Applications running under Windows are the best I've seen on DOS
platforms. However, the Windows interface is not a panacea. I would like
to talk a little bit about application interface consistency, the user
interface, and what I perceive to be some of the problems with the way
Windows implements it.

STARTING FROM SCRATCH -- INSTALLING WINDOWS

The installation process for Windows is clean and simple. I am a
person who hates to read manuals: thankfully, I didn't have to. Windows
3 scores highly when compared with many other DOS applications. My only
complaint with the installation process is that when I reconfigured
Windows to set the screen to VGA black and white (in order to take
better screen shots), it asked me for several of the Windows disks. It
asked for disk number 5, disk number 2, and then disk number 5 again.
Didn't Windows know in advance which files it was going to need, and
couldn't it have arranged them so that it required each disk only once?
Also, I often switch printers. Why should I have to stick my original
Windows distribution disks into my PC every time I want to change a
printer or change the default setting of my monitor? The Windows
installer application should have been smart, realized that I had lots
of free disk space, and asked me if I would like to install all the
printer and screen driver files.

Allowing me to choose which driver files I wanted installed would
have provided some of the flexibility that I am used to in Apple's
system software installer program. Apple wins in this respect. Although
it took a long time in coming, their installer program is simple, and
works well for both novice and experienced users.

GETTING HELP

The Help system under Windows really is easy to use. I would like
to see a system of on-line help like this come standard with every
Macintosh application. In this area, the Mac is losing ground. Perhaps
the balloon help promised with System 7.0 will improve the situation.
Every Windows application supports help, and although the location of
the Help menu varies from application to application, it is often
located on the far right of the menu bar. Although the menu location
varies, the function-key equivalent does not: help is always available
via the F1 key.

The applications that came with Windows (the Program Manager, File
Manager, Paintbrush, etc.) support a help that is highly visual, with
buttons that look similar to those on a NeXT system. Browse buttons
pointing forwards and backwards, an Index button, a Search button, and a
Back button (which takes you to the last item you were looking at) are
all quite reminiscent of the design of many Hypercard stacks:

Help supports hot words (in green type, with a dotted underline),
which instantly supply their own definitions when clicked on, and link
words (in green type, with a solid underline), which jump to a related
portion of the help text when activated. The cursor turns into a
Hypercard-like pointing hand when moved over any of these "live" words.
Unfortunately, the Search command supported in the Help facility
is extremely limited. It is not possible to search the text of the help
itself for words (for example, it can't find Scroll Bar or
Centimeters, both words which figure prominently in the Help text),
but only the pre-defined keywords which Microsoft elected to include. I
believe this is an important criticism. Shouldn't I be able to search
the on-line help for assistance with any command, dialog, or interface
object that is described in the help text itself?

In addition, I feel it is worth mentioning that two of Microsoft's
products for Windows, Word and Excel, use help systems which look and
act much different than the Help of the applications bundled with
Windows.

Gone are the NeXT-like buttons; instead, the commands are placed
in menus, with function-key equivalents which are inconsistent with the
key equivalents for the help system that came with Windows. Some
consistency in the help systems under Windows would have been nice --
where is the "standard interface that only needs to be learned once?"

ANY COLOR YOU WANT, AS  LONG AS IT'S MICROSOFT

Henry Ford is reputed to have said that you could have a Model T
in "Any color you want, as long as it's black." Let's look at
Microsoft's Program Manager interface as an example of just this sort of
illusion of choice.

When I began using Windows, the first thing I wanted to do was to
arrange the icons in the Program Manager's window the way I wanted them.
On the Mac, I like to have open windows, holding files or folders,
arranged in a tile formation on the left, and closed windows,
represented by folder icons, arranged vertically on the right. Under
System 7.0, the Finder even remembers the folders which you left open on
your desk. After all, on the Mac, the Finder's interface is designed to
represent a desktop. I should be able to arrange my desk the way I want,
without fear that the custodial staff will come and rearrange it during
the night, shouldn't I?

Enter Windows. When I had sized and arranged the windows and icons
to my liking, I quit Windows, saving the changes, and restarted. To my
dismay, all the icons representing closed windows had been rearranged,
stuck under one of the open group windows, once again lying in a row
along the bottom of the Program Manager window, their titles overlapping
and clipped by the visible region of the Program Manager's window. (See
below).

Figure: The Way I Didn't Want My Program Group Icons

Although earlier versions of the Macintosh system software
occasionally manipulated your icons in a similar fashion, later versions
allow you to leave your icons in pretty much any configuration you would
like. It seems like it should have been a simple matter for Microsoft to
store icon positions between Windows sessions.

My next run-in with the arbitrary limitations imposed by Microsoft
came when I attempted to create a program group within a program group
(like a nested folder). This is a very obvious and intutitive thing to
do if you consider your GUI to represent the file structure of your
computer's hard disk drive. After working on the Mac, where Folders are
used to store files in a heirarchy, or on a PC, where subdirectories are
used, it seems rational to want the same ability under Windows. Windows
won't allow it. But, as we shall see, the icons one sees under the
program manager, representing program items and groups, have very little
relation to the file system on the hard disk.

NO SIMPLE SOLUTION

When you create a file on your hard disk, Windows does not
automatically create an icon for that file. And, as we shall also see,
it is no picnic to try to create one.

Suppose I have saved a draft of this review on my hard disk C: in
the subdirectory C:\DOCUMENTS\OIT. The name of the file is REVIEW.DOC.
Word for DOS understood that it should be able to open all files with
the .DOC extension. Let's examine the process of creating a Program Item
for that file, so that we can view it as an icon.

First, we select the "program group" in which we would like to
place the icon. The program group is the equivalent of a folder, and the
icon is called a "program item." In my case, the program group where the
icon is to be installed is called "Document." Then, choose New... from
the Program Manager's File menu. The following dialog appears:

We want to chose "Program Item," which is already selected for us.
(The subtle linguistic distinction between "item" and "object" is beyond
me). Next, we click on the "OK" button. Another dialog appears.

Windows wants us to provide a description of the file: this will
be the name that appears under the icon. Then, it wants the DOS command
line: the complete path and filename necessary to invoke the file. Think
fast: what was the full path and file name of my document? Wait a
minute. I thought the purpose of Windows was to make life under DOS
simpler!

Help is available. If you can't remember the full path and
filename of the file you wish to associate a program item with, click on
the Browse... button. This brings up a window which looks something like
the Mac's standard Get File dialog:

Get used to this window: if you work with PCs, you will be seeing
a lot more of it. Many applications are using file-retrieval dialogs of
similar design, and all the Microsoft Office products use it, with the
notable exception of Excel. (In Excel, if you want to save a file in any
location other than the default path, you must type a complete pathname
for it. Don't ask why).

In this file retrieval dialog, it is possible to use the [..]
directory symbol to move up the heirarchy (this is  intuitive if you are
used to using CD .. to move up a level in DOS). The current directory is
listed on the top of the dialog: C:\document\oit. We are in the right
place, so where is our file REVIEW.DOC?

It is there, it's just that we can't see it. The file filter,
above the path name, limits the files we can see to those matching the
pattern we have typed into the filename field. The default pattern is
*.EXE. This is the first of a number of subtle clues which indicate that
the Windows GUI is really designed to make it easy to get to your
applications, not your documents. Why? Which kinds of files are we more
likely to alter with on a day-to-day basis, documents or executable
files?

To see our REVIEW.DOC we must replace the .EXE with .DOC (or .*).
Then we can click on the name of our file to place it in the Command
Line field of the Program Item Properties dialog. Now we have something
that looks like this:

Click OK and an icon ("program item") for our file appears in the
program group window.

But wait! Our trials are not finished. Why does it have that icon
that says DOS? Doesn't Windows know that files that end in .DOC are
files for Word? Isn't there some kind of document icon it should have?
Yes and no. Windows keeps track of the relationships between
extensions and associated creator applications (as is done on the Mac
with creator type and file fields) by including in the WIN.INI (Windows
Initialization) file a table of associations. The table in my WIN.INI
file looks (in part) like this:

[Extensions]
tbk=toolbook.exe ^.tbk
doc=winword.exe ^.doc
dot=winword.exe ^.dot
rtf=winword.exe ^.rtf

We see that the .DOC extension is indeed mapped to WINWORD.EXE
(the Word for Windows application). So, if we double-click on our new
program item icon, it runs Word for Windows and open the appropriate
file. Quite an accomplishment. (Ignore for the moment that the Macintosh
was doing it in 1984).

But what about that icon? If Windows knows that the .DOC extension
means this file belongs to Word for Windows, why doesn't it have a nice
icon for my file that visually identifies it as a Word for Windows
document?

I had to dig into the manual for an answer to this one. Windows,
it seems, only keeps track of icons for applications (.EXE files), and
then only if an icon (.ICO file) is available. If I want Windows to know
that my file is a Word for Windows file and should have a Word for
Windows icon, I need to put the following into the Command Line field of
the Program Object dialog: C:\WINWORD\WINWORD.EXE
C\DOCUMENTS\OIT\REVIEW.DOC. Now my Word for Windows program item (which
is a document) looks like this:

This is the same icon as Microsoft Word for Windows! What gives?
Isn't there an icon for a Word for Windows document file? No. After
going to all that trouble to give my program item an icon, it is the
application icon that it gets. (Notice the application-centrism Windows
is again exhibiting). There is a Change Icon button available for
program items, but the View Next button doesn't do anything (it should
be dimmed, but isn't). Looks like we are stuck with that Word for
Windows icon.

Now, there may be a way to make my own .ICO file and use it to
associate a unique document icon with .DOC files, but I haven't figured
out what it is yet, and it isn't transparent from reading the
documentation. Microsoft could have thrown in an icon editor, if they
intended to provide such a limited number of ready-made icons.
Keep in mind that if I ever move or rename this file under DOS or
by using the File Manager, Windows won't know where it is until I change
the path and filename information in the Program Object Preferences. If
I forget, there are plenty of grumpy "file-not-found" error messages to
let me know. All of our work has gotten us an icon for my file, giving
me the honor of opening my file by double-clicking on the icon, but more
work will be required if I ever need to modify or repair my GUI.

THE BIG PICTURE

Now let's backtrack a moment and think about the point of all
this. What is the real purpose of attaching these program items, with
titles and icons, to our files? It seems to me that the reason is really
to get around the limitations of DOS file management. DOS, even DOS 4.01
and the beta version of 5.0, still limits us to an uncommunicative
eight-character filename, followed by a three-character extension. But
if the purpose of Windows is to make manipulation of these files easier,
why do I so often find myself pulling up a DOS window under Windows to
do manipulation of files on my hard disk?

Now for some of the things I do like. I do like the fact that the
Program Manager provides a visual way of keeping track of commonly used
files. I do like the mechanism for shrinking file groups (folders) to
icons. This mechanism should be built into the Macintosh Finder. I do
like what limited flexibility there is in the arrangement of these
windows. I do like the support for dialogs, such as the File Browser
dialog, which look like modal dialogs but which can be left in the
background. System software designers for the Macintosh could learn from
this idea.

Windows claims to provide a consistent graphical user interface
for other applications to use, like Apple's system software. Let's take
a look at some of the inconsistencies that make it so difficult to
consistently like even the elements of Windows that appeal to me.

WINDOWS WITHIN WINDOWS: TRIAL BY INCONSISTENCY

Some applications programs, such as NotePad, Terminal, and
Paintbrush, use a single movable, resizable window. Others, such as Word
for Windows, Excel, and the File Manager, use two or more: an outside
window containing one or more document windows. This scheme is designed
allow the user to open several windows associated with a single
application, while still maintaining a clear visual link between windows
belonging to the same application. I like this idea in principle,
although I suspect it would work in practice much better with large
screens, where the user could place the parent windows side by side
instead of stacking them.

Applications which support this windows-within-windows scheme also
allow the user to shrink document windows to icons within the framework
window. This feature works quite well under applications like the File
Manager and Program Manager. However, Word for Windows does not support
this feature, nor does Excel. Under Microsoft Word and Excel, the box-
within-box scheme makes simple tasks, such as shrinking a document
windows, surprisingly difficult. Let's take a look at the way in which
Microsoft took a relatively simple window-manipulation scheme and made
it more difficult to use.

Upon startup, Word for Windows opens a full-screen parent window
that cannot be resized. You are effectively prevented from getting at
any windows that may have been hidden. To resize the window, you must
first click on the zoom box in the upper-right corner. This shrinks the
outer window to about two-thirds of the screen's height.

Once this is done, though, the inside window, containing a view of
your document, no longer behaves like a window. It cannot be resized
within the framework window, has no title bar of its own, and instead of
the "-" which would normally appear in the top left corner of its title
bar, has a special "-" menu which is part of the menu bar itself. This
scheme does provide more room for editing within the text window, but
the inconsistency in the window's behavior is confusing.

If you now choose the New Window menu command, a new window is
created onto the same document. However, unless you look at the title
bar, which changes to include a ":2" after the name of the document,
nothing appears to have changed. The new window completely obscures the
old one. Choosing Word's Arrange All menu item, or the "Restore" menu
item from the "-" menu, shrinks the current window enough to allows it
to be resized, and tiles the windows. If Microsoft had simply provided a
shrink button and a "-" button, both of which remained visible when the
window was at maximum size, this would be much less confusing.
Microsoft's approach to a standardized user interface appears to be to
stick to the standard -- whenever it is convenient.

WORD IS LOOKING FOR A FEW GOOD KEYS

There are a lot of things about Microsoft products that I like.
For example, I like the fact that in dialog boxes, it is generally
possible to use the tab key to move from one button, field, or check box
to the next, and even to use the spacebar to check or uncheck a check
box, and the arrow keys to move between choices in any given set of
radio buttons. As on the Macintosh, a double-thick line appears around
the default button (the button which will be chosen if the enter key is
pressed). Microsoft uses a faint grey dotted line around a button, check
box, or radio button which has the current "focus" (is currently
editable with the keyboard).  This is a clean, sensible extension to the
dialog model.

I am also a big supporter of keyboard equivalents for buttons. I
like being able to answer a yes or no question by pressing the Y or N
key, something that is still not standard on Mac software (see my
article in MacTutor, April 1990). Are you listening, Apple? Microsoft,
though, really tends to go bonkers with key equivalents in dialogs. For
example, look in Word for Windows at the Paragraph... dialog, available
under the Format menu. For alignment we have L for left, C for center, R
for right, and J for justified. This makes perfect sense. However, do we
really need to have N for first line indent, F for indent from left, and
G for indent from right? How about H for "Keep Together?" And Why didn't
Microsoft pick a key equivalent for the "Line Numbering" check box?
Because just about all the possible key equivalents were used up, that's
why. In my opinion, if a feature can't be added cleanly, leave it off.
Leave off "H" for "Keep Together." H for "Keep Together" should go. It
is not mnemonic, and an easy method for getting to the "Keep Together"
check box via the keyboard already exists -- the tab key.

INCONSISTENCY: THE HOBGOBLIN OF MICROSOFT PROGRAMMERS

Since we are on the subject of keyboard equivalents for buttons,
what about keyboard equivalents for menu items? In Word for Windows,
"Save" is Shift+F12, while "Exit" is "Alt+F4." "Save as" is F12. Undo,
which should be the single most easily available command, is
"Alt+Backspace." "Thesaurus" is "Shift+F7," Styles" is "Control+S," and
"Print" is "Ctrl+Shift+F12." (Boy, F12 is a busy function key!) Got that
memorized? Good.

Now, pressing the Alt key alone allows you to manuever around the
menus with the arrow keys; this is a nice touch, but why not use the
Escape key as well, to maintain some touch of compatibility with Word
for DOS? Now for another detail to remember: there are also key
equivalents for menu items, such as "S" for Save, but they are menu-
specific. These key equivalents are represented by underlines. If I want
to use "S" to save, it only works if I have pulled down the File menu,
either by using the mouse or by hitting "Alt," to go into menu mode, and
then the appropriate arrow keys. Pressing the "S" key when I have the
"Format" menu down chooses the Section dialog instead, so context is
very important. Pulling down each different menu, in fact, puts Word for
Windows into a slightly different mode.

To give Microsoft credit, it is often easier to use "Alt" and the
arrows then it is to take my hands off the keys and use the mouse. To
software designers, though, the evils of too many modes should be well
known by now. Hit a key in the wrong mode and you have done the wrong
thing, perhaps without realizing it.

A MEMORY LIKE AN ELEPHANT

Let us assume for the sake of argument that I can memorize Shift-
F12 for "Save," since it is simpler than learning Alt key, right-arrow
key, down-arrow key, S. Now I switch to Excel. I type in some numbers,
and hit Shift-F12. It brings up the Save dialog box. Terrific. However,
the function-key equivalents aren't listed in Excel's menus. So if I
forget Shift-F12, I can at least be thankful that Alt right-arrow down-
arrow S still works.

Now that we have established that there is some consistency
between Word and Excel, let's look at Toolbook a few other programs.
Hold on, the ride gets bumpy here!

It is nice to see that Toolbook, Paintbrush, Arts and Letters,
NotePad, Paintbrush -- indeed, all the Windows applications I've seen --
support the Alt key plus the arrow key to get around the menus. F1 is a
system-wide standard for Help, and Alt+Backspace generally undoes the
last action, if it is undoable. The standard Edit functions -- Cut,
Copy, Paste -- are supported by Shift+Delete, Control+Insert, and
Shift+Insert, respectively. Easy to remember. This gives us a simple and
rather intuitive set of key equivalents to fall back on. What about
control and function key equivalents, though? Let's take a look.
NotePad does not support any of the same key equivalents that
Windows or Excel supports, and it does not have any key equivalents for
Save and Print.  To the Arts and Letters Editor, Save is F9.  To
Paintbrush, it is a simple Control+S. Control+O, though, instead of
being Open, as you might suspect, is Zoom Out. The Terminal application
has no key equivalents for Save and Open.

Has Microsoft released no Human Interface Guidelines for its
developers? Things are not all roses in the Mac universe; as Apple fell
behind on human interface issues such as pop-up menus, movable modal
dialog boxes, keyboard equivalents, etc., other developers have moved in
and set de facto standards. Microsoft, though, has always been one of
the worst offenders when it came to nonstandard standards.  And now it
appears that third-party developers of software for Windows are just
following Microsoft's example.

A POWER USER'S NIGHTMARE

Windows, and the applications that come bundled with it, are laden
with bugs, and give me problems often. Some of them are minor, like a
recurring problem in Word for Windows that causes the program to devour
text on the screen as fast as I type new text, or a condition in which
the ALT key stops functioning, and can be solved by restarting. Some of
these bugs aren't so minor. Admittedly, much of this code is new, and I
would expect a few problems, but in software this long-awaited, and from
such a reputable company, there is no excuse for the number of problems
I have encountered.

Brett Glass in BYTE wrote about the problem. Speaking of the
Paintbrush program, he notes "as soon as I tried to use the scroll bars
to move about the image, the program crashed." I have had similar
problems with Paintbrush. He talks of problems with the Terminal
program: "Suddenly, Windows decided that my terminal emulator -- a
faithful program that had exhibited no bugs -- had 'violated system
integrity' and terminated it automatically..." I have had this problem
as well, which then led to an endless string of "System Error" messages
when I attempted to reboot. Finally, I had to resort to the old Control-
Alt-Delete -- unforgivable under a true multi-tasking operating system
that supposedly supports protected memory. And of course, when I
restarted Windows, my .GRP files had been partially eaten.

Some bugs are more subtle. Let's take a look at the Paintbrush
application for a few examples. My first complaint has to do with what
could be called a missing feature rather than a bug. Almost every
Macintosh painting program since FullPaint allows auto-scrolling. That
is, when you are drawing or selecting, and drag the pointer outside of
the currently visible part of your picture, your picture is scrolled
automatically. This allows you to work with objects bigger than the
rather small visible window on your document. Paintbrush doesn't support
auto-scrolling. What is worse, Paintbrush doesn't seem to support any
operation which operates beyond the bounds of the visible window. So, if
I copy a graphic image from Arts and Letters Editor or take a screen
shot, Paintbrush will not allow me to paste in this image without
cutting off most of it, even though the page is big enough to accomodate
the whole thing.

Why do we put up with this? Do I have to buy Corel Draw to work
easily with large images? Given that so few Windows applications are
shipping, it was especially crucial that the bundled applications
represented a decent, useful, although understandably minimal, set of
tools. Microsoft's definition of useful is certainly not mine.
Next, let's take a look at a bug so subtle and strange it caused
me to doubt the evidence of my senses. In some very early Macintosh
painting programs, selecting an area of your painting with the marquee
(selection box) tool and then cutting it left behind the pixels directly
under the selection rectangle itself. In later painting programs, these
pixels were generally included in what was cut to the clipboard. No
single method is intrinsically correct: the first lets you see more
easily exactly what you are cutting, though. And when doing detailed
work it is important to know what will be cut, and that this tool will
behave consistently. Now enter Paintbrush.

When you cut a rectangular-shaped region of a drawing in
Paintbrush, the pixels directly under the left and top edges of the
selection rectangle are cut, but the pixels under the lower and right
edges are not. You may think my criticism is just nitpicking, but in my
work designing Toolbook pages with graphic images, it is important that
I can easily manipulate, crop, cut, and paste parts of images. When I
first carefully selected and cut part of a digitized bitmap, only to be
left with extra pixels on the right edge and bottom, I squinted at the
screen and tried again. I was at first convinced that my eyes were
playing tricks on me. Then it dawned on me what was happening, and I
realized that no one at Microsoft had bothered to test this software by
using it to do real work.

UNDER THE HOOD

Windows sometimes strikes me as a cadillac driven by a hamster.
While the GUI is attractive, the mechanisms running underneath the flash
just aren't up to snuff. For example, It should not have been
excessively difficult for Microsoft's programmers to support some means
of nested folders (program groups). Instead they chose to associate each
program group with an open .GRP file. Perhaps one open file, with a data
structure of sufficient complexity to describe nested groups, would have
sufficed.

Why doesn't Windows, which is powerful enough to support true
multitasking and virtual memory in 386 enhanced mode, include a utility
which could run in the background and collect document files, creating
icons (program items) for these files as it goes, assigning icons on the
basis of the standard DOS extensions? This kind of utility could go a
long way towards taking some of the burden of creating the GUI off of
the user by providing a sort of minimal "default" set of program items,
which the user could then customize. Once the hard disk had been
cataloged and the files made available as program items under the
Program Manager, the program could scan the disk periodically, keeping
the graphic depiction of the hard disk's files consistent with the
drive's actual contents. A utility program like this could help remove
some of the unnecessary and confusing distinction that Windows makes
between the files on the disk and the visible program items presented by
the Program Manager.

85% OF A MACINTOSH?

When IBM managers say things like "Windows provides roughly 85% of
the functionality of the Macintosh," be careful how you interpret that
statement. Even the original Macintosh 128K allowed folders within
folders, although they were not supported by the underlying Heirarchical
Filing System as they are now. The Macintosh couples the GUI very
tightly with the file itself; we see the heirarchy, online volumes,
subdirectories, etc., all represented cleanly as windows and icons. The
characteristics of a file (the application that created it and the type
of file it is) are associated directly with the file, and transparent to
the end user. The filing system of the Mac was created with the GUI in
mind.

By comparison, Windows fakes it by creating a whole host of files
with extensions like .GRP, files that remain open while Windows is
running. Since all these .GRP files remain open as long as Windows is
running, when Windows crashes they are often damaged and must be
recreated. (Although crashes of applications under Windows tend not to
take down the whole Windows system, when the Program Manager crashes it
tends to take its .GRP files with it). So, although the system is fairly
stable, crashes that do occur tend to be more devastating than they are
on the Macintosh, as the program group files you have just built get
destroyed.

THE BEAUTY IS IN THE DETAILS

My other gripes with Windows can be summed up by the term
"aesthetics." The attractiveness of the Macintosh interface is conveyed
through the smooth feel and consistent graphics performance of the
Finder and applications programs. Windows, although the Program Manager
can look good on a good monitor, has not achieved the aesthetics and
responsiveness of the Finder. Why, for example, do my color icons turn
black-and-white while I drag them around? Why do the scroll bars in Word
for Windows tend to flicker when paging rapidly through a document? Why,
when quitting an application, does the Program Manager refresh the
content regions of its windows so slowly even on my 80386-based machine?
Try dragging the cursor slowly down through the left margin of a
Word for Windows document window, then do the same thing in Word for the
Mac. Notice the flicker in Word for Windows? Observe the redrawing of a
large TIFF imported into the Arts and Letters Graphics editor, displayed
in 16 VGA colors, and then compare it to the way Illustrator of
Photoshop redraws a TIFF on the Macintosh in 256 or 16 million colors.
Open a Toolbook book with a large bit-mapped color graphics object, and
compare the time it takes (I have one which takes almost thirty seconds)
to the time it takes to open a similar window on a Macintosh running
SuperCard. Many users may not care about these details, but in
cumulative form they convey an impression of slowness, unevenness, and
shoddiness.

Ask an employee of Zenith why Toolbook is so slow, and they will
point to poor code. Ask someone at Toolbook, and they will point to the
speed of Windows and DOS. But DOS applications can be quite fast, and so
can Windows applications. What's going on here?

All the individuals who like to point the finger are failing to
take into account the importance of integrated design. The Macintosh
hardware and operating system is designed to support a graphical user
interface. QuickDraw, even on slower Macintosh models, is fast. Allowing
all the higher layers of the software access to the lower levels through
clean, well-designed software interfaces and glue speeds the entire
chain. Just because Windows, a multitasking operating environment
running in and on top of DOS works, it is not necessarily the best
solution. Unfortunately, it may become the standard solution, just as
DOS did. In this case, we are simply left hoping that incremental
improvements will help the situation.

MOVING WORD FOR WINDOWS: A JOURNEY THROUGH CONFIGURATION HELL

If you thought rebuilding damaged .GRP files was fun, try this
exercise: use the File Manager to move your copy of Microsoft Word for
Windows, with all its associated files and subdirectories, to another
place on your disk's heirarchy, then change the program manager item to
reflect the new path and filename. Now, run Windows and try to open your
favorite Word for DOS file. Go ahead, I dare you.

This beauty took me a week to figure out. Now, if you are the type
to read help files, you know that Word for Windows stores many of its
preferences and settings in a text file called WIN.INI. Setting
applications to open as minimized icons or run in full-blown windows
when you start Windows is as easy as entering their paths and filenames
in a list, sort of like a DOS "path" statement. Why there is no way to
set this up using the GUI, I don't know. Why must this process be so
much more difficult than using the Set Startup menu item under
Multifinder on the Mac?

After I used moved Word for Windows and tried to use one of the
translators, the application generated a series of system errors and
then quit. It was, it said, unable to find the translator files. I
looked in the directory with WINWORD.EXE; there they were. This
subdirectory was in the DOS "path" statement located in AUTOEXEC.BAT
(the "path" statement is important to applications running under
Windows, since they still use DOS to find files). Everything looked to
be in order. What was wrong?

Over the course of the next few days I tried to examine the
WINWORD.INI file (no dice: it is not a text file like the other .INI
files. Leave it to Microsoft). When I deleted the WINWORD.INI file, Word
for Windows thought that I had just installed it, and asked for my name.
So I tried reinstalling it from scratch. No help. I tried using the
Windows installation options to de-install, then re-install the
application into the GUI. That didn't help either. Then, just for fun, I
reinstalled Windows. Then DOS. Nope.

By now I was beginning to get annoyed. I decided to read through
the whole WIN.INI file just to aggravate myself further. There, staring
at me in black and white, was the answer.

Word for Windows, when you first run it, appears to write the
location of its translator files into a section of the WIN.INI file.
When you reinstall it, or move it, however, it doesn't update this
information. Even when you use Windows to deinstall the Word for Windows
program item, it stays. If you change the location of your Word for
Windows files, change the names of your subdirectories, or anything like
that, Word for Windows will bomb when you try to translate files, and
nothing you can do will fix it unless, like me, you happen to
accidentally stumble across the secret.

This is going to cost confused users dozens of hours of down time,
and for no reason. In an office where users will be using Windows and
Word for Windows on a trial basis, while leaving some machines running
Word for DOS, it is imperative that the translation process be as easy
and painless as possible. A week of pointless down time certainly
illustrates that Microsoft dropped the ball on this point.

The Windows Installation program has a clean approach to a similar
problem. When installing Windows, it reads your AUTOEXEC.BAT and
CONFIG.SYS files and suggests a set of changes to make Windows run more
smoothly. You have the option of viewing these changes, accepting them,
or making the changes yourself later, and Word keeps your old files with
the extension .OLD. Word for Windows has no such tact when dealing with
your WIN.INI file. If it crashed while modifying the file, Windows would
be disabled.

SUPPLY-SIDE BONUSES

One thing that Windows does supply is good International support
and a wide variety of printer drivers which can be called by various
Windows applications. It appears that Microsoft is moving towards
providing a standard "Windows toolbox" for programmers. I applaud such
standardization. It will simplify the work that developers must do.
Indeed, most of the enhancements that Windows offers are not the visible
advantages of the Windows GUI, but the improvements to the library of
routines available to the programmer, and the ability to multi-task
Windows and DOS applications.

For example, applications designed to run under Windows can all
use the Windows tookbox of routines to support a variety of video
screens, including 16-color VGA smoothly. Unfortunately, 16 colors is
the most that Windows currently supports, and 16 colors at VGA
resolution does not compare very well to Macintosh II-series machines,
with hardware available that supports from one to more than 16 million
colors, built-in support for multiple screens, and a graphics model that
offers device independence to programmers.

When programmers become accustomed to working with these available
Windows tools, we should see the level of sophistication in PC
applications increase considerably, particularly in regard to consistent
user interfaces, an area which has been long overlooked by many DOS
applications. It is even conceivable that future PC operating systems
may include as standard the libraries and run-time tools that Windows
provides, to allow Windows applications to be "plugged in" and run
compatibly under operating systems more advanced and flexible than DOS.
The future of Windows applications, however, remains to be seen.
THE AVERAGE USER AND WINDOWS

The average user of a DOS machine, a secretary, word processor, or
administrative assistant, generally has the minimal working knowledge of
DOS necessary to do the job.  I really can't recommend that consultants
try to move all of these users to Windows. In addition to learning the
intricacies of the Program Manager and understanding the non-intuitive
separation between files and their appropriate program manager items, it
would be necessary to give these users much more training on
subdirectories and file extensions. Knowing that clicking on the [..]
will move up the heirarchy one level requires knowing that a similar DOS
"change directory" command will do the same thing. Users who attempt to
create a program item for a file that they have just created, only to
find no files listed, will generally panic and call for help before
realizing that typing in *.DOC as a file filter will show their document
files. In addition, under the Program manager, there is still no way of
visually distinguishing one file type from another, or distinguishing
data files from the application which created them.

On the Macintosh, files do not appear to "disappear," leading to
panic on the part of the less technical user, when filtered incorrectly.
Applications are generally easy to distingish visually from data files.
Files produced under Word, Excel, Superpaint, etc., are easy to visually
distinguish from one another. It isn't necessary to carry around an
extention like a ball and chain in order to identify the type of file,
nor is it necessary to tell the operating system what application should
be run when the file's icon is double-clicked, when that information is
already available. File names -- the names themselves, not descriptions
associated with them -- can be long enough to properly describe a file
and distinguish it from others. No complex process is necessary to
associate an icon with a file: this is done automatically when a file is
created. And, last but not least, the nested arrangement of the folders
which appear under the Finder are an accurate representation of the
heirarchical structure of the volume. Until Microsoft has addressed some
of these concerns, claims that the Windows graphical user interface
increases productivity leave me skeptical.

WINDOWS IN THE BIG WIDE WORLD

Considering that Microsoft Word for DOS is so widely used, and
that many offices would like to see a seamless transition to Word for
Windows, it is virtually criminal that Word for Windows does not support
printer drivers created for Word for DOS. Here at the University of
Michigan, this means it is impossible to use the custom .PRD designed to
format a file correctly for use on the XEROX 9790 printers, used by many
departments to run off exams and book manuscripts. Thousands of users
therefore have to stick with Word for DOS if they want to be able to use
years worth of carefully formatted documents. I certainly can't
recommend that these offices migrate to Windows.

For users in Mac shops, Word for Windows has no translator for the
Macintosh version of Word. This means that in order to convert my Word
for Windows file to Word for the Mac, I have to save it as a Word for
DOS file, then use Apple File Exchange to copy the file from a PC disk,
and use Word for the Mac to convert the Word for DOS file to Word for
the Mac. (Word for the Mac version 4.0B is supposed to read Word for
Windows files, but the translator apparently doesn't work. This was
supposedly corrected in Word for the Mac 4.0C. None of these bug fixes
are publicly announced by Microsoft, although if you are lucky enough to
hear about them and call Microsoft, they will send you an upgrade).
As for converting the bit-mapped illustrations in this file to the
Mac, I don't even know where to begin. Several hours of work will be
lost when I move this file to my Mac. I can use Word for Windows to save
to a Word for DOS or RTF file, and it appears to include the pictures,
but Word for the Mac will not interpret them. Therefore, I can't
recommend that shops that mix Macs and PCs migrate to Word for Windows.
While this kind of compatibility problem, even between products
emanating from the same company, is common in the PC world, it is quite
a mystery to the Macintosh user. Hence, my constant confusion when I
hear DOS managers waxing ecstatic over the Mac-like functionality that
Windows brings to the PC world.

Indeed, with the release of Word for OS/2 and Word for DOS 5.5,
Microsoft will be trying to support five different versions of Word.
Word for the Mac, Word for DOS with the old-style menus, Word for DOS
with a new Windows-like menuing interface, Word for OS/2, and Word for
Windows. All of these products have slightly different user interfaces,
slightly different keyboard equivalents, and support slightly different
file sets. There is no single file format which can be used to smoothly
move Word files between all of them, while still maintaining complete
formatting information and graphics. Microsoft is guaranteeing lifetime
incomes for the respective programming teams that created these
products, but what are they doing to make this situation easier for the
end user? With whom is Microsoft more concerned?

What we find, those of us who work on the front lines and deal
with users, is that with the new, improved operating systems for the PC
such as OS/2, we have high-powered graphical text editors with which we
can edit CONFIG.SYS and AUTOEXEC.BAT (and now, we have our WIN.INI and
SYS.INI files to contend with). Now, we have ever newer ways to make our
systems incompatible with our programs. One of my co-workers, who has
suffered mightily while trying to configure a PS/2 to work smoothly with
both DOS and OS/2, commented that despite the visual appeal of Windows,
she really couldn't imagine giving a PC to a new user, one with no
knowledge of buffers, caches, and file sharing systems, and expect him
or her to be able to set up the machine without becoming confused.
Here is an example of yet another idiosyncracy designed to make
our lives miserable: the File Manager under Windows uses the left mouse
button to drag a file icon from one directory to another. The File
Manager under OS/2 uses the left mouse button, held down, to extend the
selection of files to drag, and the right mouse button to drag file
icons from one directory to another. Why is this? Is the phrase
"consistent user interface" just so much hot air to Microsoft? Is
Microsoft so big that it is easier for teams to implement everything
from scratch than it is to share code?

Pretend for a moment that these user interfaces were newly hatched
out of a software void, and did not have a history of DOS and earlier
versions of the same program. Then pretend that Microsoft was not the
world's largest software company but a small company that you had
contracted with to supply word processors, spreadsheet programs, and
operating systems - the complete suite of software for your whole
computer. Would you tolerate these problems, or would you start looking
for a new company? The only reason Microsoft can get away with this
because they are, for the bulk of PC users, the only game in town.

CLEAR BY NOW?

It should be clear from the above discussion that, although much
more powerful and visually appealing than DOS with its baroque schemes
for addressing expanded or extended memory, Windows still lacks the
essential consistency and user-friendliness that have characterized the
Macintosh. This is the "85% of the Mac" that PC managers would like to
convince you Windows will provide your clients. And while it is true
that it is possible to pick up an inexpensive DOS machine that will run
Windows, a DOS platform that will run Windows well (i.e., quickly and
flexibly) will cost significantly more than a low-cost Macintosh.
What I really don't understand is this: with Windows, Microsoft
really had the opportunity to start from scratch, to create all new
applications, to make an entirely new, consistent, and easy-to-use
interface from scratch. Yet, even from the start, the programming teams
that have devised Windows, and the applications for it, seem hell-bent
on undermining the very things they should be working for. Although the
ability of Windows to break the 640K barrier and achieve multitasking is
commendable -- it brings PC technolgy boldly into the 1980s -- the
applications available from Microsoft, both bundled and separately, are
inconsistent and strangely buggy. Are these applications never tested on
users? Windows probably represents the future de facto standard of PC
computing. Which leads me to ask two questions: why do users put up with
this sort of thing, and why did they put up with the last de facto
standard for so long?

-- 
         -Paul Potts-potts@itl.itd.umich.edu- 
"Wrong is wrong, even if it helps you." - Popeye


================================================================================
|           "Nukem' from orbit.  It's the only way to be sure."                |
================================================================================