We often get questions about why there are no OK & Cancel buttons on Protégé forms. This page is an attempt to give the reasons why the forms do not have these buttons.

There are a number of problems with trying to put OK/Cancel buttons on Protégé dialogs. Some problems result from the decision to have the dialogs be "modeless" (where you can go elsewhere in the application and work and then come back) rather than "modal" (where you must respond to the dialog and answer OK or Cancel before you can do anything else). Users have made it clear that it is very important that dialogs be modeless because the users often refer to one instance when filling out another one. Using OK/Cancel on modeless dialogs is almost never done in any application because the meaning of the buttons is unclear. I'll try to explain why below. Another set of problems results from having widgets that are substantially more sophisticated than those typically encountered on "data-entry" forms.

(1) In general dialogs can bring up other dialogs. For example, creating a instance on a form brings up a dialog which may then allow you to create another instances. Modal dialogs that bring up other modal dialogs result in a chain of dialogs that must be closed in reverse order. Thus if you have a chain of 4 dialogs which you close with OK, OK, OK, and then Cancel on the bottom dialog the effect is (or should be according to the common UI guidelines) to cancel all of the previous dialog changes. No change can be "committed" until "OK" is pressed on the bottom dialog. This is the behavior that people have come to expect.

One problem is that for modeless dialogs there is no real "chain" because the dialogs can be closed in any order and the same dialog can be reached via several paths. The only reasonable OK/Cancel strategy is then to commit the changes on a given form when OK is pressed. You can't wait for the bottom form OK to commit because there effectively is no bottom form. Since dialogs appear to be "stacked" on the screen the user may expect the modal dialog behavior of no commit until the bottom dialog is "OK"ed. This will be confusing.

(2) We have several sophisticated widgets that allow you to edit multiple instances on a single form (the contains widget, the table widget, and the graph widget, to name a few). The behavior of these widgets would be quite difficult to understand if changes were committed only on OK. (It would also be extremely difficult to implement these widgets). Since changes to the contents of one of these widgets actually changes instances other than the one being displayed on the form we must address the issue of when these changes to other instances will be committed. Obviously committing the changes immediately when they are made gives a bizarrely inconsistent feel to the user interface. For example, creating an arc in the graph widget causes the creation of an instance in the knowledge base which will not go away if the form that graph is on is canceled. Committing the changes on an OK seems reasonable but it forces the widgets to cache an arbitrarily large amount of information about the other instances which it references. When these instances are displayed by other means, such as by looking at them in their own form (double-clicking on a node in a graph, for example), the information cached by these widgets will not be displayed. This is going to give rise to quite a bit of confusion.

Even simple widgets like the standard "InstanceListWidget" for displaying several instances in a list box shows this problem in a simpler form. If you are on a form with such a widget and press the "create instance" button, go configure the created instance, create other instances from there, edit other places in the knowledge base, and then hit "Cancel" on the first form two hours later, none of the changes should be committed.