There yet? I don't know, do you have a shipping version ready?
There is precedent, of course, superboyac. (Does that mean one should never do something unprecedented?)
The UI idea isn't actually all that far from something like the Visual Studio.NET interface, where you can dock multiple panes in different parts of the application window. And I didn't know you were an EE, though I'm not too surprised. I just threw it out because of the reputation of engineers to be very focused, logical and orderly in their thinking. And performance artist I just chose as a kind of opposite: expansive, intuitive and nonlinear in theirs.
At its barest level, the Frankenote UI would be something like a blank canvas. But since that's too scary for a lot of folks, ideally you'd have the idea of templates incorporated into the product. When you created a new page, you'd be given a choice of which template to base it on, one of which would be the blank canvas. Others would be templates analogous to the some of the UIs of existing apps. So you could have an "outlook" template, a "one note" template, an "evernote" template, etc. Since they're just pre-defined layouts, they would be immediately usable but also immediately tweakable.
A "note" should be able to store any kind of content, almost like a Word document. I can see the need for a few basic note types: formatted text, bitmap graphic, vector graphic. There would probably be a few specialized sub-classes of these, too. Everything else is a view. The trick would be this: as soon as a note is called on to contain more than just formatted text, it
silently and transparently changes itself into a view! So you’re typing away, and you decide to paste in a picture. Behind the scenes, the text becomes its own note and the "note" you were working with becomes an aggregator view containing your original text note and your pasted picture. If you continue typing text under the picture, that text becomes (internally) a third text note displayed in the view, but stored separately behind the scenes. This is all invisible to the user. As far as they are concerned, the "note" consists of text-picture-text. They will never see it represented in any other form.
Inside a view, there can be notes, other views and links. Views need a killer memory as to how they are constructed. Part of a view is its query, or what database items it uses to build itself. Part of it is its formatting rules. Part of it is its nesting rules (what kind of view can I be inside? What kinds can be inside me?) And part of it is its collection of links.
There are two types of links: hard and soft. Hard links are created and maintained by the system. Soft links are user-configurable. Take the above example of a text-picture-text note. The links in that view are hard links. The user never knows that it is actually a view - to them it is just a single note and they work with it as such. But to the program, it's a view with hard links to the two text notes and the bitmap note. Another example of hard links is a table. The table is really just an aggregation of notes (each cell is a note) with hard links that keep them together in the table layout. When you paste Excel data into Frankenote, the program converts it into a native table view and embeds that view in your current note, just like it handled the picture.
Soft links are used by the user to "wire up" the UI. Suppose you start with a blank canvas. You add a tree view - which is a type of aggregator. Now you have a tree view inside a canvas view. The tree view has some default contents - lets say it shows a node for every note in the database (and it shows what the USER considers "notes" - pure notes and views that contain only hard links.) Those tree nodes are notes linked to the view by a soft link. The user could change the soft link and have the tree show only the notes that were created in the last week, or only the picture notes, or whatever. (The notes appear as tree nodes because a tree view's formatting rules specify that this is how it displays the notes it contains - it takes their "title" attribute, assigns an icon based on some criteria, and creates a hierarchy based on some other criteria.)
Now you want to be able to select a node in the tree and view it in the canvas. So at the top right corner of the tree view is a small icon that looks like an electrical plug. You drag this icon out and drop it onto the blank canvas. This creates a soft link and wires the two views together. Now when you select a node in the tree, the note is displayed in the canvas.
This is the simplest case, but it pretty much encapsulates the whole concept. This concept of views is powerful because it is recursive. There would have to be an arbitrary limit on the recursiveness though, or things could get really ugly.
I absolutely DON'T think a SQL back end would be the way to go. I'd say a free-form database engine along the lines of AskSam is a better choice. Take a look at
this page if you're unfamiliar with askSam. Especially the part under "Why People have chosen AskSam." Trying to map a beast like this to a rigid field/key/index structure is asking for heartache.
