InterUnit-UI is a temporal UI-design paradigm that asks the question:
"What does the user want to use the UI, for right now?" --
an "interface-unit" services that intent.
It is a simpler alternative to WIMP which is based on the spatial concept of windows
and associated icons, menus and pointers. WIMP asks the question:
"What interactive screen-widgets does the developer need to build an app-UI?".
- Past work
We have been developing the SDK for InterUnit-UI over the past few years. It is based on wxWidgets, an open-source, cross platform library for app development in C++. The codebase is about 10000 lines of code. - Current status
We are currently developing a CAD app (The Specifier) using the existing codebase. We are adding user interface design features such as a hex-grid based drawing engine. - Plans
After validating the API with CAD tool, we plan to:- Continue work on a developer tool (Ergonomix) for developing apps using the API.
- Produce an implementation of InterUnit-UI on an iPhone based laptop platform, and get The Specifier running on it.
It's a much simpler for a developer --
it only defines 2 constructs, the InterUnit and the EngagementManager.
It's much simpler to use -- it does not require the use of menus, icons, and windows.
The need for mouse usage for fine-grained screen-space selection is removed.
The need to switch between mouse and keyboard used can be reduced by design.
It's much easier to onboard a new user to UI usage,
instead of a documented menu, toolbars with tooltips, and a help system.
Since InterUnit-UI is a temporal UI, it is possible to control ergonomic-efficiency which relates to the actions the user needs to perform to control an InterUnit. The WIMP UI provides a library of UI widgets that are used by apps in UI design. The ergonomics of each of these widgets is fixed -- the widget-designer designs a widget to service a particular use case in the most efficient manner.
An app-developer can only choose which widgets to use in their app-design to control ergonimic-efficieny, but they cant change the erognomics of the widgets they use.
In InterUnit-UI UI-design,
an InterUnit's source-code is self-contained
and can be modified independent of other InterUnits and the EngagementManager component that will host it.
An initial design can be produced and it can be refined over time to improve ergonomic-efficiency.
An InterUnit can be re-used. This re-use is at a user-function level, since each InterUnit is associated with a unique user-function. In WIMP, reuse occurs at the interactive-screen-widget level, which is a UI-function, not a user-function. A WIMP app developed by a developer can't really be re-used by another developer. An InterUnit developed by a developer can be re-used by another developer, since it's an independent app-component and not an app. An app is composed as a set of functional InterUnits.
Since its a temporal UI-design paradigm, it is possible to maintain memory of how the UI was used (unlike WIMP). The EngagementManager always maintains a memory reference of what the user was doing last, or what they were doing in the past. This improves UI-efficiency, since it's easy to start where you left off. Using WIMP, this can only be done inside an app, such as the "Back" button in a browser.
InterUnit-UI uses a hexagonal-grid (instead of a cartesian-grid) to organise 2-space. This greatly simplifies both graphic-design-specification and spatial-layout in 2D.
An InterUnit is associated with a specific user-function and differs from other InterUnits based on this association. Hence, each InterUnit can be optimised for use-ability independently and on a per-device basis. This makes the development of any InterUnit a lot simpler since the initial code can be refined over time.
We suggest some guidelines for improving the ergonomic-efficiency of PC-apps.
- Doing away with the Menubar at the top, and the taskbar or status bar at the bottom of the screen, to reduce visual screen-clutter.
- Using a visual layout technique generally focused around the center of the screen for the presentation of information to the user.
- Minimising the need to switch between mouse and keyboard operation in the course of any user-input sequence.
- Eliminating use of the mouse for fine-grained screen-space selection and reducing the usage of mouse-drag operations.
- Eliminating the use of Windows.
Operations such as resizing and aligning of Windows, and, in general, (multiple) Window-layout, should not be needed in the usage of the UI. - Always providing a navigational reference.
On a keyboard-input based device, the ESCAPE key should always be used
to return to the previous operational context.
On a touchscreen based device, a visual icon should always be present,
away from the center of the screen to provide a way of returning to the previous operational context.
