Why I like MS Windows

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 78

Why I Like Windows¶

by Richard Smith (age 7)

The Mouse¶

The mouse is easier to handle than the keyboard, that is, except when dog-hairs get on the ball and the mouse sticks. The only thing about it is, I would like a bigger space to move it in! The mouse’s buttons are also nice - they’re a good size.

The Icons¶

Icons are not only easy to design (if you’ve got an hDC Icon Designer), but they are also easy to ‘do’, because all you have to do is click the hDC icon (a red box with hDC written in it) and select Icon Designer from the menu. When Icon Designer has loaded, a rectangular window will appear. This window will have a: a squared square for ‘doing’ your icons and b: a space which shows all your finished icons. Talking about putting windows down to ‘icons’ is explained in the Windows section. Icons are the little ‘pictures’ in the windows at the start-up.

Comparing with the Keyboard¶

For most things it is either easier or the only possible way to use the mouse. But for some things it is impossible to use the mouse, things like APL or RCS are ‘keyboard only’ functions, and these functions are accessible from Microsoft Windows, or, at least, can be made to be. To pull a menu down, press Alt with the underlined letter in the menu word, then to select an option, press the underlined letter, and you’ve got your option!

The Windows¶

The windows can be worked by the keyboard, for example: in games Alt G gives you the games menu, but this isn’t as easy as doing it with the mouse. When you put a window down to an icon, an icon, usually its own, goes down under Program Manager, with its name label underneath it. By getting hold of window ‘title bars’(the blue/brown stripe at the top of the windows - blue if you are currently using that window, brown otherwise) with the mouse, you can move windows. After moving a window, it will have a blue title bar, until you either click or move a different window.

Window Menus¶

The menus at the top of windows like Write can be used easily, even with the keyboard (as explained in Comparing with the Keyboard). All you have to do with the mouse, though, is click the menu you want and then click the option you want.

Iconising Uses¶

If you are working with anything running under Microsoft Windows and somebody comes and pesters because he/she wants to do something else, you can put whatever you’re using down to an icon (as explained in The Windows). After doing this he/she can get on with whatever they want to, but you haven’t lost your work. After he/she has finished on the computer, you can get on with your work. Putting the start-up windows down to icons saves space.

Window Buttons¶

The buttons at the top of every window can only be ‘pressed’ with the mouse, and I think that there ought to be a way of making use of those buttons with the keyboard. Other than that, the windows are well designed, because they are easy to use with a mouse, as all you have to do is click the left mouse button on the window button you want.

Why I Like Microsoft Windows?¶

by Adrian Smith (Age 38)

A User’s View¶

A couple of old advertising slogans come immediately to mind: “every home should have one” and “so simple even the cat could use it”. I have no idea what the former was trying to sell me; I believe the latter had something to do with John Cleese and Sony video recorders … anyway …. as Richard rightly points out, Windows software is easier to use than the old text-based stuff. The interesting question is why?

Obviously, for anything involving pointing or drawing, the mouse is an enormous improvement over the keyboard. However in itself this doesn’t explain why Windows software like Powerpoint is an order of magnitude easier to work with than (say) Lotus Freelance. The same difficulty occurs in explaining why Windows Write can be picked up by a 7-year old with absolutely zero instruction, and yet an old warhorse like WordPerfect takes a 3-day course, and you still don’t know how to get a PostScript print to file!

For what it’s worth, I think there are two key reasons why Windows software is a real step forward in both functionality and ease of use:

the underlying philosophy. You hear a lot of loose talk these days about empowering the user. I say loose talk advisedly, because of course empowered users are exactly what your average IT department hates. Windows is aimed squarely at individuals; it is another step in freeing users from the strictures imposed by corporate IT, and as such it is both a powerful and a dangerous idea.
absolute consistency of use. We have IBM and their CUA guidelines to thank for this one! A lot of developers seem to think that they can claim CUA compatibility simply by strapping on a pull-down menu bar, and using the ‘right’ colour scheme; this is rubbish. Real CUA applications rigorously apply the ‘object-action’ model to dialogues (the converse is neatly illustrated by Lotus-123, where you always pick an action before you select the patch of the spreadsheet to do it to); real CUA applications have a set of menus going ‘File … Edit … View … Options …. Help’, with the Print command under the File menu; real CUA applications already know what printers you have available, and where the output is to go; real CUA applications use your personal choice of colours … and so on.

The main reason why Powerpoint is easier than Freelance is because you can learn it incrementally from Paintbrush; it has a ‘line tool’ and a ‘text tool’ which operate just like the ones you played with before. It also has a ‘text edit’ tool which behaves just like Windows Write, except that it works in a stretchable frame within your artwork. Strangely enough, the spell-checker in Powerpoint is just like the spell-checker in Word, and you can even get them to share dictionaries! If you want to move things around, then you just learned all the necessary skills playing Solitaire and Backgammon, … and so on.

In summary, as a user I like Windows because I am all for giving individuals the freedom to exploit their environment in any way they choose. In the long term, I believe that companies which encourage employees to do this will prosper better than companies which try to control their employees’ every move. By providing an environment where all software looks and operates in the same way, Windows and CUA make it far more practical for users to choose the best package for the job, safe in the knowledge that they won’t be faced with a whole new set of commands and menus.

Oh by the way … you can do things like multitasking and cut-and-paste and background printing. So what! Fast task-switching is all I really use, and I could have had that with Software Carousel for £50 under DOS on my old XT! Windows does the job very prettily (as long as you have an extra £25 to spend on an Icon designer), but I cannot see something selling 3 million copies simply by offering a nice ‘point-and-grunt’ DOS menu and an efficient task switcher, can you?

