Shell Integration

[Amit’s note: Although this is about OS/2, I think some of these ideas may be useful in Win95’s shell as well.]

From: Jim Little
Subject: Elements of WPS integration (Was: WPS and DeScribe.)
Date: 30 Apr 1996 01:22:36 -0700

DeScribe, Inc. wrote:
From time to time there have been comments about areas where DeScribe’s integration with the Work Place Shell could be improved. Would users please email or post specifics.

What follows is some of my thoughts on the matter of WPS integration. I hope others will contribute their ideas for WPS integration as well. I’ve cross-posted to comp.os.os2.programmer.misc and comp.os.os2.programmer .oop. Followups are directed to comp.os.os2.programmer.oop and comp.os.os2.apps only. I see this as a thread for discussing general WPS integration features, not just Describe-specific comments. Please contribute!

There are several ways an application can be integrated with the WPS. I’ve grouped these ways into three categories: Basic, Advanced, and Total. In my opinion, a commercial OS/2 application must support all the Basic WPS integration options. High quality OS/2 applications support the Advanced integration options. Total integration is usually not necessary or desirable for your average productivity application, but when it works, it’s very impressive.

Basic WPS integration features:

I think every serious OS/2 application should support at least the WPS integration features in this section.

WPS objects

Every OS/2 application that supports creating documents of some kind or another should display those documents as objects on the desktop. For productivity applications, this is as simple as saving each document as an individual file. For programs that save several documents in one file (for example, a game that stored all savegames in one large file), create a new WPS class by subclassing WPAbstract and create an individual object for each document. (Note that I’m using the term “document” very loosely.)

“Open” support

Every WPS object should display a default view of itself when opened. For most applications, this is as simple as setting up a program association. (File extensions should be optional.) If data files aren’t being used (for example, the WPAbstract savegames described above), make sure the custom objects open the application AND load the appropriate document.

“Print” support

Any object that represents a document that can be printed should print that document when the object is dragged to the printer. Ditto for selecting “Print...” from the pop-up menu. Objects that represent documents that CAN’T be printed (for example, those savegames) should have the “unprintable” style set.

Templates

Any application that has objects should support creating new objects via templates. This can be as simple as creating an empty data file and turning on the “template” flag when you install, or as complex as having a application-specific object class that creates a template for itself via the wpclsCreateDefaultTemplates method. If an application has multiple “new” documents, like Describe, it should either create multiple templates at install time or (preferably) have a dialog box pop up showing the different document styles when the user tears off a new document. The second option would require an application-specific class that overrides wpCreateFromTemplate or wpCopiedFromTemplate.

Advanced WPS integration ideas:

The WPS integration suggestions in this section are “above and beyond,” and would make an application stand out above the crowd.

Uninstall

An application can define its own Program object class. This leads to the ability to have an application ask if you want to de-install it if you delete the program object. Also, you could remove the “Delete...” option from the pop-up menu and add a “Uninstall...” menu item.

Drag-n-drop

An application could accept objects dragged from the desktop and automatically create links or copies of the contents of the dragged object. It could also have an icon that could be dragged to the desktop to save the document. I believe IBM Works supports both of these options.

Live link

If the object for the currently open document were moved or renamed, the application would automatically save the document under its new name. If the object were deleted (by dragging to the shredder or by selecting “Delete...” from the object pop-up), the normal confirmation dialogs would be displayed, and then the application would automatically close if the user confirmed the delete.

Settings notebook

The application could have a custom WPS class for its document objects. This object would have a customized settings notebook that reflected the application. For example, if the application supported documents with multiple revisions, it could add a “Revisions” page to the settings notebook. Even if the application didn’t define its own WPS class, it could still support the standard “Subject,” “Comment,” “Key words,” etc. fields.

Object views

Objects could also modify the “Open” menu to support multiple views. For example, the multiple revisions mentioned above could each have their own menu item on the “Open” menu. Or a word processor like Describe could have “Draft view” or “WYSIWYG view” options.

Details

It’s possible to define additional information about an object that will be displayed in the details view of a folder. An object could contain information such as the topic, author, or something similar.

Full integration:

Some applications can be completely integrated with the WPS. This isn’t appropriate for all applications, but for those applications that are well suited to it, full WPS integration is very powerful and very impressive. Applications that are fully integrated into the WPS definitely set themselves apart from the crowd.

Full WPS integration is just that: All aspects of the user interface are part of the WPS. For example, the FTP support that will be included in the next version of OS/2 will be fully integrated into the WPS. FTP Sites will be represented as folders in your Drives object. When you open an FTP site folder, it will open just like a regular folder and display the remote files as objects. Downloading should be as simple as dragging and dropping.

Since there are so many different kinds of applications, it’s not really possible to give a list of capabilities that the application should support. Just think about what your application would be like if it were a standard part of the desktop, and split it into user interface objects. For example, if you were creating a database application, you could make each database a folder object, with each table, query, report, etc., as an object within that folder. You could add a “SQL View” to the queries and a “Relation- ships view” to the database. And so forth. The key to designing a fully- integrated WPS app is to forget about your application as an “application,” and to think about it as all the different pieces a user interacts with. Then take those pieces and fit them to the WPS paradigm.

That’s my thoughts on WPS integration. I’d like to hear what other people think. The WPS is really OS/2’s most innovative feature, and I wish more programs would exploit it.