Exploring Cairo: Forms Database Engine

Forms Database Engine

If you think about it for a minute, user interface design hasn't really moved forward in a long time. Sure, it changed from the DOS environment to Windows 3.x. And now it's moving from the Windows 3.x design to the Windows 95 design. But there's still something missing. There's very little you can do to make the user interface right for you. You can change colors and the look-and-feel of your interface--that's true--and you can load up a button-bar task launcher, but that's about it. And when you consider the power available in the macro languages of, for example, the Microsoft Office applications, this is a strange limitation.

I know that the Microsoft developers will say that their product has been through extensive usability testing. I've been to the usability testing labs in Redmond, and they are impressive, but Microsoft cannot hope to achieve anything more than what appears to work best for most of its users. And, as the old adage goes, "If the rest of the world is normal, then I don't want to be ..." In other words, if you want to make wholesale changes in the user interface, you're going to come up against a brick wall very quickly.

Shrink-Wrapped Users
If you take a long hard look at a development tool based on components--Visual Basic is an excellent example--you realize that you can't go any further than the application you are actually building. Nothing allows you to go out into the operating-system world to make global changes.

Why not? After all, it's your working environment, your space. It should be the way you want it to be, not the way some committee thought it should be. The reason "why not" is simple: The Windows 95 shell is a fixed-function application. It wasn't designed to be user-customizable. It's what comes in the shrink-wrap. If you don't like it, that's too bad!

This approach has considerable merit when you think about the memory and size constraints put on a product such as Windows 95--anything that would bloat the product unnecessarily wouldn't make it into the final version. But Windows NT is different. NT is a melting pot of technology where size and performance rightfully take second place to capability. I'm not suggesting that size and performance don't matter--of course they do--but NT is a platform led by capability, not size or speed.

It has long been rumored that the Cairo project has a user-rebuildable user interface. Indeed, such a capability was shown at the December, 1993, Chicago (Windows 95) Developers' Conference held in Anaheim, California. Microsoft showed that it was possible to take standard user interface components, such as a FileOpen dialog box, and extend and modify them and load active objects onto the Windows 95 Taskbar.

How could this work? Is this capability really deliverable to the desktop? And once it's delivered, will it really work across all applications?

Modular Object Interfaces
A number of key pieces are required to make such a user-redefinable interface work. First, you need objects that encapsulate specific pieces of object functionality. They shouldn't be too small in capability, nor should they be heavyweight, multifunctional monsters. A push-button object would be an ideal size. A file-directory listing box would be an ideal size and scope for an object, despite being larger and more complex than a simple push-button object. A full-blown FileOpen dialog could be too large if you wanted to significantly change things within the context of the dialog itself.

You would need a design framework in which to lay out and design these composite forms or dialogs--some way of placing the objects with a Form Painter and then setting the properties of each object, as appropriate.

At this point, the words Visual Basic 4.0 (VB4) should be flashing through your mind. VB4 has a Form Painter system and has lightweight objects available in the form of Object Control Boxes. (An OCX is an Object Linking and Embedding (OLE) object wrapped as a usable control.) VB4 ships with OCXs that encapsulate the functionality of push buttons, shapes, lines, list boxes, scroll bars, frames, and so on. In addition, VB4 has a good Form Painter tool.

In Screen 1, the upper dialog box is the standard hard-wired FileOpen dialog box from Notepad. The lower one is a form created using OCX OLE controls; it exposes standard OLE Automation routines. I created this form in VB4 in about 10 minutes from start to finish, and it works very nicely, thank you. It has one major advantage over the standard dialog box: I can rearrange it to my heart's content.

Screen 2 shows the result of less than 60 seconds of tinkering. You can rearrange it to suit your particular style or needs or to add completely new controls to it. Imagine extending the Taskbar to allow custom controls, status areas, and so on, without having to delve into the Win32 API. Just get a handle to the Taskbar object, and add a new control to it (see Screen 3).

Finally, you need somewhere to store your custom form design. VB4 can output an executable application, but that's probably not flexible enough. After all, a stand-alone executable needs to be loaded and executed, and that takes time. Wouldn't it be better to have a form runtime program that takes form definitions and brings the relevant form up on the screen--especially if it were actually the desktop shell program?

Indeed, stretching the concept a bit further, if you could store form definitions that used OCX objects in collections, then the whole user-interface shell could be built at runtime. In other words, your desktop could be custom-built for you when you sit in front of it for the first time. The Taskbar would be a container object which belonged to the Desktop object. The Taskbar object could contain other objects: buttons indicating running applications, OCXs providing live data feeds, status objects, and so on.

This concept becomes especially important when you remember that Windows NT allows you to log on anywhere and get your own desktop. All you would need to do would be to store the interface definitions in a pan-user (i.e., the same for all users) Registry, which would be preferable in a global name space. Thus, changes made by an Information Systems supervisor would be automatically distributed to all users. Your user interface could be a collection of unchangeable, standard, corporate designs coupled with your own changes and modifications.

