Build Your Own Information Environment
We begin with an atomic concept that is simple and general: simply a unique ID, an author, and a time of creation (and sequence number, just to be safe ;-). The time is a unique ID itself, and we might want to combine these two things.
What's the idea here? To construct, in several simple yet general steps, a useful information environment. I imagine the process taking not much more than an hour in a Vi Hart-style progression, and not involving much more than 2000 lines of code. [10/18: still under 200 and several things work]
Copying
When an object is copied, it gets a new ID, author, time and sequence number. A whole bunch of notes, for instance, can be made simply by copying an existing note and, where desired, editing its content text.
Collaboration
Much of this project is simple, almost trivial, database behavior. The hopefully interesting aspect is its brute simplicity, and therefore the ease of conducting experiments, such as making this all work as a collaborative information environment, and including active content as well as more conventional information.
Any item can have properties added to it to be more useful as, eg, a sticky note, calendar item, a contact item, or an email. Some properties are atomic, such as a tag, "family", and some may have associated values such as "date" for a calendar item. Some properties may be collections or ranges, and we'll try to do a nice job of that before we're done.
Properties
Search
A search panel consists of two panes, a filter pane and results pane. It may also be targetable to a database other than the default database. Any of the properties in the system can be used as search patterns, simply by dropping them in the filter panel panel - these will match any object with any property matching the one in the filter. A more complex object such as a library book reference can be dropped in the panel and the search will filter those objects that match all of the fields that have been filled in. A tag as a filter looks for exact matches for that tag. This could be more permissive but, done this way, it's like post-facto classes which I think is cool.
The Item
About this project
Views
All objects in the system will have some default morphic view, and some may have several different views available. Typically the instance stored in the parts bin will be used as the default view, and such views will have a protocol associating a view with a stored model.
This is all similar to the process of defining new record types in a database and then making many instances of them, but there are other goals here: To make it very simple and thus easy to experiment with To make it concrete so as to be understandable to end-users To make it collaborative, and thus a tool that we can actually use
Fields
Just as a note is a concrete representation of an item in our database, so are fields the concrete manifestation of properties. A field consists of a name, a type and a value, and these correlate with properties of a the model in javascript and the database. A field may also carry a label and special editing features such as a calendar button for selecting days. These are viewing state only and are not represented in the database.
Extensions
Fields can be added to an item, thus defining a new kind of object. When this happens, the itemName will be reset to 'asYetUnnamed' or the like, but the logic for storing and retrieving as a data object should continue to work.
Database
At the outset there will be just one database, a simple JS object attached to some morph, like an ellipse. As soon as things are working, this will be embellished with a search interface, and then extended to collaborative access.
To make this exercise meaningful, so we'll start with a basic item, and add text to it like a "sticky note", arguably the simplest usable item of personal information.
The Note
DB
Filters
Results
Here is a thought...
X
C
-
Poems
A couple of things to try...
X
–
Menu
Yet to do...
X
–
Menu
Workspace
X
–
Menu
Things to fix...
X
–
Menu