One of my frequent suggestions (repeatedly nixed by Christian with good but IMHO arguable reasons) has been a plugin API and the ability to hook into certain functions of DTP, like data visualization. My frequent examples are Graphviz and TouchGraph. Or someone bright might make a new mind-mapping plugin or outliner plugin. (If all works out for me, I might be going back to school to get a BS in Computer Science. I’d love to start really getting into Objective-C in my off-hours, and I think a great way to do that would be to code plugins for my favorite app).
Many people will answer a request for data visualization in DEVONthink with “Well, I don’t need it, and 75% or more of the userbase doesn’t need it, so just use some other piece of software.” That’s fine. Now, the power of an application like QuickSilver is that BlackTree didn’t code the hundred or more plugins available for the application. Quicksilver by itself is just a launcher, and even with plugins is limited to basically replicating Spotlight’s functionality with a more powerful interface with the crucial addition of allowing the basic items (files/messages/contacts/applications) to be used as objects in a long chain of instructions.
Yesterday I referred a user with a comment to Path Finder 5. He already used it, natch, but that’s irrelevant. One thing that I’d really like to see DEVONthink take cues from is Path Finder’s UI. I see this conceivably fixing all of the UI issues that trouble me about DEVONthink (tags, hateful info panel, etc), as well as UI issues that will be presented by things like the extensible metadata.
If you’re not a Path Finder user (I’m not), check out this video and note the following:
-
the “breadcrumbs” ( > Leopard > Users > etc). Someone else has requested this, and the widget is available in XCode, so I’m sure the developers have considered this. Why have breadcrumbs on a document display window when viewing a folder simply displays a useless “No Selection” placeholder? Because I’m hoping that DEVONthink will replace that placeholder with something useful – for instance, provided a proper plugin, a mindmap or outline view of that directory – a virtual document stored outside of the internal Files.noindex structure. Being able (again, through no DEVONcode, only through code by plugin developers) to create a network of mind maps or outlines linked to specific folders and displaying the content of those folders would approximate the most powerful and useful (read: non-eyecandy) features of a Zoomable User Interface (ZUI). (It appears the Raskin Center, where I usually refer people for demos approximating a ZUI, has been hacked) See the below note on for how we could make the document pane immensely useful when a folder is selected.
-
Path Finder’s tabs look fantastic. I hope to see many or all of these features appear in DEVONthink, but I’ll be patient
-
IIRC, something like a bookmarks bar has been suggested for DEVONthink, but I can’t find the thread. Path Finder’s implementation appears quite excellent – especially if you could bookmark “objects” such as a specific part of a document (like a scroll-to position) or bookmark scripts or Automator workflows stored within the database (the Script menu in DT currently does this very, very well for such things stored outside the database). An idea would be to again rely on my oft-suggested capability for an embedded scripting language within DEVONthink that would allow linking to something like ```
x-devonthink-command://RUNCOMMAND( RECORD( “0a79b080-ddb1-11dd-ad8b-0800200c9a66” ) )/
* the modules (~40% through the video). Essentially, you click on the document title and the information can be displayed/handled in multiple different ways. For some file formats (.eml, .rtf, etc), we'd have a "DEVONthink" view as well as a Quicklook view. If some enterprising chap were to do so, you might have a plugin view for, say, OmniOutliner files, that allows things like conversion to rich/plain text and text copying that the Quicklook view does not currently allow. Also, this seems to me to be a good place to locate a new version of the "Show Info..." panel with more details and support for things like tags and extensible metadata that the current panel simply cannot do effectively. If you need to edit a record's metadata and content at the same time, all you have to do is open a new window. (Have I mentioned before that I would really like to see "collaborative editing" in DTP, so that you can edit two components of a record at the same time without the risk of losing information?) You could also have a module for version control (important for many people, and might streamline the PDF OCRing process). At the folder level, you could see a view via a plugin (mindmapping, outlining) or an icon/list/column view of the contents, or the information for that folder and/or its contents (like a combination of "Database Properties..." and the Info panel), etc. At the smart group level, you could edit the criteria in a larger and friendlier interface that might even incorporate a realtime view of which files are/are not included by the current criteria and does not monopolize the main window.
* Also possible through this multiple-view functionality is the ability to quickly and fluidly define the conditions for class inheritance in records -- I could, say, create a new class for all PDF files that says I want them to always be opened in Skim, and that class would be editable when you open up any PDF file simply by selecting the proper module when viewing that document. This would provide an enormous increase in functionality, fine-grained control of the application's behavior, and could likely rely on a combination of current smart group/saved search technology and user-extensible metadata. The initial class could be created by making a smart group that applies conditions (additional metadata, associated files, a particular way of handling records) to the items that match those conditions. This could also be done (as in other programs like Tinderbox, for instance) through a specific item of metadata like "RecordClass=ARRAY(45b5b7b0-ddbc-11dd-ad8b-0800200c9a66)". A direct link to the applied conditions of the class would be available when viewing that record (as well as when viewing the smart group itself). This would unlock, as I said above, enormous gains in control over the application. For instance, let's say that you're a comic book collector and want all comic books of 20 pages or fewer to be viewed in Quicklook and all those with more than 20 pages to be viewed in SimpleComic. Create a class and you can do that automatically. Similarly, you could open all text files with a certain label in Word/Mellel/whatever, and others in TextEdit, or have a specific text file updated with your word count and other statistics whenever you save any RTFs with "draft" in the name, or when you add a new Address Book contact and import it into your database, any emails you have to or from that person can be moved out of your general email archive and into a folder created for that specific person. When I say enormous, I mean [b]enormous[/b].
* Note also how Path Finder uses drawers -- somewhat similar, I suspect, to how DEVONthink could further improve their drawers. If you want everything in one window, you could simply add a similar widget controlling the module display for the drawers and have metadata/version control/see also/classify or whatever customarily shown when you open the drawer. (Conceivably, you could also switch between case-sensitive and case-insensitive versions of "see also" and "classify") Some people don't like drawers -- my philosophy is that if it means $FEATURE gets implemented sooner rather than later, and with fewer bugs/display glitches, I'm all in favor of drawers.
* Customizable context menus are just plain neat. DEVONthink's contextual menus are generally excellent, and of course far more complex than anything a file manager has to deal with, but I just wanted to say that this feature is @#$%ing sweet.
I know this goes considerably off-topic (and I started babbling about things that are completely separate, like class inheritance and metadata and internal scripting support) but the essential point is still valid, IMHO -- that there are two ways to go about this: bugging DEVONtechnologies to implement many complex features for which they don't necessarily have any experience or enthusiasm, and which in fact may be completely counter to where they want the app to go, or bugging DEVONtechnologies to implement a single (admittedly massive) powerful feature that will allow the users themselves to augment the application's functionality. Everyone benefits from a wider range of functionality for the application, particularly when that functionality is optional and does not bloat the core application.
DEVONtechnologies (or at least Christian) believe that the plugin API would massively increase their support load (due not just to the difficulties of plugin development but also the risks of running code written by someone like me) and time spent doing documentation. My suggestion to counteract that is to make the API completely unsupported and to add an option to DEVONthink -- for instance, something like how iTunes handles switching between multiple databases. Opt+click the icon in the dock to load DEVONthink without loading third-party plugins. The database is and should remain proprietary, so plugins should not have raw access to the database.
I'd cheerfully do the documentation for the API. If nothing else, it'd be something to put in my portfolio.
(What I really want right now is a million bucks so that I could just flat-out [b]pay[/b] DEVONtechnologies to make DEVONthink Pro: Kalisphoenix Special Edition)