Regarding a Tabbed Finder
Andy Budd recently posted a mockup of a tabbed Mac OS X Finder window, a feature that has been suggested a number of times in various Mac forums. I really question the value of this for the following reasons.
- Files and folders are not browser content
- The spring-loaded Sidebar already provides much of the functionality
How users interact with their local files is rather different from how web pages can be and are used. Web page content cannot (99% of the time) be directly manipulated while graphical file managers depend heavily on such functionality. One of the reasons tabs work in browsers is that individual pages (even those from one site) are pretty much isolated — I don’t know of any situations in which you can move an element in one browser tab to another (unless it is text). Again, the ability to move objects between views is a key part of graphical file managers. For this reason, I suggested spring-loading the tabs, but that brings me to my next point…
For moving and copying objects from one location to another, the 10.3 Sidebar is pretty flexible. You can either drill down in the existing window, or use the Command key to open a Sidebar location in another window.
The sole new benefit of a tabbed Finder that I can think of is that you could contain two windows in one. But again, in order to make tabs function as more than just visual information, you would basically have to replicate what the Sidebar already offers.
I have to agree that I don’t think this is such a great idea… just another example interface de jour? If you encapsulate folder views in a single window, you lose the benefit of Expose, and Spring Loaded folders, in moving files around.
On the issue of Spring Loaded Sidebar vs Tabs, of course the Sidebar only holds predetermined destinations, as opposed to a dynamic list of open, or recently accessed folders, and there’s nothing that really achieves that, at the moment, at least not as a ‘browsable’ mechanism.
Each window’s history buttons are one, but too unpredictable, and restricted to the context of each window, and the ‘Go’ menu’s ‘Recent Folders’ item, is another, which generally ‘destroys’ the current Finder location, unless you go to the effort of creating another window, for the express reason of opening a previous folder, which inhibits it’s efficient use.
One, simplistic option might be a Cmd-Tab-like palette that shows the ‘Recent Folders’ list, and opens the appropriate window, when selected, but, while being fairly direct, it also wouldn’t offer a ‘browsable’ interface.
Actually, the usefulness of tabs in the Finder would be quite high if the tabs themselves were spring-loaded. Then you could drag stuff in Tab A up to Tab B, the view would switch to Tab B within a half-second (or whatever delay you’ve set the Finder to), and there you go. I could envision that becoming quite useful.
i think it would be a usefull improvement. i have to work with about 7 - 10 windows open at one time. all of them are needed from time to time for opening, transfering etc.
tabbed finder browsing would be perfect for me, because the other two alternatives aren`t perfect for me:
-spring loaded (sidebar) windows just let me jumping too long through the paths.
-expose is nice, but it takes also too long too find the right window out of 10 open windows. you have to roll
over all small expose icons in order to see the window names and finally get yours.
this all isn`t funny, when you work with many windows open, and you got little time.
so i dont understand, why discussing about it is not the idea of expose. let the user
choose, what makes sense to him, and if you are a fan of the current expose (future
will bring better solutions, yet its just beta for me) , than
there of course should be a function, that disables tabbed finder browsing, so you
dont have to use it.