A Programmer’s View¶

Cast your mind back to the heyday of motoring, maybe around 1908 when you could have a really fabulous day out in your new machine; OK it frightened the horses, and you soon got used to the joys of retrieving the contents of a ball-race from half a mile of loose gravel … but this was real motorist stuff … no quiche eaters here! But the skills needed to operate the old horse and trap were simple and well-known, and it could beat the fancy new machinery to town and back any day of the week; why on earth should anyone want to change?

I reckon I can operate the old horse and trap technology pretty well … it took me about an hour to write a little C routine to send a bunch of files to a PostScript printer, suitably wrapped up in font selection and pagination. I know how to read and write files, and if I want to display some output, I simply use a file called ‘stdout’ and everything duly appears on the screen. Similarly in APL; we have always had the simple convention that if you leave the result of a statement hanging in mid-air, APL outputs it to the standard output device (usually a screen) after applying some default formatting rules.

Can we continue for ever with the simple life? The motor car opened up vastly wider horizons, and made possible journeys that could never be contemplated in horse-drawn days; once tempted by the promise of a better tomorrow, you will find it hard to stay with the old ways!

Life begins to get a harder once you let your application have full control of the screen. You might need to direct output to specific fields (in GDDM mainframe terms):

'A' FSM∆PUT 6 2⍕DATA
'B' FSM∆PUT DESCR

… and you need to be a bit fussier about getting the shape and type of the data right. On the PC you probably just bung things in windows, and assume that the windows utility will handle details like nice borders, scrolling, and so on:

2 3 WIN∆PUT ⎕NL 3   ⍝ Display function names in scrolling wdw

What you tend to forget is that some muggins has put in an inordinate amount of time and effort in making things this easy! WIN∆PUT is about 40 lines of very solid APL (in APL*PLUS/PC with ⎕WPUT, about 25 lines in Dyalog with ⎕SM) which took a good deal of designing and debugging. On the mainframe, I wouldn’t know a 126 ⎕SVO 'CTLS' if it jumped out and bit me, and yet I once wrote all that low-level stuff to manage the screen through GDDM calls.

My first reaction on opening the manual for the Windows Software Development Kit (the SDK for short) was that it was just like opening the GDDM Application Programmers Guide for the first time. It is written in English, so you feel you ought to be able to understand it, and yet there are so many unfamiliar concepts, and a lot of the words have new, precisely defined, meanings. In short, there is a big learning curve to go up before you can even think about things which were previously almost trivial! Take the obvious example … here is the “hello, world” program in C and in APL:

main()
{ printf("hello, world\n"); }   /* K&R page 6 */

     'hello, world'     ⍝ APL wins even here!

Compare this with Peter Donnelly’s sample to get ‘Press Here’ on the simplest X-widget: a button. Just what happens to you when you ‘realise your widget tree’ (see page 116)? Why might you want your application to activateCallback? Do you really need all that portmanteau of code just to display a simple message? How on earth can ordinary mortals hope to generate useful systems ever again??

Of course the answer is the same as the resolution to the horseless-carriage dilemma (it was predicted that by 1925 half the world’s population would be chauffeurs); we don’t all need to become expert mechanics to drive a modern car. Most of us don’t even know how a modern car works (could you fix the electronic ignition on your 16v fuel-injected Japanese toy?); we just turn on the engine and drive away. It took around 20 years for the car to evolve from a complex engineering marvel to a commodity (Henry Ford had a lot to do with it); the interesting question is how long it will take for windows to get to the same state.

The Next Two Years¶

Over the next two years, we really are going to see the shape of things to come. The APL developers are already taking the first tentative steps towards integration of MS Windows and X/Motif into the APL development environment (of course MicroAPL and I-APL have already done it for the Mac). I appreciate Peter’s argument that 18 lines of APL is better than 72 lines of C, but I want to write 1 line of APL:

ACTION←XYPOS X∆BUTTON 'Press Here'

… what’s more I don’t want a couple of hundred things with names like disarmCallback listed whenever I do )FNS. For cheap and cheerful output, I want to use the APL default display, and have the user think I just wrote something really fancy in X. If the user grabs my window and pulls it all out of shape, I don’t want my code scattered with ⎕TRAPs just so I can recover. All that stuff should be buried in utilities where the application need never see it.

I think we need two things to happen:

The APL interpreter writers must provide the basic hooks into the underlying window manager in a tolerably clean way. I have a personal preference for auxiliary processors, but if STSC chose to implement another 100 ⎕functions I shouldn’t really mind.
A bunch of APL systems programmers (people who don’t mind coding at the AP level, or who can handle ⎕WIN without flinching) should get together and define a common application-level interface for APL under windows. This should be common across all the different window managers (the Mac, MS Windows, X/Motif etc.) and it should also be common across all the available APLs (APL.68000, APL2/6000, Dyalog APL, APL*PLUS, I-APL etc.).

The first of these is already well underway, and is clearly going to generate the usual variety of different approaches to the same task. The hard part is to motivate someone to begin work on the second; clearly it is in no vendor’s direct interest to write vendor-independent code, and yet in the long term all the vendors will sink or swim together. Just as the car makers reached a rapid consensus on the ‘proper’ positions for the accelerator and brake, so should the APL vendors on the ‘proper’ way to program a push-button. STSC and Sharp did it for component files, so it should be possible for Dyadic, MicroAPL and the rest to do it for windows! The CUA Advanced Interface Guide would be a good place to start.