System and UI
The Isaac has a full featured API which not only provides developers with the tools they need to make full-featured applications, but also provides a basis for a uniform user experience. This document covers concepts for how that user experience works.
Like the Newton, the Isaac has a toolbar to the side of the screen. Like the Newton this will be customizable with different applications, but it will also feature a more in-depth feature set to dissolve the modal nature of the operating systems we are accustomed to. Imagine something half way between the OS X dock and an NSToolbar. The action bar could have icons for an application, say your notebook, but it also could house actions like undo and also have tool palettes, like a text style palette. This lends itself to breaking down the traditional modal walls that exist.
Within the Isaac API, a standard set of actions will be defined. How different applications handle these will be up to the developer, with much help from the APIs. Actions like Undo, e-mail, fax and print will all be included in this standard set. Much of this could possibly be implemented for free, with the ability to override the default handling to enhance them for application-specific tasks. Also developers can choose to disable certain actions where they don't apply and define ones that aren't OS-wide.
The Action Registry exists to allow all actions to be trackable. It keeps an inventory of all the actions that exist, and all the applications that implement each action. So, potentially, a user could select an action, and then select an application they'd like to perform that action. More likely a user will have an action, such as e-mail, in the ActionBar. When they tap the action it will perform it for whatever context is focussed.
Being a physical device that is terribly mobile, there should be a simple and easily accessible system for changing the screen orientation. This is partially achievable by having a detector within the device find the orientation and rotate the view accordingly. However when the device is flat on a table, it is nearly impossible to judge how the user would like the views to be oriented. One possible way to judge is simply detect handwriting orientation and adjust to meet that. Additionally a small diamond could be located at the center of each edge of the display that a user taps to switch that edge to being the bottom of the display. This way the user is free of the burden of keeping a display rotate action in the ActionBar, as well as thinking about concepts like rotating 180 degrees vs. 90 degrees clockwise and counter-clockwise.