Elsewhere, I wrote: “Also, DOpus advertises spring-loaded folders in the folder tree view, but this isn’t really true. I have a dozen favorites folders that appear in the tree view. When I drag a file over one, nothing happens. There’s no spring-loading. It’s true that this happens for non-favorites folders, but why doesn’t it happen for favorites folders? It should all work the same–consistently. Also, it doesn’t make sense to have (partial) spring-loaded folders in the folder tree view, but no spring-loading of folders in the actual lister views to the right of it. It’s not just that Mac OS does this that’s relevant; it’s good design and saves a lot of time.”
You replied: “[F]avorites in the folder tree cannot be expanded at all, by design. The favorites branch of the tree is intended to be a fixed list of shortcuts that stays at the top of the tree, so the list is always in the same place and structure for you to pick a favorite from. If it expanded, it’d become a mess and no more use than the main parts of the tree. As you navigate to another folder from a favorite (e.g. the child of a favorite), the tree jumps to the real location of that folder. So the spring-loaded option doesn’t apply there as those nodes in the tree don’t expand. I guess they could just when doing drag & drop, but it’s not something anyone else has asked for so far.”
Yes, I want to bitterly complain! (At least I’m consistent–right?)
I commend you for trying to implement spring-loaded folders. Let’s step back for a moment. What’s the problem that we’re trying to solve with spring-loaded folders? It’s to drag and drop files or folders from one place to a specific folder, buried somewhere inside a higher-level folder, as efficiently as possible. Do you agree? (If not, why bother with spring-loaded folders at all?)
If we agree on that goal, then the question is: What’s the best way to do that?
One possibility is to create a favorite folder for every possible folder that one would want to typically perform the drag-and-drop operation to. That gets unwieldy, though, if you have dozens of such folders and need to scroll the folder tree view. (Principle: minimize scrolling.) It would also put a tremendous burden on the user to keep adding favorite folders. And no user wants to deal with a long list. (Imagine how long scrolling and finding the right folder would take if you have to deal with dozens of them–every single time! Keep in mind the limits of human cognition: we can only store between five and nine items in short-term memory, on average; any more, and we become inefficient as the cognitive burden increases.)
Another possibility is to open a two-pane lister, navigate to the source folder in the left pane, navigate to the destination folder in the right pane, and then perform the drag and drop operation. (But that would be highly time-consuming and thus inefficient.)
A third possibility is to drag files or folders from a lister to the folder tree view (not including favorites folders, where spring loading doesn’t work), which will expand as you drag. But this requires a lot of scrolling and mouse movement.
If using the UI, the most efficient operation that I can think of, borrowing shamelessly from the Mac OS Finder, is to use spring-loaded folders as implemented by Apple. I think that your implementation of spring-loaded folders in DOpus is both partial and inconsistent.
I understand that you want to use favorites folders as fixed “anchors.” But 1 is inefficient. And design is all about figuring out what the user is trying to do and enabling him or her to do it as efficiently and easily as possible, which is what a full-blown implementation of 4 would accomplish.
You, yourself, hit upon the solution when you said: “I guess the [folders] could just [temporarily expand when] doing drag & drop, but it’s not something anyone else has asked for so far.” This is the way that the Finder works in Mac OS X, and it’s very efficient.
The problem with your partial implementation of spring-loaded folders is that because it only works in the folder tree view, not including favorites folders, and not including listers, not only is it an incomplete feature, but it is an inconsistent feature. It’s disorienting to the user to be able to drag-and-drop and have spring loading occur only in the first case, but not in the latter two.
The idea with spring-loaded folders is not for the folder tree view to move around and become unwieldy to work with as it expands and contracts. That would be a usability nightmare. Instead, please take a close look at how Mac OS X Finder works. Apple did things right.
If you implement spring-loaded folders correctly, and apply it consistently across the folder tree view (including favorites folders) and in listers, you’ll nail this feature and it will greatly benefit users. In listers, when we drag files or folders over a sub-folder, that folder should expand (reveal sub-folders and files within it) to enable us to hover over another sub-folder, which, in turn, should also expand, and so on, until we reach the target folder that we want and release the mouse over to drop the files into that folder, at which point the lister should show the folder that we started with.
The expansion and contraction would only occur when dragging the cursor (with selected files or folders) over a folder (or nested sub-folder), and the expansion and contraction would be recursive. The moment that a drop occurred, the UI would show the exact same view as right before the user began the drag-and-drop operation.
Fellow users: Am I right?
Leo, also, every time that you want to add or change features, before you write so much as a semicolon, first ask yourself: What goal does the user want to accomplish, and how should DOpus work to enable them to accomplish it as easily and efficiently as possible, far superior to how they could do it in File Explorer, or using any other file management app? Please make your design work about achieving user goals, not just adding features. Design is teleological. What are the user’s goals? What’s the workflow? Minimize the latter.