Just some days ago Apple requested input from PC users or from Mac users coming from the PC world. They asked for some input regarding what a PC user would like to see on Apple’s products. While I am already a Mac user, I would like to see the following. If it doesn’t happen (as it hasn’t), I intend to do it myself with some smart friends. – This would be built atop a very simple, extensible, dynamic messaging system, similar to Newton frames that have arbitrary name/value/(flags) “pairs.” All messaging, including instant messaging as well as the event system for the user interface as well as observable/observer systems would be built atop this dynamic messaging system.
– I want my computer to turn on and boot in 10-15 seconds. We all know this is possible (BeOS). Instant-on functionality would be very nice.
– I’d like to be able to watch several movies at once, and move them around on-screen without skipping frames. I’d like to be able to listen to music, utilizing 1-5% of the CPU, without ever skipping. Playing background music can be, and should be an effortless task.
– I’d like to see the kernel be able to schedule tasks effortlessly across as many processors as available, and support clustering or “grid computing” across local networks and the Internet.
– I’d like to see a very dynamic plug-in architecture that drivers for the kernel as well as applications and everything in between use for extending things instead of separate API’s for doing so.
– No more CFPleaseLetThisMadnessEndOneDay names, please!! Let’s see some very nicely-designed objects with nice method names and a consistent naming scheme used.
– Everything should be re-entrant and thread-safe, where possible! If locking is required, the system should provide for it unless the developer ABSOLUTELY needs to do it, and this should be clearly documented if it’s the case.
– Legacy-free. No Carbon, Cocoa — something completely new and parallel to the Macintosh/Mac OS X effort would be very nice. An emphasis towards performance, code size, efficiency, and simplicity would be very nice.
– I would like to have a scalable user interface in two ways: In one way, I’d like to be able to start with basic, primitive functionality like pointing and clicking, identifying objects, examining their various properties/attributes, seeing a list of actions or operations that can be performed on them, performing such actions and operations, etc. I’d like to see an interface that could start primitively and grow with the user in complexity. A child could have simple objects on the screen, and the same system/account/workspace would “grow with the user” as she gets older, revealing more complexity as time moves on or new types of interfaces are available.
– I’d like to see a visually scalable interface that is independent of screen or output device resolution. The interface should be able to work on an arbitrary # of screens or output devices. It should be pen and touch-aware. It should be able to work over the network in a minimal client fashion, or locally. Where the actual code is running should not matter. You should be able to scale the level of detail and size of the interface and the objects which comprise it to maximize for smaller displays or for poor eyesight. This means less use of bitmaps and more use of scalable vector-based artwork and code.
– I’d like to see arbitrary “painters” that are easily created that define the appearance of objects in the interface. You could separate the actual behavior (to an extent) from the presentation. Further customization would be “Themes” or collections of such “painters.” Themes could have different “variants” — things like color choices, image choices, cultural or International resources, etc.
– I’d like to be able to buy an Apple-branded PDA that runs a modern version of the Newton OS. I would like to see these Newton frameworks available across the board on Mac OS X on any computer, exportable to portable devices, set-tops, appliances and other forward-thinking/lifestyle devices. I want to be able to use the dynamic, expressive power of Newton frames and soups to represent and store data. I believe that there is a lot of promise with frames in a networked environment, and that they are the best means I have seen to date for expressing views/user interfaces and quickly and dynamically implementing user interface object behavior.
– I’d like a simpler, object-oriented, highly-expressive, highly-dynamic API that I can use to piece together slick, fast applications that are not implemented as directory bags/packages, but rather a single entity that can be easily moved around. I want a very straightforward, simple class hierarchy. I’d like to be able to have only one book that describes the entire API.
– I would like for files to be associated by MIME type, by their “magic number” or header information, and then finally by filename suffix if the type cannot be adequately determined otherwise.
– I’d like to be able to have my data stored somewhere on a server, and access my data from wherever I am, instead of worrying that my data is at home, at work, in my PDA, wherever.
– I want to be able to stream any music, movies, or text that I’d like to any device at my leisure, be able to bookmark or otherwise save my place in said content, be able to share links to this content or even mark up or comment on it with others as well as save excerpts of this content for later browsing.
– I would like to easily automate repetitive tasks, and would like for the system to notice when I make certain choices over time and ask me if I’d like to somehow automate it or set default choices.
– I would like to have some notion of online “presence,” sort of like an instant messaging system that is built into the operating system. I would like my online status to be publishable, and would like to be able to let people have access to this status based on any number of rules or criteria. I would like for text and video/audio messaging to be an integral part of using the system.
– A “frame” is a list of arbitrary attributes. It is basically an object at the lowest level of the system runtime that has attributes that describe and implement it. Some attributes can be methods or executable code.
– A “container” is a frame that has a “contents” array with some standard accessors that can be used to add, remove, describe and otherwise iterate over the container’s contents.
– A “context” is a container that has one or more threads (or a thread group) associated with it. “Handlers” can be added to a context that take arbitrary messages (or filter them with some filter procedure or attributes) and can handle them, absorb them, pass them on or stop them in their tracks.
– A “agent” is a context that can “go” various places on a network of nodes and containers. It can have various tasks or handlers associated with it. It can have a signature that identifies it and where or who it comes from, which can be used as a basis of security. They can be local (used to automate tasks and what-not), or remote. They can have a life span, or a certain # of iterations before it “dies” or moves on. It can return back to the sender(s) when it is finished, optionally.
– A “place” is a context that can have agents running inside it. Can be used to implement a chat room or a “place” online that can have one or more ways of describing an optional user experience. A “place” manages the various messages associate with it. It can represent a physical place or a virtual place.
– A “scout” is an agent that can travel from place to place and sends messages back to the originator or user. A perfect way to present the user as an online entity or presence that can be used for chatting, messaging, exchanging files, or otherwise operating or carrying on on a user’s behalf. A scout could, for example, travel to a place, and if admitted, send back the user interface description for the place, which would be built dynamically on a user’s screen. That interface might have a text field that can send messages to the scout, which drops the message in the place it’s in. The handlers in the place distribute the message to other scouts in the room, which in turn send the message back to the user, where they are displayed in a window or what-not.
– I would like to see less emphasis on a whole pile of windows on the screen and more emphasis towards what Raskin calls the user’s “locus of attention.” In other words, people generally only want to view or act on a few discreet pieces or views on information at any given time. I’d like to see more effort expended towards efficiently allowing the user to see an overview of the various views being browsed and switch effortlessly between them. Likewise, I’d like to see innovative new ways for telling the machine I want “these three things on the screen right now” or even indicating prominence or priority for them.
– I’d like to have better interfaces for rapidly entering various types of data that I encounter on a daily basis, from whatever machine(s) I have access to at the time, and be able to quickly recall that data later. I’d like to be able to freely group and associate this data, and would like for typical types of data (URL’s, phone numbers, e-mail addresses, physical addresses, etc.) to be automatically recognized and indexed as such. Instead of having hard-wired hierarchies that are represented in the file system “where they exist,” I’d like to be able to browse and search for data quickly and efficiently based on attributes and (user-defined) types in a freeform data soup.
– This would necessitate that the graphics and view system basically provide support for N screens or display areas that have a DPI resolution, a scaling factor, and arbitrary sizes and shapes that can be arranged in different ways (with the edges running into each other or being separate, even bordered). There would be arbitrary non-rectangular regions that could optionally have shadows or other dynamic visual properties — windows, if necessary, would be implemented on top of these regions. These regions could in turn have views, with an x, y, and z position as well as separate layers which could be hidden, scaled, shown. A set of core graphics primitives — 2D, 3D, whatever. A standard way to represent views that is very dynamic in nature, maybe employing prototype-based inheritance like NewtonScript has. On top of this, go nuts, and allow users and developers to do so as well.
– For bitmap-based UI objects, it’d be nice if they were stored as YCbCr color-space objects, where the Y value represents the luminance information. It’s very easy to color objects when represented or converted to this color space, so you could, for example, have whatever color or “flavor” of bitmap objects that you like, and these colored objects could be cached as colored to speed performance.
– It’d be nice to have an interface that scales nicely from a textual interface to a phone interface (voice, keypad) to a 2D interface, to a 3D interface, and be dynamically extensible.
– You should be able to browse, find, get, purchase, and update everything over the network. For example, if you buy a phone that is Apple-enabled, you would turn it on and have a very nice graphical picker for services, user interfaces, ring tones, and the like. Fully integrated into the system. Likewise, you should be able to share your creations and content with others — all using the same mechanisms.
– It seems that “ad-hoc” networks are a very interesting phenomena to start exploring. For example, driving on the highway in bumper-to-bumper traffic — seems like a network where packets can hop in any direction down the chain. Also, being able to associate real places with virtual places and content would provide for unprecedented location-specific levels of functionality, not to mention marketing and social opportunities.
This is just the beginning of what I’d like to see. And discussion I would like to see as well.
– This would be built atop a very simple, extensible, dynamic messaging system, similar to Newton frames that have arbitrary name/value/(flags) “pairs.” All messaging, including instant messaging as well as the event system for the user interface as well as observable/observer systems would be built atop this dynamic messaging system.