Viewed in that light, the compiled .EXE format of VB4 might not be the best. You would need a unified store where all the form definitions could be stored. The Cairo name space seems like an ideal location.

If the form renderer were OLE Automation-capable, you could use standard OLE Automation from any application or tool to bring up the required type of form. The syntax could be very simple. For example, look at the following pseudo-VB4 code:

Sub ShowFileOpenDialog()Dim MyDialog as object,   FormsEngine as objectSet FormsEngine =   CreateObject("Shell.Forms")FormsEngine.FormType =  "ShellFileOpen"FormsEngine.ShowEnd sub

The code is standard OLE Automation code (I just made it up off the top of my head). But since the Shell.Forms object server runs on your desktop, you just create an object instance of that type with the CreateObject call. You then tell your object to be a form of type "ShellFileOpen" or some such name.

The form server loads the definition of the standard FileOpen dialog box, and the final .Show call displays it. If you want to change any of the dialog box's standard properties, you can do that before displaying the form. Indeed, given the fact that Visual Basic for Applications (VBA) in VB4 supports collections of objects, you could probably even use the .Add call to add a new control to the form design, setting the form's properties before the final .Show call.

The form server could cache all my form definitions locally in the Registry under HKEY_CURRENT_USER and could call a centralized forms server to check for new revisions and designs. It's simple, neat, and efficient, and anyone looking at creating OLE Automation servers using VB4 will see the potential benefits and understand the ease of creation and use.

The Application Quandary
There is, however, a fly in the Cairo "roll your own interface" ointment. It's called Office! If you want strong user-definable user-interface components, then Office is the most likely place to look.

To be frank, I find Office 95 to be somewhat disappointing. Once you go beyond the tinsel and hype, there really isn't much there that wasn't in the previous Office 4.2/Windows NT product. Admittedly, Access and PowerPoint are now 32-bit applications, but the mainstays of Office--Excel and Word--haven't received a great deal of attention, apart from some performance improvements and usability features.

What difference does it make? One of the core requirements of an office-automation system is a fluid and customizable interface. Look at how each application handles custom dialogs, the mainstay of a properly designed office-automation solution.

Word 7 has a bizarre dialog editor which spits out largely meaningless code that you then place in a WordBasic macro. If you want the dialog to be active, as in a Wizard, so that different pieces appear and disappear depending on what the user does, then the dialog-definition code becomes tortuous in the extreme.

Excel 7 doesn't use this system at all. It used to--for its XL4-style dialogs--but now there's a new sheet type called Dialog. On this pseudo-sheet, you paint the dialog using components from a Toolbar. My initial excitement waned when I realized that you can't load an OCX control, so this feature's real-world usefulness is somewhat limited. Worse still, you can't bring up an Excel dialog object on the screen without loading the whole of Excel first, if it's not running. That's a rather large hammer to crack such a small nut.

Does Access 7 show us how? No! It has form designs which are stored in the Access .MDB file. It does support OCX objects, however. Is VB4 the solution? Well, its Form Designer supports OCXs, but it's as different from all the other Form Painters in terms of operation, building, and storage as they are from each other.

This is madness! Excel should be a worksheet/calculation engine and a graphing engine; Word should be a page-formatting engine; and so on. It makes no sense for each of these tools to have its own custom and completely incompatible forms engine.

If such an object deconstruction were to happen, what would it mean for the applications? Well, there's really no reason why Word couldn't be designed to use the common Forms Registry for all its user-interface components. And the same could apply to Excel. How would it work? Think of how you execute an Excel worksheet inside a Word document: The Word frame negotiates with the Excel interface engine to bring the right components onto the screen.

If each application used a common forms engine not only for its own internal use but also for custom dialogs, it would allow dialog designs to be pan-application and pan-solution. You would no longer need to create a set of dialogs in Excel, then recode them in WordBasic, and then code them again in Access and yet again in a VB4-hosted component. Solutions that leverage multiple object sources--core applications--could have a single update point on the network and still allow some components to be stored on the local hard disks for optimum performance.

Cloudspace Cairo
Will a common forms engine happen? I'm firmly convinced that it will. It has to if we are to release ourselves from the straitjacket of the precooked user interface. There are so many advantages for users if the common engine can be made to work that the first mainstream operating system to implement it will overwhelm the competition. Perhaps it could be implemented as an optional shell replacement package for Windows NT, a Shell Plus or some such thing.

Whether it will come with Cairo, be packaged as a systems-management tool, or accompany a future version of Office is unclear. Personally, I think the Office group will seize on it as a way of escaping from their current macro/dialog mess. But whoever implements it, have no doubt that the advanced OCX and OLE Form Painter work will almost certainly have come from that cloudspace of ideas called Cairo.

Maybe I'll finally be able to have my desktop the way I want it, not the way someone else thinks it should be.