On approaching the new platform, you might be presented with one or more of a range of devises varying in size and functionality but sharing a uniform set of coding conventions so the same software could run on any device with the minimal set of resources required to accomplish its purpose. The devices themselves would have a green design and be modular at the subsystem level, so you wouldn't need throw out your whole laptop to get a faster cpu or to change the removable memory card bay to support a newer hardware standard. Indeed, some components could even be shared between device classes when one was retired. So you were planning to get rid of a tablet that held your personal digital library, you could transfer its mass storage module with all of its downloaded academic papers to your desktop machine where its contents would be merged with those of its new host.

Moreover core functionality, like converting between decimals and Roman numerals, converting text to a bitmap, and using a bitmap to drive a Times Square billboard would be factored into discrete modules independent of their user interface. So the same Roman Numeral converter program that could run on your Cell Phone and remotely change the bill board.

For more complex tasks the interface to a core module could automatically adapt to the device being used extending itself through authorized adjacent networked devices. So a tiny subset of a spreadsheet on your Cell Phone display might be projected without cropping onto the wall of your home office as you entered the room.

Developers coding to The IEUC Baseline will first define a fairly fine grained interface to their modules that will include optional resource usage and quality of service guarantees, regressions tests (i.e. test cases illustrating how the module should work), any known pathologies (i.e. negative examples of input not handled), any invariants guaranteed to hold during module execution (e.g. guarantees of no side effects if call-by-copy semantics are applied to module input), the domain and range of module input and output parameters, and last but not least free form documentation with examples applications and hyperlinked references.

This extended specification will be required by the license terms on linking code to the core platform libraries to be placed in the public domain. Only the implementations of these extended specifications will be open to other licensing models including closed source proprietary ones, which might exceed the performance guarantees of the base interface they are implementing. So one black box implementation of some Interface X might offer a lower maximum memory usage guarantee while another might offer faster worse case performance relative to the size of its input. Either could be hot-swapped in, in place of the other allowing a running system to dynamically reconfigure itself!

Moreover, this component architecture will have a fractal quality encouraging End Users to mix and match both commercial and open source implementations and aggregations at different levels of abstraction opening the door for End Users to effectively debug sealed black box modules by correcting easily inferred (from component failure cases) interface specification errors and injecting point-cuts to filter their inputs and outputs or route around them entirely if needed.

Say an implementation Y of interface A has a bug that causes it to fail if its input contains more than say 1024 records to cluster. Now, posit that there is also a much slower or more memory hungry reference implementation of A that works for any number of records. Without having any access to Y, an End User could now add the newly discovered maximum record count constraint to the interface of implementation Y. The system would then automatically rout requests to cluster more than 1024 records to the less efficient fall back reference implementation while still using the otherwise superior implementation Y where it known not to fail.

This gives us the best of both worlds since it lets us view Y as a correct implementation of its modified interface in the wider context where the overall system is only somewhat less efficient that it would have been absent the bug in Y. (As an added benefit the failure case and fix could be propagated to other End Users and to Y's original developers so they could potentially fix the bug by making their code up to a higher maximum record count, or correct their marketing and publish an amended implementation performance specification.)

Logging in could be accomplished by a biometric scan or by bringing a wireless access token into close proximity with your system. There would also be a provision for transfer rights from one owner to another and upon such a transfer any personal information not explicitly marked to be carried over would be securely purged. (This is a serious consideration with cell phones and pda's that get discarded with personal data on them facilitating identity theft).

Once logged in, subsequent passwords for account access would be managed transparently since trying to memorize and track multiple logins merely encourages weak password choice. For truly secure situations a pass phrase could be required in addition to the biometric or token based identifier permitting the End User to supply a distress code if under duress. Passwords sent over the network could be generated on a one time basis using any of several mathematical techniques to further enhance security.

All of the chunks content entered into the system would be tagged with their origin, unless expressly stripped of that metadata. A simple to understand set of security wrappers as formalized with an Object-Capability model would then mediate which tasks and operations would have access to them.

This would allow us to support more a nuanced digital rights management approach that we call Fair Digital Use in which limited copy would be permitted with automatic attribution and a cryptographic binding of the True Name of the copier. One would not be required to subscribe to the regime unless one wanted to access this transclusion capability with regard to protected assets that would be highly prized by pirates like first run Hollywood Movies. For legitimate users wanting to splice 20 seconds of a feature film into a review for a middle school assignment, having their identify embedded in the copy in a form that only be accessed — unless they chose not to shield their identity from third parties reading the report — with permission of the original copyright owner (say while investigating a Piracy Ring), would present a negligible privacy concern and do much to make first rate commercial content accessible on the platform.

This same fine grained approach to security could even further guard against misuse by making it easy to require multiple simultaneous co-present geographically bounded authentications to access particularly sensitive functions like making large denomination wire transfers between bank accounts. In the event that a duress code was entered, authorities would be notified and all subsequent activity would be logged and treated as a transaction that could be rolled back as soon as all participants were safe.

Once authenticated you would first be stuck by its simplicity. Banished would be the stacks of overlapping windows and twisted hierarchies of drop down and pop up menus.

An IEUC Baseline system configured for desktop use, would probably provide a large wide format flat panel display possibly with full color 3-d capability (achieved with glasses or preferably a headgear free lens system ), a 6 degree of freedom input controller, speech recognition and synthesis capability, a traditional keyboard, and tablet for sketching.

The display itself would initially be partitioned into two panes, one graphical and one textual, both of which would be remarkably free of clutter. The 6-Degree of Freedom controller would permit the elimination of graphical scroll bars and zooming controls. Selections in the visualization pane could be referenced in the textual dialog with pronouns so one might select several nodes and say or type, "What is the average balance of these accounts?" or "Show me a tree map weighted by citation frequency of the items in this outline."

A zoomable interface paradigm would be employed throughout to eliminate the clutter of today's overlapping windows and virtual desktops.

Thus you would be able to directly invoke a visualization that might require navigating a large number of modal parameter selection dialogs in one of today's systems. You could further simply the interface by invoking expert system support by requesting a "walk through" of some common task.

The system itself would maintain a "discourse model" of what you were talking about to draw reasonable inferences that it could confirm by injecting a confirmatory query into the dialog. At that point you could answer or digress or request an explanation of the reason for the query.

This same interface and level of interactivity would extend to both Explicit End User Programming and Programming By Example as in a directive to the system to "Watch how I group these items".

Documentation with live examples could be call up in the display pane as well making an IEUC Baseline system a digital library of its own design. (See the Inform 7 interactive fiction authoring environment for the closes extant system to what we have in mind.)