A Historical Sketch

My earliest model was conceived as a system for studying plant growth. Through collaboration with a colleague it was expanded to a system for ecological modeling with nascent educational capabilities, called Ars Botanica. We spent a few years pitching the idea to local and national government groups who have a stake in natural resource management and risk assessment. From there I continued to develop the systems ideas further in an attempt to find broader application while still maintaining the strength of historical work.

The additional work included a heavily modularization of the core components, so that they could be mixed and matched for system implementations outside of ecological modeling and management. The benefits of modularization were made possible through a strong discrimination of view configurations (portals), module component layouts, and visual themes. The portal specification would define the modules & functionality involved in an implementation - i.e. for a K-12 school, university, group of government risk assessors, farm, casual social community, private horticulturist, independent team, etc. The aspects of the model will be laid out briefly below. Each item will be covered in greater detail in the Overview of Features section.

Layouts would specify the arrangement and visibility of the modules' interface elements. Different functionality would be displayed based upon user. This is the layer where privileges would be implemented as necessary. Themes (or 'skins) are a layer of styling set by individual users, covering coloring, font sizes, and other aesthetic or ease-of-vision display settings.

Modules in the system are logical blocks of code that generally have a unique visual interface style and conceptual flow of information. I had grabbed the most recognized interaction metaphors as modules: news feeds, journals/blogs, wikis, a calendar, and a [research] notebook. The notebook concept was, and is, the least developed in the public spectrum - no clearly intuitive interface has come forward in this area.

Module Accessories are components that are most, or only, relevant in relation to other content - such as in a module. Forums for discussion, version history, automatic syndication (RSS, ATOM, etc), image galleries and a visualizer. The data visualizer is, as the notebook, the component with the least agreed-upon interface.

All of these elements and their information would be stored in a relational database. The basic level of getting data into the database would be through user input via the interface. Data could also be sent via a server that manages sensors, or sensor networks (in the case of environmental monitoring). A distributed database could ease the sharing of information between collaborating groups, public and private, and is the first step toward a system that allows for new models of education. The logical next step is towards a model of a distributed system with many people accessing it and interacting globally. Grid computing, meaning the shared usage of storage, processing and network resources, is the big tie-in that many are now beginning to consider on the path toward new models for research and education.

The broad scale ideas will be covered later, after we have built a foundation of the individual components.

© New Alexandria 2002