The destination for a Capture operation on a Bookmark (using the contextual menu or Tools/Capture) seems to be the Inbox of the database in which the Bookmark is located, not the current Group. Is this intentional? DT2 captured to the group containing the bookmark.
Actually, all captures from that mechanism go to the Inbox of the current database.
I believe it’s due to…
- That is the essential use of an Inbox, to contain newly unfiled data.
- Smart rules would allow processing the Inbox of a databases.
@cgrunenberg would have to comment further on this, and whether the previous behavior would be reinstated.
Thanks - regarding your points:
- I don’t think of the capture of an already-filed item as being ‘newly unfiled data’. The filing decision having already been made for the first item, I think it is reasonable for the user to expect the capture to appear in the same place.
- I can’t think of any smart rule that would automatically move a capture from the inbox to the group in which the target was located, except in specialised cases (e.g. to a group with the sole purpose of holding captures).
I used the previous behavior in my financial database (which I am not using in DT3), so I understand the habit, but as I said, Criss would have to comment further on these things.
I don’t code 'em. I just report and support 'em
The change is intentional to make capturing more consistent. The destination is now the same no matter whether an item is viewed in a preview pane or in its own window. And like any new item smart rules could post-process it.
Just want to 2nd what Keith wrote above, especially this:
I don’t think of the capture of an already-filed item as being ‘newly unfiled data’. The filing decision having already been made for the first item, I think it is reasonable for the user to expect the capture to appear in the same place.
I can’t really agree that the new behavior makes capture more consistent; it seems inconsistent to me to put the capture of bookmarked content into another location. However, if a rule could be created to automatically refile captured content, then I guess it wouldn’t matter.
Could the DEVONthink developers provide an example of how to define such a rule?
+1 from my perspective for making the capture inconsistent, as well. This is highly annoying because while being consistent from a general perspective it breaks the current context I am working in. And if in doubt I would always put context over consistency. Context defines human cognition and actions and should hence be accordingly valued by our tools (speaking from expertise and not only opinion here ;-))
Apart from that it breaks one of the foundational rules for good UX: the system should always make the result of an action obvious – and in most cases also immediately actionable – to the user (and not stow it away somewhere where I need to dig it up again)
Beta 3 will revise this, the current group will be used in case of main windows.