A "look-and-feel interface" software module will be located between the Command Line Interface and the user. Providing optional modules for selected look-and-feel interface characteristics will serve an important practical as well as evolutionary need. When working interactively, no matter what particular look-and-feel style is being used, a user has a particular mental model in mind for the significance of every menu item, icon, typed command, or "hot, command-key combination" employed.

The users will automatically learn about their tools and materials, intuitively coming to understand underlying common-vocabulary terms no matter what form of user interface they employ, and may move from more graphically pretty interface modules which spell out potential options at every juncture, to simpler and more flexible interfaces which rely more on the knowledge of the system.

Besides relaxing the troublesome need to make people conform to a standard look and feel, this approach has a very positive potential outcome. So far, the evolution of popular graphical user interfaces has been heavily affected by the "easy to use" dictum. This has served well to facilitate wide acceptance, but it is quite unlikely that the road to truly high performance can effectively be traveled by people who are stuck with vehicular controls designed to be easy to use by a past generation based on simple click-on-the icon over simplicity.

As important classes of users develop larger and larger workshop vocabularies, and exercise greater process skill in employing them, they will undoubtedly begin to benefit from significant changes in look and feel. The above approach will provide open opportunity for that important aspect of our evolution toward truly high performance. The bottom line is OHS is easy to get into and easy to evolve in.
           EXAMPLE: Icon based GUI system, extensive hierarchal menu systems and high performance command line interface where the user can exert as much control as he or she can remember the commands for, commands which can be learnt while using the easier but less flexible interfaces.

The OHS Interface Architecture will be set up explicitly to provide for multiple UIS options, with a common, full-feature Application Program Interface (API). To support extensive capability evolution, it will be necesary to provide for a range of UIS options, varying in complexity, potential competency level, difficulty to learn, types of interface devices and modalities, etc. Being able effectively to support web-connected mobile phones is one example.

But a VERY IMPORTANT purpose here is to enable individuals, or special-role support teams, to experiment with interface equipment, functionality, and control options, together with optional special attributes of the standard Intermediary File, to pursue especially high performance at important parts of their knowledge processes.

Having this kind of exploration in any event will be necessary. Doing it with special extensions to the widely used OHS will be very important in enabling feasible migration of these tools and skills out into the rest of the communities. Moreover, doing this exploratory high-performance activity over the SAME WORKING domains amplifies that benefit immensely; motivated individuals can optionally acquire special interface equipment, take some special training, and move up to a "new class of user proficiency" (e.g. becoming a certified Class-4B Knowledge Integrator).