- 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.
- I'd like to have a complete, integrated user experience that is forward-thinking in that Apple does not put its foot down and say "this is how people MUST or SHOULD interact with computers," but rather "here are a set of dynamic, expressive, powerful, secure tools -- we don't know exactly what people want in terms of user experience, but here are some examples -- please extend them and come up with new ideas on your own." There is no reason for UI objects to be as hard-coded as they are today, nor as static.
- 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.
About the Author
Steve Klingsporn is a software developer looking for a fun programming job in the Santa Monica/West Los Angeles Area. He can be reached at steve@seapod.org or http://www.seapod.org.
- "Part I"
- "Part II"
