My project is an attempt to visually model the most important tasks of an operating system. Allowing the user to view, in a metaphorical way, the processes, services, and resources of a system. This includes, their statistical information such as CPU usage, memory usage, bandwidth usage, disk usage, and any other resource that might be considered relevant. The main goals of this project are to allow the user to view the above mentioned things, in a way that is intuitive, simple and pleasing to the eye. The user interface is the most important aspect of this project, not the underlying program structure.

    The interface consists of different colored spheres ranging from green to red along the natural spectrum. Color is used to indicate the proximity of the represented system object to a defined system bound. For example the closer a process gets to 100% CPU usage, the closer to red will the color of its representative sphere be. The reason for using color to represent bound proximity is because of color's ability to easily represent data in a qualitative way, by playing on the user's natural interpretation of various colors.

    The next aspect of the interface are the sizes of the spheres. The sizes of the spheres are determined by the system object usage of a particular resource, and are relative to the other system objects, using that same resource. If there is only one object using a resource, it's size is determined by its percent usage of that resource. The reasoning behind varying the size of the system objects is to allow the user to easily the relative usage between system objects. The larger the sphere the more of a resource it is using. Potentially the size and the color of a system object may represent the same resource in certain instances, if that resource is used to determine a system object's bounds.

    The third aspect of the user interface are the bars that connect the different system objects. These are used to show the relation of system objects between levels of abstraction. The user will navigate through these levels by clicking on an system object, which will display a detailed view of it components, which can also be system objects, creating a tree effect.

    The fourth aspect of the user interface is the textual identification. Text will be overlaid onto a system object to allow the user to distinguish between one object and another. Although this violates the ideal of the project, different test indicate that this is the easiest and clearest way for the user to identify an object. Using different icons constrained what could be displayed too much. Different shapes and textures caused too much confusion, and created the need for the user to learn and remember too much additional information.

    The user will have the ability to change their point of view according to three basic models. These include the process model, the resource model, and the service model.  These will be the three main branches of the display tree. If the user clicks on the process model, they will get a view of all processes currently running on the system, each will be identified by its PID (Process ID). Clicking on a process will reveal the specific details of a process such as memory usage, open sockets and pipes, file descriptors, etc.  The user will be able to define a universal bound for all process. The default bound will be CPU usage. The resource model will display relevant system resources. Each resource will have a default bound. Clicking on a resource will display both the services as well as the processes using that resource. Potential resources will be bandwidth usage, disk space, I/O usage, memory usage, CPU usage etc. The service model will display user defined services. They will be displayed according to user defined bounds. Each service object will contain all of the processes and resources being used by a service.

    The user will at any time be able to define bounds on object by right clicking on that object. By right clicking on the service sphere, a user will be able to add service to monitor. The user will type in the name that they wish to call the service along with the name of the executable. Service objects will implement a polling architecture by default. All other System objects will not continually update, unless they or their parent is clicked upon, or the user sets a particle system layer to poll.