Killer User Interface

KillerUserInterface is the GUI for the imaginary KillerOperatingSystem.

In most operating systems, the user is at the mercy of the programmer. It takes many programmers to make an operating system. Therefore, the GUI is inconsistent, incoherent, and generally annoying. There is a nice writeup on GUI annoyances at

Here are some attributes of the KillerUserInterface.

There have been many attempts at KillerUserInterface. Please list them here. One interesting "rebellion" from common view of the KillerUserInterface would be to consider the entire computer learning curve, from 5 year old to programmer, with an eye towards minimizing learning humps, so that people more naturally discovered the full power of the machine. An example of such an idealized system would be the following: Users could easily be exposed to and learn from the internal workings of an application's frontend, which would usually be very simple programs that merely poked powerful libraries underneath. In principle, virtually all interactions would be scriptable, bringing more users to scripting, and hopefully saving enormous amounts of time.

Regarding UI consistency, to minimize learning humps and etcetera: The Windows API, although crumby in ways, intended to be consistent and programmable, unlike all the unix GUI's which make nearly each and every application different looking, with no common programmable API. i.e. consider that many QT apps look totally inconsistent with GTK apps. Console apps all have different looks too (midnight commander, emacs, vi). A lot of the applications on unix had (and still have) totally inconsistent key bindings (and keys are related to the UI), until KDE came along and copied microsoft with regards to consistency (some claim KDE/X11 dumbed down unix, and killed it). Even the mouse acts differently in some unix programs.

The OS/2 operating system had some sort of standard application thing going on for a while (forget what it was called) to improve UI consistency.

Also, regarding a programmable consistent UI script-ability - again the Windows API messaging system allowed one to take control of the GUI of nearly any application (with some security implications, although not many noticed) consistently. Whereas unix has no standard consistent localhost GUI API (except for X11, but, that was more for remote control). People use arcane tools like sockets and shared memory to control localhost GUI's, if at all, on unix. This, in my opinion, needs improvement and it doesn't do well for ease of use. The attitude, sadly, of unix programmers might be that it shouldn't be easy to use.

One of the problems with the Win API, was it was always fairly hard to use.. sending odd parameters to sendMessage and similar functions. However, people built wrappers around it and made scripting systems - although they never really caught on (microsoft windows scripting host, JScript, CScript). Now that the DotNet buzz is taking hold (or is it?), things are a bit different (how does one even control a .Net application?). But, OS/2 and microsoft did try always to make the killer user interface.. and somewhat succeeded if you look at their sales (not that popularity represents quality, though ;-)).

I wonder how many deaths can be attributed to failures or stalls of the Windows operating system.

I'm not particularly fond of the "shell" model for User Interfaces in any case, and DOM-driven web applications are only slightly less broken. A shared document or object model with publish/subscribe is much "better" in terms of (potential for) security, scalability, composability, performance, robustness, multi-user sharing, zoomability, etc. - especially after getting rid of built-in semantics for manipulating or updating DOM in favor of strictly issuing commands to arbitrary remote objects, which may or may not cause feedback that updates the document.

The document model (DocumentDefinitions) and ObjectBrowser are distinguished mostly by the fact that, in the document model, the mapping of a document-description object to arbitrary non-document objects becomes explicit - a decision by a document server. Much less intelligence is expected of the browser, and greater flexibility (in terms of styling, composition, etc.) is available to the document server. In addition to that complexity advantage, the 'document object' interface can be designed from the ground up to support the browser which can offer advantages in terms of update latency, liveness, performance, composability, etc..

For KillerUserInterface, the document model is the best candidate so far, better even than ObjectBrowser by the metrics that matter, though relative quality of a given document model remains contingent upon designing a good 'document object' API and a good 'GUI language' (e.g. DeclarativeGui).

This is more than IwantaPony, this is "I want a Swiss Army Pony" (SwissArmyKnife) that has every BigIdea known to man.

See Also: ObjectBrowser, DocumentDefinitions, HandVsPointer, TheHumaneInterface, DontModeMeIn, PlanNine, CanonCat, DeclarativeGui, ProgrammingLanguageNeutralGui, EverythingIsa, FlikiBase


