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.
1 Like
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.
Jim,
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).
Keith
1 Like
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 Like
+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)
1 Like
Beta 3 will revise this, the current group will be used in case of main windows.
3 Likes