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 http://suck.com/daily/2000/04/10/.

Here are some attributes of the KillerUserInterface.

DontModeMeIn - taken as a high-level and encompassing theme for the KillerUserInterface; this implies NoApplication
CapabilityUserInterface - the tenets of CapabilityUserInterface are followed; essentially, users shouldn't be led to believe they can do that which they may not, users should always know the capabilities they are forwarding when they perform certain actions (even if it is just a color-coding with fuller information available in accordance with ProgressiveDisclosure and ZoomableUserInterface), the easiest and most natural way to do things should be the most secure, etc.
ObjectBrowser - the KillerUserInterface is fundamentally a browser of objects with which the user possesses capabilities to interact (at minimum, the user must possess capability to know they exist). The ObjectBrowser offers an InteractiveSceneGraph to the user of all objects with which he or she is currently interacting. 'Object' here is very loosely defined and means anything that can reasonably be reified and displayed or represented in a browser - including web pages, 'files'
- Alternatively, a document browser - which doesn't provide 'display' capabilities except from document objects, but that might provide command-capabilities to arbitrary objects. This avoids the need implied by ObjectBrowser to intelligently come up with descriptive elements for arbitrary objects. (DocumentDefinitions).
ZoomableUserInterface - the illusion of a smooth transition is offered and all files are always 'open' ('open' vs. 'closed' violates DontModeMeIn). This could range from just one object up to any number, and careful attention to LevelOfDetail? is used to maintain efficiency. Open stateful objects are readily edited should one have the capability and the tools to perform a meaningful edit.
ProgressiveDisclosure - related to ZoomableUserInterface, but based less on spatial organization and more on apparent degree of user interest. E.g. if users express interest in learning more about an object, they can easily learn more (to the degree they are capable): getting a list of available interactions and expected semantics, looking at source-code, auditing messages going in and out, entering a debugger; if a word in source-code doesn't mean much to them, they can ask for help on that and get a window they can zoom in on; etc.
QueryInterface - the scene on display in the ObjectBrowser and ZoomableUserInterface is an automatic layout from performing a query that returns URIs for a collection of objects. These objects are laid out automatically, but in accordance with an ordering decided as part of the query (not as part of the browser - see ImmediateModeGui). The ObjectBrowser supports easy construction of the most commonly desired queries. This can be seen as a massive generalization of the FileSystem browsers seen today, with the 'query' in a modern FileSystem browser being severely limited to identifying a single 'folder'. Note that what the query returns is often dependent upon the state of the world, so the QueryInterface should subscribe (or poll) as necessary to maintain the layout over time. Multiple queries can be maintained at once (e.g. query1 | query2) with automatic layouts of choice (which could give illusion of separate windows or all in one pile).
Automatic Layout - Objects in the ObjectBrowser need to have a layout that is significant, predictable, and automatic. Allowing users to move stuff around is trivial, meaningless, and ultimately creates extra and unnecessary state to maintain - see TheHumaneInterface and RK's discussion on ObjectBrowser for more. Users may, however, define new Automatic Layouts or twiddle the parameters of their current Automatic Layout.
HandVsPointer - using the pointer, objects (URIs) are 'picked up' and dropped into a (zoomable) bucket or list visible on the HeadsUpDisplay? for further action. I.e. more 'clipboard', less 'drag and drop' (though you could still drag and drop). This can also be used for actions, which can be dropped onto a collection of objects.
CommandLineInterface - a good CLI with a ReadEvalPrintLoop should be readily available and fully scriptable, and should also include all simple calculation needs.
Predictive, AssociativeMemory (use of cameras and microphones, MindControlWithDerrenBrown); more than just command-line completion, but that too
FirstClassUndo - KillerUserInterface and KillerOperatingSystem interact to make KillerUserInterface aware of what sort of actions can feasibly be undone, and for how long they can be undone. As much as possible, use of Undo is preferred to use of confirmation dialogs.
ImmediateModeGui / RestfulArchitecture? - state of ObjectBrowser displayed to user is 'immediate mode' to within limits imposed by practical concerns for TransparentDistribution and efficiency; in particular, the only 'state' that should be held by the ImmediateModeGui is that 'state' that is there for security (session keys), optimization (cache, communications context), and configuration purposes (e.g. how does ObjectBrowser interact with local machine, plus current user 'preferences' and 'bookmarks' and any 'cookies' acquired (securely) by URI); as much as possible, the state of the ObjectBrowser is determined wholly by the state of the objects one is browsing. The state of the ObjectBrowser itself should be stored in a browseable object.
History and Replay via versioning, albeit possibly degraded; taking advantage of ImmediateModeGui
Multi-user interactive - multiple users can cooperatively edit a single file and see each other's edits in SoftRealTime?; a bit of WikiWiki and WikiIde blended into both the KillerFileSystem, the KillerOperatingSystem, and the KillerUserInterface
TransparentDistribution and mobility - UI fully accessible via any ObjectBrowser across network, ideally even designed for it from the start
GracefulDegradation - bandwidth-intensive activities must be network-translucent and be able to provide degraded service over a limited connection, possibly compressing more and shifting higher level interpreter logic into the ObjectBrowser for retained-mode communications context (caching for communications optimization doesn't violate ImmediateModeGui). Also, services should be available in slightly-degraded form (likely loss of most ObjectBrowser features, but full access to code and ability to enter queries and objects) via WebServer, along with the ability to download the full ObjectBrowser (possibly the user's specialized version) via the WebServer.
TableBrowser, especially a "smart" table browser that allows all the options and validation of the corresponding form such that we can do in-table data-entry if desired.
Delay and DisruptionTolerantNetwork support for online activities: ability to very easily edit and read cached versions of traditionally online material, and such edits will be maintained for automatic merging when going back online.
Full composability or MashupMaker - ObjectBrowser makes it easy to mix and match components to within the limits they can fit together (according to typing rules and security constraints), making it trivial to take existing components and recombine them. Possibly see QedWiki and ActorsActionsAndArtifacts? (on services and use in a query/search system)
Extensible - a representation of the ObjectBrowser itself is among the set of browseable objects and can be modified at runtime (RuntimeUpgradeableCore) and modified to taste.

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:

A GUI based upon a client server model within each applications. An application consists of a backend library and a frontend, an idea reminiscent of Java if network transparency is implemented by uploading a bytecode frontend.
The backend may be written in any language, but frequently mid & low level ones. The frontend, however, is expected to be written in some language which is not overly obtuse, and should have an interactive or shell-like variant. Haskell would be an ideal choice. When compiled, the language is remembered & can actually be "watched" by the user, say by opening up a dialog at the bottom of any window. AppleScript is a vaguely similar idea.

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.

It's called CommonUserAccess.

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.

AprilZeroEight

CategoryUserInterface