I wasn’t going to make this post. Really. But upon reading a kind and thoughtful PM from Patrick K. Kroupa, I realized that I had indeed been slacking. Yes, Christian, I’ve still got my eyes on you 
[size=200]The List[/size]
[size=150]Extensible metadata[/size]
I read that this is coming in a future release, but I thought I might provide some ideas on how it might be implemented. Simply put, make it an AppleScript field that is executed whenever the document is loaded (much like the current attached script functionality), and stores that result in the database until the next time the document is opened. 0 will evaluate to 0. “goat” will evaluate to goat. And (get value for field “Author” of record thisRecord) will evaluate to the value of that metadata field, assuming some minor AppleScript support for metadata manipulation is added to DTP. If a typed field is desired, DTP (or the user) can append a "as " and rely on AppleScript to perform the coercion.
[size=150]Record views[/size]
I read that “record views” or a reasonable facsimile thereof are returning at some point. Again, I only have a couple of thoughts on how this may be implemented. Why not store and edit the templates as HTML, and use a Webkit plugin to replace a tag (? ?) with evaluations of the code contained within? For instance, if there is a simple “get cell # of this sheet”-esque AppleScript command added, all of the UI design and development pursued by hapless bastards like Filemaker just became obsolete. And IMHO, outclassed.
This simple strategy can also turn the CSV sheets into miniature multimedia databases. For instance, if I type , I insert an image from a DTP record specified by the value of the third column. Similarly, with the video tag support of HTML 5 in Webkit, it makes cataloging and viewing small videos (such as from Youtube or taken on your cell phone) quite easy.
If this functionality is available to all HTML documents stored within the database, users then have the ability to easily use data from sheets in other documents, elsewhere in the database.
[size=150]Loadable, global AppleScript libraries[/size]
I would not have thought of this, if it weren’t used by an application I’ve been using recently. Essentially, you place AppleScripts in a special folder and the functions therein become available to scripts running afterwards, without a need for custom code (either declaring or loading the function) in each script. For instance, I could make a function that returns the previous record from a sheet, sorting by a specified column. From that point, typing previousRecordByColumn(“Name”,“ASC”) in a metadata field would order the records of that sheet by the “Name” column in ascending alphabetical order and return the UUID of the previous item in the list. In addition, this might make the smart templates easier for users to code.
[size=150]Metadata-based Searching[/size]
This is a bit more complex than it might immediately sound. All values are stored as text (at least, in my simplified proposal), but how to handle date comparisons, number comparisons, and text comparisons? It’s easy to do a direct text-for-text match – DTP’s been doing that for years, and stuff far more complicated – but with the type unspecified in the database, it becomes complex to do these other comparisons. Of course, if DTP handles the type (which is, in the database, basically just a column containing a “boolean” or “string” or some other type), this difficulty disappears entirely. And specifying the type in the GUI can be as simple as a drop-down menu.
[size=200]Conclusions[/size]
That’s really it. Those four things would make me extremely happy, and I believe they can produce a significant feature bang per man-hour buck.
Right now, the Mac desktop database/information management world really sucks. There’s DTP, which of course I love, and there are several profoundly inferior competitors. If you drift in the direction of database management systems, you find a high-end (Filemaker) option and a low-end (Bento) option, but neither is satisfactory. Filemaker suffers from a major handicap in the form of cross-platform compatibility, a high price, and a specialized, arcane, and steep learning curve. Bento suffers from being a toy.
Now, record views, by themselves, replicate a small bit of the functionality of Bento. Storing the content of cell (and metadata) fields as text, and relying on AppleScript to perform the coercions, replicates all of the essential functionality of Bento. In my opinion, storing record views as HTML far surpasses Bento and even Filemaker (for some usage scenarios). Allowing cell and metadata contents to be AppleScript snippets, again IMHO, far surpasses Bento. With the ability to create libraries of functions that are available to each script, DTP equals Filemaker while relying on knowledge that a large subset of Mac users already possess: knowledge of AppleScript.
DTP is not built to be a relational database, and I don’t expect it to replicate Filemaker’s functionality, to search through arbitrary metadata as fast as Filemaker, or to perform calculations for each record while searching, as Filemaker does. But that’s not necessary – I think that DTP, as a desktop app (not an unholy amalgamation of server and desktop as Filemaker is), would not suffer any decrease in performance or functionality from implementing any of these suggestions.
In short, I see a large vacuum in the Mac app marketplace: a document manager that also handles individual bits of data elegantly and powerfully. I see DEVONthink as potentially filling this vacuum once enhancements are made to its handling of sheets and document metadata.
