Auto move to next item?

I’ve just integrated my RSS feeds into DTPO and though it works great, there is a little annoyance. I’m used to the behavior in Mail and Cyndicate where if you delete a post or message, the focus moves to the next line above, such that you can easily scan, delete, scan, delete, scan, flag, etc.

In DTPO once I delete a post the focus disappears and I have to click on the next post to read it.

Is there someway to implement this in the future?


(emphasis added)

Possibly in the next beta, at least in Split and Three Panes views

Sorry Scott, it doesn’t work that way here in either split (in a list view) or in 3-pane view.

I select a post, read it, click the delete icon in the tool bar (or press the backspace key), the focus disappears (the focus being the highlight stripe that highlights the entire line).

Nice try, though. :slight_smile:

See my edited reattempt. :slight_smile:

I had complained about more or less the same issue a couple of days ago and got a promising reply:


And Christian’s more recent reply (that I linked to above) is even more promising:

The next beta will select the next item in split & 3-pane views after moving the selection to the trash. The other views will still work like the Finder.

Now we can suggest/debate how post-deleted-item selection/focus should behave in other views even if it means inconsistency with Finder. :slight_smile:

Just another point of view: I hate the behavior of Mail, such that if I delete a message another one is automatically selected. I would prefer that no message be selected after a deletion of a message.

For example, new messages have the status of unread. But that darned focus change after a message has been deleted means that the unwanted (by me) automatic selection erased the unread status of another message, requiring me to manually restore it if that’s not the one I want to look at right now.

When I’m reviewing a set of new messages, I don’t want to go through them in a linear sequence. I want to decide for myself which of the new messages (if any) I want to review after deleting one.

Wasn’t that one of Apple’s most significant achievements in the iPhone, the revolutionary step of allowing the user the freedom to choose a specific voice mail message rather than be forced through a linear sequence?

Personally, most of the time, if I’ve selected and deleted a document in a DEVONthink view, I have no desire to have an adjacent document automatically selected. If I had intended to select multiple documents for deletion, I would have done that in the first place!

Philosophically, that’s the problem I have with ‘keyboarders’, who need an automatic focus set so that they can continue keyboarding. I usually don’t need or want the focus set in that way, and it often causes me extra work to undo the forced selection and any changes in document state that it may have caused.

Most of the time when I’m working in my databases I’m doing things that are more conceptual than mechanical. It’s rare that I want to operate in a linear fashion within a list of documents, for example. I spend much more time thinking than doing repetitive actions, so I find it counterproductive when an application tries to force me into a linear mode.

So there. Just a comment that a rigorous approach to focus setting isn’t necessarily viewed as a good thing by everyone. :slight_smile:

So there indeed, Mr. Contrarian! :slight_smile:

Bill, you raise some significant points regarding this issue, points that are completely valid.

Therefore, how about making the feature a toggle somehow? Toggle “focus moves up or down on deletion” with “focus disappears on deletion”? I know, just what we need, more additions to the Preference panes! :laughing:

However, just as you don’t like to manually restore an email that the focus, by moving to the item adjacent to one that’s just been deleted, has marked “read,” so I don’t like to do the opposite when the focus simply disappears.

I’m pretty sure what you hate, Bill, isn’t so much the auto-selection of another message after deletion but more the side effect of it automatically marking messages as read. :slight_smile:

Easiest workaround is to disable the preview pane and open selected messages in separate windows, if it’s not too much a downgrade in usability. And it’s possible to defer marking selected messages as read using a plugin, e.g. Mail Act-On:

Preview, don’t read
Mail Act-On lets you control when you mark a message read. Set it to immediately, after a delay, or never for better control over items in your inbox.

Or, switch to a MUA with preferable behavior behavior. :astonished:

Just noticed Tod’s reply snuck in while composing this so I’ll followup again later after considering that …

Aside from the aggravation of having to restore the ‘unread’ status of a message in the example case, automatic selection of another massage merely because it is adjacent can impute an undeserved priority. Auto-selection has a message shouting, ‘Look at me!’

Why should I? :slight_smile:

I do a lot of work in my databases, but there are two quite different types of such work. In one mode, I’m acting as a file clerk, adding and organizing stuff. I don’t find that very interesting and try to do as little of that kind of work as will let me get by. The real work, that I do enjoy, is using the database, which is a very different thing indeed.

I’ll concede that linear, repetitive procedures simplify work in that file clerk mode, although I also make as much use as possible of the artificial intelligence features in DEVONthink, such as Classify, Auto Group, etc.

But when I’m using the database to explore information and think about it, I don’t want to be forced into irrelevant, linear side trails. That’s why I mentioned Apple’s genius in breaking the traditional mode of handling voice mail messages, which had always been linear. To me, the genius of DEVONthink (thank you, Christian and Eric) is the set of tools and assistants that let me explore information content of my databases in ways that are much more powerful and non-linear than the traditional approaches, which have often depended on simplistic and fundamentally limited tools such as keywords.

It’s at the stage of using the database that features that may have been useful in the clerical mode can become irrelevant or irritating. :slight_smile:

EDIT: Bill, I don’t notice your latest reply until after submitting this … I’m struggling to catch up. :slight_smile:

Considering that, have you tried closing Mail’s preview pane and opening new messages in separate windows?

Except when it adversely changes the document state (which I certainly agree can be heavily annoying) I don’t see how a forced selection would be any worse than a non-selection, while in some cases it would be preferable. A non-selection always requires manually choosing the next selection; an auto-selection only sometimes does. An auto-selection often provides visual feedback that makes it easier/quicker to choose the next action. A non-selection requires more attention, e.g. a mental delay of “focus limbo” I’ve described in other threads.

I can see how auto-selection might be a distraction to that process because you’re accustomed to making actions that won’t use it, even if it requires making non-linear selections “out of” a non-selections.

I agree, however …

Unless they adversely affect document state (which eventually deserves more discussion) I’m able to take advantage of auto-selections in both linear and non-linear processing. Specifically in DEVONthink, forced non-selection is far more frequently frustrating to me than forced selection would be if implemented a certain way.

Backtracking a bit …

Tod’s original suggestion was in the context of RSS usage, which is frequently a mostly linear process for many people. It’s a “mode” of DTP(O) where post-delete auto-selection would improve usability. And at least for me there are other usage contexts/modes where that’s applicable, too.

If the choice was between forced non-selection or forced auto-selection I’d likely prefer the latter, for reasons I tried explaining in my previous reply. Implemented only in Three Panes and Split views, as Christian said would be done in the next beta, is a compromise. However, it’s in those views where auto-selection causing unwanted preview and document states changes becomes an issue, like in Mail. For RSS usage it’s probably minor but in other contexts I can imagine it being distracting and irritating. I don’t have any suggestions right now for elegantly handling that.

Considering this:

I like the idea “toggling” selection behavior, with the ability to easily do it (somehow) on-the-fly rather than fussing with Preferences being conveniently preferable when switching contexts. That could partly help with the preview and document state changes issues previously mentioned, too. But maybe this is too awkward and obscure?

Purely for handling the auto/non-selection issue, would using a modifier key to adjust the behavior when deleting be acceptable? I could adapt to typing Option-Delete instead of just Delete in contexts where I want auto-selection to kick in, probably quicker than having to remember to toggle a behavior preference and somehow know its current status. Yeah, I’m sure I’d be satisfied using a modifier prefix for this.

Handling unwanted previewing and state changing with auto-selection is trickier. Somehow adding a delay without a preference could be okay. Or, maybe just learning to adjust to this issue is good enough?

PS: I’m “caught-up” enough here now. :slight_smile: