Outerfacing is a revolutionary new technology for designing and implementing user interfaces for object-oriented applications. It takes us away from today’s control-centric paradigm (fig. 1) (where the UI is created one control at a time) into a new object-centric paradigm (fig. 2) (where the UI is a direct visualization of and interaction with the objects in the object system).
Figure 1. Control-Centric Paradigm
Using today’s technology, ii is necessary to write large bodies of UI code in order to define the UI for a given object system. With Outerfacing, you can create the entire UI without writing a single line of UI code. With today’s technology, the coding requirements for the UI are directly proportional to the amount and complexity of the UI desired (the fancier the UI, the greater the code requirements). With Outerfacing, there is no relationship between writing UI code and creating the UI. This means that, with Outerfacing, a given object system can have an infinite number and variety of UI’s associated with it, without writing any UI code.
Figure 2. Object-Centric Paradigm
Considering the fact that the code requirements for the UI often exceed those of the underlying object system, this represents a major break through in UI technology. Outerfacing accomplishes this breakthrough by redefining the very assumptions on which UI technology is based.
Since the dawn of the computer age, it has been assumed that the interaction with the user is external to a computer program. This is highlighted by the fact that the interaction between the program and the user is often referred to as “input and output”. Over time, this assumption has resulted in larger and larger bodies of code being devoted to creating the UI and handling the data I/O between the UI code and the underlying functional program.
Given that almost all programs that are written today need the ability to interact with the user at some level, the assumption on which current technology is based has become obsolete. Taking into account the advances made in software technology (especially those related to O-O technology), it is now be possible to create a new UI technology based on a new set of assumptions. They are as follows
1) With O-O technology, the focus of the programming effort is to create an object model of the targeted domain.
2) A properly implemented object model has the same structure and behavior as the targeted domain.
3) A UI can be created by visualizing and interacting with selected portions of the objects at selected times.
4) The structure contained within this model can be used to facilitate the direct visualization of and interaction with the objects that comprise the object model.
Outerfacing is the end result of these assumptions. It directly accesses and utilizes the structure and relationships contained within an object system. Using this knowledge, Outerfacing completely encapsulates the visualization and interaction processes normally associated with the UI and provides these capabilities at the object level. All the messy details of writing code to create the UI and to transfer data between the UI and the object system are eliminated.
Figure 3. Object View Types
Figure 4. Member Control Types
Instead, Outerfacing technology is able to create visual representations of the objects in an object system without the need for UI code. These object visualizations, called Views, can take the form of windows, dialog boxes, bitmaps, buttons or any other supported UI control (fig.3). A view can be populated with UI elements that will appropriately display the visualized object’s member variables and functions (fig. 4 and fig. 5). Figure 6 shows a class definition and several possible views that could be applied to objects of that type. As you can see, a class can be visualized in a variety of ways.
Figure 5. STL Container Visualizations
Figure 6. Transaction Views
With current technology, each of these views would have taken several pages of UI code and hours of labor to create. Not to mention the specialized knowledge of UI programming techniques that is required. With Outerfacing, each of these views required no UI code and took a couple of minutes to interactively design and layout. No specialized knowledge is required.
With Outerfacing, the UI design process shifts from being primarily an exercise in coding to being primarily an exercise in interactive design and layout of object views. Once the appropriate views have been defined, all that is required to create the UI is to select the object(s) to be visualized and ask it to visualize itself. This can be accomplished with a single function call.
Once visualized, the user can interact directly with the visualized object(s). These interactions may result in the manipulation of data within the object, executing one of the object’s member functions or creating visualizations of other portions of the object-system. All synchronization between the object visualization and the object itself is handled automatically.
· If a data member’s value changes, then its visual representation is changed.
· If the user changes the contents of a UI control, then the value of the data member it represents is changed.
· If an object contains a container structure, such as a list or vector, and elements are added or removed from the container, then the visual representation will be changed.
· If an object is simultaneously being visualized in multiple views, then all these view will be synchronized with one another.
All this is accomplished without having to write a single line of UI code!
Using Outerfacing technology within an object oriented computer program is an extremely easy and straightforward process. It requires no specialized knowledge above and beyond that required to write an object-oriented program. Any O-O programmer no matter what their skill level can use Outerfacing to create a UI. Adding Outerfacing to an O-O system is accomplished through a two-stage process: Instrumentation and Visualization.
The first stage is known as Instrumentation and takes place when the object system is being coded. During instrumentation, functionality is added to each class in an object system. Figure 7 outlines the instrumentation process for C++, and figure 8 shows an example. As you can see, instrumenting an object is an extremely simple process that can be completed in a couple of minutes. When instrumenting an object system, it is only necessary to instrument the objects for which visualization is desired. Once all the desired objects in the system have been instrumented, a single function call needs to be added to the object system’s initialization code. This function call initializes a process called the Visualization Engine, passing it the initial object to be visualized and the view to use. In many cases, this is all the programming that is required to visualize and interact with an object system.
Figure 7. Instrumentation Overview
Figure 8. Instrumentation Sample
The second stage of the Outerfacing process is called Visualization. During this stage, the Visualization Engine interacts with the instrumented objects to create object visualizations. It is also during this stage that new object views can be defined. This is accomplished by using a specialized editing program called the View Editor (fig 9). This editor resembles a desktop drawing program and allows the user to interactively define how a view looks and behaves.
Figure 9. View Editor
Since the task of defining a view doesn't involve programming, a non-technical person more suited to the task, such as a graphic designer or human factors engineer, can perform it. This allows the programmer to devote more time to adding functionality to the program.
Because new views can be defined without changing or adding code, any object or group of objects in the O-O system can have an infinite variety of visual representations. The exact visual representation displayed can be dynamically selected while the program is running. This allows a given object system to be appropriately visualized and interacted with in any context.