Main Area and Open Discussion > General Software Discussion
General brainstorming for Note-taking software
Rover:
superboyac - I was thinking about this around 1:00 AM this morning (when I wanted to be sleeping).
The database thing is exactly what I thought too. Assume that we have a database schemea that has all of the fields we want/need to for tracking notes. That remains the same for any interface that uses it.
Now put the intelligence for searching, add/edit/delete in your application de jour and it's pretty much done. Evermike can still use his presentation, Google Desktop can have a nice api to search the data. Someone can duplicate the OneNote outlining stuff and you're done.
Keep the transaction/record locking stuff in the database itself and you don't have to worry too much about the DDE bugbear. To make it truely multiplatform, you'd probably need a database engine like MySQL. That might sound like overkill, but you can do the same thing with applications for Calendars, Contacts, Email, etc. Just a new set of tables for each application type.
Next we just need to get someone to write a sync. application so we can update our blackberries and palm pilots.
Are we there yet?
Jimdoria:
There yet? I don't know, do you have a shipping version ready? ;D
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.
kfitting:
oooooooooooooooooooo.... I like this idea a lot! Especially the whole user-defined GUI idea. This is the type of program I've been dreaming about as well. The next problem is getting someone to code it. I suppose it's too big for a coding snack!
Kevin
Rover:
Sorry, I just love this thread :)
I just re-read the first message from superboyac. After a lot of whinning about bad apps, and dreaming about good ones, it looks like we're heading off in the right direction.
I'd like to start laying out a database for use with MOANTS (Mother of all Note Taking Software -- I'm open to name suggestions). I started looking for a nice normal database, like firebird, but Jimdoria mentioned using something like AskSam.
I'll start a new thread for MOANTS Database design and we can start discussions for Fields needed and engines. I'll leave it to some nice interface-type folks to start on the application stuff. There are probably two or three interfaces to start with, if you count a google desktop api.
nevf:
So it seems to me that the "ultimate" note taking software either can't exist, or would have to be some kind of super-morphing application, with the user taking a hand in the construction (or selection) of the UI. Perhaps this would look like some kind of free-text database back-end coupled with a dead-simple GUI builder front end that shipped with a number of common GUI configurations out of the box. Maybe you'd start out with pages or tabs (a la KeyNote or OneNote) but you could choose a default UI for each one - the "tree on the left" UI, the "sticky notes" UI, the "scrolling column" UI, the "cloud of tags" (del.icio.us) UI, etc. Then you could tweak the templates, mix and match, or construct your own from scratch. ...
--- End quote ---
Let me talk briefly about the design of Surfulater. Surfulater is primarily an engine that knows little about what it is doing. What you see displayed in the content window comes from HTML template definitions which are stored in the XML database (knowledge base). There are no database schema's, no complex or proprietary database, nothing hard coded into the application, zip. If you want to add a new template (or form in a more conventional database sense) you can, as I showed earlier in this thread by adding a "Note" template for superboac. And CSS gives you control over the look and feel.
Down the track you'll be able to create new templates from within Surfulater itself, instead if hand editing the XML file. In my mind this comes pretty close to a free form database.
Surfulater also uses a tree, witch gives you a variety of different views of the database. This includes folders and articles, just folders, folders with certain articles and a chronological view. More powerful tree views will come when we implement Filters.
The tree is in a dockable/floating/auto-hide window aka Visual Studio. When Tags (keywords) are implemented this window will show a tag cloud, which will provide yet another way of locating content.
Surfulater has a concept of 'See Also' links which enable records (articles) to be linked together to create a web of related information. Simply drag an article from the tree and drop it on another articles 'See Also' field and links are created between the two articles.
Next Surfulater allows you to have a single instance of a record in as many folders as you want, so their is no deciding which folder is the "right" folder for a record. Important stuff.
And as superboyac mentioned you can view all of the records in a folder at once, or just a record at a time, the choice is yours. Again another important capability.
Surfulater lets you embed any files in its database. For example Word Documents, ZIP or PDF files. Alternatively you can add links to external files, so they are instantly accessible, but remain on your hard disk, instead of in Surfulater. The choice is yours.
You can easily push content into Surfulater from other applications. I've recently written about this here and here.
The extensible and flexible design of Surfulater was there from day one, as I wanted to ensure it could be adapted to other uses, besides capturing Web content. I've gone to great lengths to ensure Surfulater is straightforward and simple to use, which belies the power of its core capabilities.
For those interested in more background material on the inner workings of Surfulater I encourage you to read "Surfulater, Under the Hood and Down the Road".
It is great to see this thread spring back to life.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version