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?".
Development roadmap
- 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.
Advantages of InterUnit-UI over WIMP
Simplicity
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.
Ergonomic-efficiency
An InterUnit's source-code is self-contained
and can be modified independent of other InterUnits and the EngagementManager component that will host it.
This makes it easy to produce an ergonomically-efficient InterUnit.
An initial design can be produced and it can be refined over time to improve ergonomic-efficiency.
Better Reuse
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.
Memory
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.
A developer's view of InterUnit-UI
Easy to optimize the UI for use-ability
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.
Guidelines for improving app-ergonomics
InterUnit-UI suggests 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.