WHAT IF...

Dick Pountain/29 May 1998/Idealog 46

"What if..." is probably the most powerful word pair in the English language. Or in any other language for that matter, as one can imagine someone back in the Stone Age grunting the equivalent of "What if I bang these two flints together...". Setting the world to rights is most people's favourite pastime: sitting down the pub, wondering aloud What If Gareth Southgate had consumed a more potent breakfast cereal on the morning of that World Cup final; or What If Adolf Hitler's mum had had a headache that night.

I'm fond of this game myself, most often to do with matters of history, but until recently I'd never tried applying it to the Windows user interface. You may recall that in recent columns I've been whinging about the lack of proper object orientation in Windows - that is, of the ability to alter all the properties of individual screen objects - and the gross overcomplication of OLE as a means of automating and linking applications. Lying in bed one night recently, it occurred to me that I was approaching the problem the wrong way. Thinking in terms of underlying architectures like OLE, COM and ActiveX comes naturally to me, it's what I do for a living, but it prevented me from seeing how things could be different. Instead I thought, why not just sit in front of the PC and wonder "What If Windows actually worked like this". I tried it and the scales fell from my eyes...

Let's illustrate with a concrete example of something I want to do, but can't. When I want to send an email from Ameol I bring up its Mail Message dialog, and if I click on the "To:" button next to its first input box, Ameol will pop up its own internal address book for me to choose from. The trouble is, what I'd really prefer to do at this point is to access my own address book, which is kept in a separate application, Idealist. I'd like to be able to tell Ameol that's what I want.

The conclusion I've arrived at is that Microsoft started to go wrong in the design of Windows when it neglected, and then dropped, the Recorder application that you used to create keystroke macros. What Microsoft should have done was to make that Recorder deeper and more powerful, and make it into the primary interface into OLE Automation - Visual Basic should have been the language of that macro Recorder. The way I imagine it, when faced with that Ameol message dialog I would just switch into Record Mode and then indicate that I want to look up my email addresses in Idealist instead by launching that application. My preference would be recorded and stored, not in a file of macros but actually inside the To: button of Ameol's dialog - every button would have to become capable of containing a stored VB script.

But of course I wouldn't want to have to actually write any VB code myself so let's keep the fantasy rolling. What If every Window were to expose a wisely chosen exerpt from the OLE interface of the application that's running in it, perhaps described by aliases that are rather simpler than their full method names (so no MsoOLEMenuGroup.msoOLEMenuGroupContainer then). When you clicked on the control menu box at the left end of the Title bar of any window, you  would see several additional items like "Input: TextStream", "Output: Doc" and "Output: Selection". And then What If you could just draw a 'pipe' from the Input of one Window's control menu to the Output of another Window, to transfer the appropriate data type between the applications. In my example I would pull down Idealist's control menu and see items on it like "Input: Query", and "Output: Record(Name,Phone,Address,Email)". I'd draw a line on the screen connecting the "Email" field of Idealist's Output record to Ameol's "To:" box, and the mere act of drawing that line would generate the required VB code and store it into Ameol's To: button, so that from then on Ameol would work the way I want it to.

Would the automatic generation of VB code from screen actions be difficult? I don't think so - after all there are already macro recorders built into Word and Excel already which do it. The fundamental architectural flaw in Windows is that those macro recording functions are local to Word and Excel, rather than being a global property of Windows itself.

But who am I to make radical suggestions like this - about fundamental issues of user interface design - when I don't even work for Microsoft? Well I'm one of the ultimate experts in user interface design, that is to say, a user. We are the ones that never get consulted about the basics of the UI at design stage: only recently have the big software firms started sampling users after the event, via their useability laboratories, but by then the most fundamental decisions have been made. Visual Basic once looked like it might revolutionise computing; dragging and dropping pre-existing components like Lego bricks to make them do new jobs. The problem, as always with MS software is that VB's roots don't penetrate deep enough - it's just another layer plastered on top of Windows. I'm not suggesting that it would be easy at this stage for Microsoft to implement a scheme like this, as it would require very fundamental changes to be made to the basic object model of Windows. But in order to end on a positive note, I would be very happy to accept a highly paid sinecure at Microsoft's Cambridge campus to help them sort it all out. All offers care of PC Pro please.


[Footnote: RIP Byte Magazine 1975-98]