Have autoclassify leave *some* control with user? (Replicate

Autoclassify is one of the great, time-saving, powerful features of DT. Hooray.

But I feel very uncomfortable using it for one reason, and in another situation won’t use it.

(1) Won’t use: One very important set of notes I create in DT are my daily work journal notes: a sequential set of notes of meetings (mostly) or decisions etc. I don’t want to get into a religious war, but a lot of people have concluded that a chronological journal where you write down everything that is happening that might be of future use is a valuable way to collect and organize data (e.g., for managers). I very much want to autoclassify my notes on meeting X because it was about project Y and I’d like to find those notes when I’m in my project Y group in DT. But I won’t autoclassify it because it moves the note, taking it out of my journal. I have to manually classify, creating replicants. My problem would be solved if there were a preference (or command) that allowed autoclassify as replicants only, so that an original copy stayed where it was. Then I could be sure it’s in the group where I definitely want it, but still use autoclassify to structure it throughout my network of info.

(2) Uncomfortable using: This has been mentioned by others. Autoclassify leaves no breadcrumbs or other indicators of where it moved things. Usually I trust it, but sometimes I’d like to know where a doc went, to be sure I’m going to be able to reasonably find it later. Please add some sort of feature that allows us to see where a document was autoclassified.

What your “won’t use” scenario seems to be suggesting is a hypothetical autotagging feature for replicating items instead of moving them (as autoclassify does). I can see how that would be instantly useful to me. Autoclassify has never been, e.g. because of its lack of an audit trail like in your “uncomfortable using” suggestion.

Excellent first post; welcome to the forum. :slight_smile:

Have you considered a smart folder for your journal notes? It might work like this:

  • Establish a naming convention that DT can use to find all journal notes. Create a smart folder based on this convention.
  • Use auto-classify to put journal notes with other subject-relevant materials.
  • Smart folder automagically replicates everything into itself, preserving the chronological journal while allowing you to do whatever you want (short of deletion) with individual notes.

Katherine

PS Smart folder? Smart group? Not sure what the official terminology is… thingy that collects files based on specified criteria.

It’s Smart Group in the app and docs, which I prefer. Folder, shmolder. :slight_smile:

Good tip, btw – thanks!

And Katherine’s suggestion would be facilitated by the use of a template (or smart template), with a handy keyboard shortcut. Using a smart template approach you can set the name of the new item based on context, or at least make your naming convention painless.

Templating with a script package is a great feature I’ve been wanting to delve into, just never have the time.

See also Bill’s advice on his approach to note taking. For example:

http://www.devon-technologies.com/scripts/userforum/viewtopic.php?f=3&t=9360&p=43640#p43640

The lookup command (keyboard: select text; hit Command-/) is very useful for finding notes across multiple databases on the fly.

I like jmmason’s ideas about a “breadcrumb” trail for AutoClassify. Maybe something like the History Panel.

As for Replicate with Autoclassify, I can see how that could be useful, but wouldn’t that also duplicate some of the functions of the See Also & Classify Drawer? Just curious, I don’t use replicate extensively, so I may not understand other users’ needs.

Karen

I don’t see how the manual functionality of the latter duplicates the automatic functionality of the former.

With tags implemented as replicants the idea of autotagging as a replicating version of autoclassify is intriguing to me. I don’t want my documents automatically moved but having some of them automatically tagged could have value (depending on the implementation). Since tagging is still a work-in-progress it’s harder to suggest specific details of what an autotagging extension for it might be.