Of all the built-in Mac OS X applications I know, Finder is probably the one that comes most often under attack, closely followed by DVD Player and Address Book. For some users, the Finder is asinine, full of annoying bugs, unworthy of its name while some others praise it as the foundation of the Mac OS X experience, the easy entry door to a world of computing fun.
Looking objectively at the Finder, it sure has its share of bugs, some strange, some annoying and some rather theoretical. In fact, many of these bugs go beyond the scope of the Finder itself and happen when Finder interacts with its interface cousins, such as the Dock and menu bar extras, making pointing out the guilty party a lot harder.
The question, of course, is whether the Finder is fundamentally good enough at what it does and whether it should, as some users claim, be replaced or re-written from scratch. Some Mac users would like to see it totally replaced by a Spotlight-driven interface, where files would be tagged and categorized in “Smart Folders” that would be little more than SQL queries in disguise. Others believe the current Finder is just in need of a good bug-fix release but has plenty of power left. Some argue the current folder/file analogy has run its course and would like icons and windows to better adapt to the contents of a directory — the long rumored piles interface that never made an appearance but drew a lot of ink back in the days.
Radically changing the structure of a filesystem and replacing it by a query-driven one is not without challenges. For example, how do you adapt to the needs of UNIX applications that still want to see a “/tmp” or “~” in a filesystem where everything is nothing but a big pile of files with a side of SQL? Write a translator? Doable, maybe, but definitely difficult and slow. Mixing Smart folders with real folders is what the Finder already does and few people seem to have entirely switched to dynamic groups for their daily work. The Finder could of course add UNIX-like options like regular expressions but a dash of AppleScript already takes care of the user’s most pressing needs (or good old Terminal, of course).
All in all, as you can see, I would lean towards the simple “scrub and fix the bugs” path which, admittedly, is easier said than done. The Finder as it is has to appeal to the geekiest of users as well as to the least advanced, which gives it an impossible task, the one to please everyone. In that, it is necessarily stuck in a middle point that remains very hard to navigate.
Of course, I would like to see a dramatically different Finder come up one day, one making use of visual effects for real, one that would present a radically different way of browsing files. I do not believe however the technologies and demands of today make it very easy for the Finder team to find an easy and quick way out. Am I wrong?
"Piles" not in Finder...
..but I consider that Aperture finally used the "Piles" metaphor organizing the photographs in stacks (http://www.apple.com/aperture/compare)
More information on piles
Although I'll have to Google it in the morning, if anyone has any more substantial information on piles, I'm curious to read about them. The MacRumors link makes it sounds like a giant simplified waste of time. The Finder may be flawed, but I can certainly find things far quicker in its current structure than in any comparable actual desktop pile I may have.
"Piles" not in Finder...
Hi!
That is indeed a very interesting approach to the question, thanks for reminding us of it!
FJ
More information on piles
Hi!
Information about these rumored "piles" is quite hard to come by actually and that Mac Rumors link was the best summary I could find — then, there is no way to know how close it was to an existing Apple feature, if such a feature was ever in the works. It did however attract many comments.
I agree that the Finder does allow for the easy retrieval of information, especially compared to traditional desk management systems!
FJ
Hidden Files...
Although I continue to hear about bugs, no one is specific. I've yet to encounter anything that even looked like a bug. That being said...I would like to turn on and off specific files/directories that are hidden. Currently, I have to do backflips and even then it really doesn't work as expected (bug?!?!?). I just want to be able to look at the hidden files/directories and then Get Info on them and specifically state to hide or not to hide. Not all files/directories interest me but some do and I should have far more control over them.
As have yet the Finder is more than adequate to get the job done at least it doesn't make me wait until next year to look at files. Unlike some OS's.
Finder Bugs
A lot of the complaints about the X Finder come from old time Mac users. It does stuff like not remembering window and icon positions, which was a key part of the Mac experience before X. There is a definite lack of consistency in the X Finder. You never know where a window will appear when opened, nor where the items inside it will appear. Also, it was only in Tiger (10.4, several years after the first major release of X) that the Finder would update windows (folders) when things had changed right away. For instance, to download a file to a folder window that is open, and it not show up until something else forced it to was unintuitive and wrong.
The 10.4 Finder is much better, but for some reason, it's still not as good as the 'classic' Finder was for these reasons. If Apple made it that consistent and reliable, then the only debate would be the interface.
Replace Finder.app
Finder needs to be replaced in the biggest way! Just rip the whole thing out and start over from scratch. Preferably using the fastest technique being either carbon or cocoa. It needs to have much better threading, auto-refresh, greatly improved network connectivity and browsing. I like the sidebar and toolbar. I like the spring loaded folders but I hate the spinning beach ball and I hate when I have to restart it all the time.
Adding better Spotlight support that runs fast and offers even more ways to search and work with your files along with tagging, etc. Would help a whole lot. Finder has been improved a lot over the last several releases and Tiger is where it finally became bearable but it still has a ton of problems. So much so, I am merely waiting for the next release of PathFinder and I will drop cold hard cash down for the replacement.
Finder bugs
Wow. I'd like some of what you're smoking if you think the Finder can be fixed without major UI changes.
The people I've encountered who think the Finder is wonderful actually use the command line to navigate the filesystem. This includes ex-NeXT engineers, who always used the command line to navigate. It's why they never had a decent file navigator.
(Sacrilige, I know, but have you ever used the NeXT File Browser or GWorkspace? It's great for browsing deep source trees. And nothing else.)
Please read:
http://arstechnica.com/articles/paedia/finder.ars/1
Hidden Files...
Are you kidding? John Gruber's been banging the drum (http://daringfireball.net/2002/11/that_finder_thing) on the Finder's usability problems for years.
Here's a specific bug that rankles me every day. The sidebar in every window where you can stick frequently used folders and the like is resizable. It can snap to icon width (which I like), but some new windows will not be snapped to that width, and if a new icon appears in the sidebar, it doesn't stay snapped.
It oughta go while the going's good...
One word: infrastructure. Or: It's not about working with files and folders. It's about how you manage information, right from the ground up.
And now for the long version; hold your breath...
That the Finder has become such a mess of bolted-on features and design-by-committee ideas points to a deeper malaise: not only has the amount of information it has to manage grown greatly, but the ways in which users want and need to interact with that information have multiplied and diverged too.
The current Finder is monolithic, self-contained, non-extensible, and it's still fundamentally bound to the filesystem-as-filing-cabinet metaphor, with all the limitations and lack of flexibility that such tight coupling inevitably brings. Its core design is rooted in a 128KB, single-user, non-networked, floppy disk-based world. Sure you can keep layering over this core design - never was a problem that couldn't be 'fixed' with another level of abstraction - but this approach is inevitably one of diminishing returns, and it's struggling to keep up.
Therefore, at some point somebody really needs to say enough is enough, take all the lessons learnt, sit down and rethink from scratch what's needed in a central information manager in context of the modern computing environment and 21st-century users' needs. Because two things are clear: 1. a "one size fits all" interface is no longer sufficient for modern and future users' needs, and 2. staying tightly coupled to the file system and fifty year-old file/folder metaphors in a world that's aready moving beyond this narrow point-of-view is the fast track to obsolescence. The low-level OS- and network-level technologies are rapidly expanding and evolving, but it's the high-level applications like Finder that are responsible for delivering these to the user - and they seriously needs to get the finger out to keep up.
This is deep, conceptually heavy stuff that lies well beneath the user interface where it's not obvious, so doesn't get nearly as much attention as the glossy icons and whizzy 3D effects that the chattering classes, who wouldn't know form from function, like to focus on. Yet it's absolutely key to everything else that goes on, because the slickest user interface in the world isn't worth squat if the major underpinnings are worthless.
But this still only half its woes: today's Finder plays very poorly with others at the user level as well. Look at Mail, at iTunes, iPhoto, etc. and you see the same pattern emerging over and over: each of these programs is implementing its own information management systems. And what does the Finder bring to all this? Zilch.
Each time Apple or a third-party bring out another of these applications, the Finder becomes a little more irrelevant. XCode, Delicious Library; the list goes on. Sure, the information formats are all different, but this is superficial: underneath the surface there are powerful conceptual similarities in how each manages this information. This is right approach to begin with: start small and evolve naturally so that good ideas are nurtured and further explored, while bad ones are kept from entering the wild where they'd be impossible to exterminate later.
After a while though, it makes strong economic sense to start factoring out the mature, common elements into shareable frameworks, reducing duplication of effort in existing projects and making it quicker and easier for new projects to get up to speed. Once you have all these applications sharing a common information management model, you're no longer limited to them being the sole deliverers of those management services. Some of those apps might even consider turning over the basic organisational gruntwork to a third-party completely. Like, say, a centralised, general-purpose information manager.
And once you have that, you're no longer restricted to a top-level organisation scheme based on something as crude and insignificant as datatype; you can browse, cross-reference, categorise and view them according to whatever rules suit you best. Allow users to plug in multiple viewers to this system, and you've got one hell of a system to manage information pulled from any number of sources in any way you like.
So this is what users currently have: a whole lot of information, spread across all manner of storage systems - local filesystems, object databases, metadata, internet hosts, remote applications - and a whole bunch of wildly disparate tools that barely even speak to one another for interacting with this data. Twenty years ago it wasn't even an issue; look at where we are today and try projecting the current state of affairs twenty years into the future. Finder is, by honored position, Mac OS's flagship representative to its users. Question is: with everyone else moving on, is it still sufficiently qualified for the task?
Apple can bandage the Finder if they want and allow it to proceed on its long slow decline into irrelevance. Or they can bite the bullet and meet the rush face-on by establishing the foundation to a modular, extensible, flexible, high-level information management system that will not only replace the Finder, but also consolidate a whole heap of other organisational tasks with plenty of room to grow.
Personally my money's with the rumour-mill: that they'll simply replace the existing Finder with a Spotlight-driven version of the same. I could imagine such a straightforward "Finder 2" incorporating some duties from other apps in the process but which probably won't establish a truly open, componentised architecture that's completely extensible at both top and bottom. Not so much because they couldn't (though it'd certainly be more work), but because they've still got that 'Apple Knows Best' attitude that sometimes works so brilliantly for its users yet other times is a complete PITA when it doesn't.
But I guess we'll find out eventually... and hey, if Apple fail to make the most of the opportunity then I expect someone else will; e.g. I hear there's a company near Seattle that sometimes writes OSes too...;)
Cheers,
has
Finder is an application - it is not the filesystem!
Radically changing the structure of a filesystem and replacing it by a query-driven one is not without challenges. For example, how do you adapt to the needs of UNIX applications that still want to see a "/tmp" or "~" in a filesystem where everything is nothing but a big pile of files with a side of SQL?
Huh? I thought the discussion was about changing or replacing Finder. Finder is an application. It sits on top of the lower-level Unix stuff. There is no need to change the filesystem in order to change Finder.
The Finder definitely needs work.
But what's wrong with Address Book?
It oughta go while the going's good...
While I'm certainly not opposed to the notion of a radically new interface, provided it works as well as advertised, if not better, I don't entirely see the value of dismisisng the office analogy entirely. It's outdated to some degree, but it's useful in providing an abstract comparison for most users and it's one that I think will be incredibly hard to overcome. What would be a better analogy? Would it not also ultimately succumb to being outdated? Files are just collections of code and short of going to a rather long-winded atomic/molecular kind of analogy, I see little use in necessarily foregoings its use, at least for the time being.
I don't think there's any question that any successive upgrades to OS X, at least in the short term (such as with Leopard), won't be seeing any radical departures from the current Finder structure. I'm perfectly fine with the Finder if they'd just clean it up even in its current state, especially if they addressed its threading issues (networking! Fix it!) and some of the more egregious UI issues. Moreover, I wouldn't hold my breath on Microsoft doing anything radical either. Essential as these applications are, they're free and most consumers don't even view them as distinct applications, but as simply being "Windows" or "OS X".
All that said, if you have any resources or links that you feel are worth mentioning to add some more specificity to your argument, I'm all ears. Of course, anyone unfamiliar with Ars' notorious Siracusa tirades on the Finder would be well served to do a quick Google search to that effect.
It oughta go while the going's good...
"While I'm certainly not opposed to the notion of a radically new interface"
To reiterate one of my points: it's more than just an interface issue. It's also a question of: what should it be an interfaceto? Interface is just the icing on the cake, yet attracts most of the attention often at the expense of less visible but much more significant issues.
"Files are just collections of code and short of going to a rather long-winded atomic/molecular kind of analogy"
Storage format is just an implementation detail, and the least important part of the puzzle. Again, focussing on obvious but relatively insignificant concrete details misses the larger, abstract picture. A lot of folk are thinking of Finder in terms of a file manager. My point is that they need to step back and consider it in more general terms:
What's a file manager? A tool to manage files. What's a file? A piece of information. Ergo, a file manager is an information manager; however, not every bit of information we deal with today is stored as a file.
Even within the limited file/folder metaphor it's possible to do a heck of a lot more than Finder does. Unix already decouples interface from underlying representation to some extent, treating '/' as the root to a more general-purpose namespace: every object in this namespace looks like a file (i.e. conforms to a standard interface) without necessarily being a conventional file. While Plan 9 takes this basic idea and runs like crazy with it.
i.e. Lesson 1: Decouple. Decouple. Decouple. And not just at the top level (UI), but right down at the bottom as well. Data stored in a traditional HFS? No problem. In a relational DB? No problem. Transmitted via custom RPC protocol from a data vault on the other side of the world? No problem. Just schlunk in the appropriate adapter, and away you go.
"I don't entirely see the value of dismisisng the office analogy entirely. It's outdated to some degree, but it's useful in providing an abstract comparison for most users and it's one that I think will be incredibly hard to overcome."
Indeed, and I make no such argument. Using hierarchical tree models to present objects to clients will always have its uses. It's not the only form representation that may be useful, however. Nor does it require that the underlying data itself be stored in a tree-shaped model.
Here's an interesting thing: take a file path and apply s/\//\n/g. Now it looks a whole lot like a list of search keywords. (Took me years of art school training to learn how to switch perception like that.)
"What would be a better analogy? Would it not also ultimately succumb to being outdated?"
Death and taxes are a given - deal with it.
Don't box the whole design into that corner in the first place. Going with a component-centric system where storage, filtering and presentation are all loosely coupled provides a lot of room for variety and growth. Obviously the core components - the central query/search engine and the adaptor interfaces below and above that - have to be fairly durable to provide a stable foundation for everything else to build on. But the rest can come and go more or less as they please, so it won't matter if one particular viewer - one based on a filing cabinet metaphor, say - becomes "obsolete", because it can go away without impacting on the rest of the system.
i.e. Lesson 2: Be adaptable. Flexible. Don't get precious, or start developing delusions as to what is The One True Way. Where a filing cabinet metaphor is useful (e.g. for XCode project files), allow the user to use that. Where a Lifestreams model is useful (personal organisation), allow the user to use that. Where an association frequency map makes sense, allow the user to use that.
Certainly, Apple are not without experience in the component-centric architecture area (e.g. OpenDoc).
Steal liberally; I'm willing to bet, for example, that there's some good ideas about dealing with distributed system interactions kicking around in OpenCroquet, once you get past the ridiculous and distracting 3D UI. There might be a few ideas could be nicked from something like Placeless Objects, if indeed it hasn't already been completely strip-mined by VTwin/Spotlight. Jef Raskin's work on keyboard-driven and visual-zooming interfaces.
The real trick, of course, is knowing when Less is More: i.e. look around to see what such a system might conceivably be used for, then create the basic open-ended architecture needed to enable this, and let everyone else do the hard work of enriching it; reimplementing existing paradigms, trying new ideas, creating new adaptors, occasionally flubbing it, and so on.
"All that said, if you have any resources or links that you feel are worth mentioning to add some more specificity to your argument, I'm all ears."
I've name-dropped a few items off the top of my head by way of background reading. You'll have to open a fresh web browser, jump to , type in and hit the Search button for each of those names one at a time, but it ought to get the job done.
There was a time when the Finder desktop represented the hub of every Mac system. What would make a real impact now isn't a better Finder, it's a spanking fresh hub. Give folk less - particularly those who've never considered that there might be other possibilities - and I expect they'll continue to get by in some shape or form, but it'll be a valuable opportunity wasted, especially one like this that doesn't come around every day.
Cheers,
has
Just Bring Back Tabbed Windows
In OS9 whatever I was working on I'd just open the windows, drag them to the bottom, and there I'd have my files/folders all at hand. For frequently used files I'd just make a folder(in the apple menu often) and drag aliases into it, then make that as a tabbed window too. Possibly, tabbed Windows would be even better in OS X because you could have both the tabbed window and the actual window, so the tabbed window wouldn't be affected by other actions. (ok you probably couldn't have pane-view).
5 years on, I haven't found anything that comes close to this system in terms of speed, efficiency and convenience. The dock doesn't display names, and is full of running apps anyway, the side bar is regularly hidden, and all the commercial alternatives are simply far too complicated.
Think of the extra power if you could drag smart folder display to a tabbed window at the bottom. Come on Apple bring this back.
Why wouldn't SQL be possible?
The Finder itself is nothing more than a window engine, in my view - It's Aqua that handles the interface, and Darwin (UNIX) that handles the stuff going on underneath. It's a go-between for the two, feeding information passed from the UNIX Core, which handles file and directory placement, to Aqua where we see it on screen. It even maintains its own DB (look for DB files when you burn a disc in toast, or upload onto an anti-mac server. BTW, I couldn't think of a better term for the types of server they are - when taking off the extension changes the file to a Unix-executable file, it's obvious it doesn't handle Mac files well.)
Whether we'd benefit from a SQL-based finder system, however, is another story. Some people will never take advantage of it, and some companies will even try to prevent it. (Before you say they won't, I already know a handful that would do it in a heartbeat, if possible - all with justifiable reasons.)
Furthermore, making it based on something accessable, such as SQL, may invite unwanted problems from people smart enough to do damage to a machine.
Just some thoughts though - it's a cool idea, and I think it's doable, but I wonder how bad the consequences would be.
Just Bring Back Tabbed Windows
5 years on, I haven't found anything that comes close to this system in terms of speed, efficiency and convenience.
Hmmmm.....nteresting. I'm going on almost 12 years of using the Workspace Manager (ala NeXT) and now the Mac OS X Finder. Sure I'd like to see a few improvements, but basically I'd say the same thing. I haven't found anything that comes close to this system (NeXT/Mac OS X Finder) in terms of speed, efficiency and convenience. I could never see a return to OS 9.
It oughta go while the going's good...
The parent post outlines that Apple's already 're-solved' the problem in several specific apps - think iPhoto, iTunes, and as he mentions, Delicious Library - the key to all of these is managing very large collections of files, which is where I think the 'desktop' metaphor breaks down.
(In fact, if you keep the 'Office' metaphor, office's also have problems managing large collections of files, especially when they need to be used by people on/off site - so perhaps the history of how offices have managed this could help in thinking of an interface).
My hunch is that the spatial metaphor of the classic desktop / Finder only works for about the same amount of data we can handle in that way in the real world - most people can manage a small CD collection with no ordering, but after a point they need some sort of system. I only need to think about my setup here, where I have some books close on hand, but a library behind the chair.
Like the other post, I can see there's some core behaviour Apple should be moving down into a framework (iTunes and Spotlight don't even use the same metadata - and I can't add my own 'tags' - i.e. metadata - onto iTunes, so that I can search for artists by City, Band Members, etc - which is what he means by extensible. Why can't I then use the same search outside iTunes and click on the file to play it (in iTunes)?
Now we all know the file metadata stuff is now in there at the OS level - the question is whether Apple are going to make it easy to get at.
There's definitely some mileage in the comments re. XCode (and the MS Office Project Centre) - these are interfaces that have looked at the problem of 'project management' - i.e. grouping different file types into a project rather than by type (as iPhoto and iTunes do).
Finder bugs
Hi there!
Hmm... Looking around me, the only smokable element I see is my carpet but it looks fairly intact... ;^)
I confess to never having used the NeXT File Browser or, for that matter, a NeXT system, despite my having read much about them. The Mac OS X Finder Column View does have a development edge and is absolutely terrific to browse deeply nested files and folders, such as these being found in bundles. I do use the Finder on a regular basis to navigate the file system (more than the Terminal), although it is true the abundance of shortcut systems does speak for itself in some areas.
FJ
Finder is an application - it is not the filesystem!
Hi there!
Thank you for pointing that slip out. Indeed, I meant the "filesystem" as in the structural organization of files and not in the technical meaning of the word. Replacing the Finder does not, as you rightly point out, mean replacing the HFS+ filesystem.
FJ
The Finder definitely needs work.
Hi!
Some people have criticized Address book for its using a modal interface and being unclear on how it is toggled (with fields being editable in one mode but not the other and fields staying editable in both). I personally love Address Book and, while I wish it had some additional features, do not see it as "lacking" in any way. My goal here was to pass along feelings I have heard voiced by fellow users.
FJ
Finder is an application - it is not the filesystem!
Indeed, I meant the "filesystem" as in the structural organization of files and not in the technical meaning of the word.
Sorry, but I'm not sure you understand yet. The view presented by Finder (or any other application) is not necessarily a view of the "reality" of how files are organized. It is instead a "fiction" that presents something which is useful for the user in the course of his/her tasks. There is no need whatsoever for the view presented by the Finder to have a one-to-one correspondence with the actual files (or database entries).
Finder is an application - it is not the filesystem!
Hi!
Yes, I entirely agree with you -- and the very fact Finder can be replaced by another application proves this point. There are however some applications out there that still interact with the Finder at some level to access their files and would not find their way around a Mac on which Finder isn't running or on which it is not available through some mechanism. iTunes, for example, relies on the Finder to show the files corresponding to songs and, if the application is not available, just drops the call. Until all applications can abstract their requests and ask the system to "display" some "file" without needing to specify a path or talking to a specific application, dramatically changing the Finder would, I believe, be complex.
FJ
It oughta go while the going's good...
First, I want to say "this" is a topic I've been particularly passionate about for the past year or so. Much of what's already been written here reminds me of my own thoughts and writings. Good stuff! Where have all you smart folks been hiding your ideas/writings? If anyone's interested, I'd enjoy discussing any of this in more length/depth beyond weblog entries here although I'm not sure where to recommend.... any suggestions? For now I'll start by jumping in here (once again forgiving the frustrating lack of comment previewing) ...
the key to all of these is managing very large collections of files, which is where I think the 'desktop' metaphor breaks down.
Yep, the traditional "office-like" desktop metaphor isn't scaling well for large and growing collections of files, possibly with different relationships between them beyond their simple hierarchical file/folder organization (imposed by the filesystem, often managed with Finder).
My hunch is that the spatial metaphor of the classic desktop / Finder only works for about the same amount of data we can handle in that way in the real world - most people can manage a small CD collection with no ordering, but after a point they need some sort of system. I only need to think about my setup here, where I have some books close on hand, but a library behind the chair.
Like the few "random" CDs/DVDs on my desk vs. the larger collection organized in racks. Etc.
I never worked much with the Classic Mac OS so its Finder spatial metaphor is more conceptual than experiential.
Something I've struggled with in OS X (Finder) are ways to organize collections of files with "persistent views" that provide both short and long term visual contexts. For short term context, I've tried grouping/labeling small numbers of files/folder on the Desktop, glancing at them as a quick reminder of "related stuff". When the Desktop gets too cluttered to be useful that way it forces a subset of files into long term storage, without retaining the same "view" of them. Rinse and repeat. Trying to keep even smaller numbers of files/folders organized with relevant iconic views in windows quickly becomes an exercise in futility.
So, I typically store a lot more of that kind of data directly in DEVONthink Pro, which has become my "secondary Finder" to a great extent. There's more to say about DTP's strengths and weaknesses used that way but I want to keep this post short(er).
Implementation limitations aside, I'll add that I'm particularly fond of the iTunes/iPhoto metaphor of the library representing the entire physical storage container for content (regardless of how or where data is actually stored), with playlists/albums as virtual groups for organizing content without copying/moving/deleting the physical data. I think that abstraction of storage from organization is one of the key points in discussions like this. That's what the current Finder *doesn't* allow, except (barely) using aliases and smart folder. Personally, I want a "meta-Finder" that's free from the tedious file/folder management that's so strictly associated with the hierarchical filesystem.
Gmail is also worth mentioning, for its successful pioneering effort of bringing a large scale mail service without traditional folder-like mailboxes into the mainstream. While Gmail is a limited and oversimplistic implementation (for me) I see it foreshadowing the future of more generalized and pervasive "file/folder-less" interfaces. Naysayers take heed.
Now we all know the file metadata stuff is now in there at the OS level - the question is whether Apple are going to make it easy to get at.
Possibly with extended attributes, as Siracusa mentioned in his 10.4 Ars article? And maybe that's where Finder/Spotlight comments belong instead of being stored in volatile .DS_Store files?
Finder is an application - it is not the filesystem!
There is no need whatsoever for the view presented by the Finder to have a one-to-one correspondence with the actual files (or database entries).
I completely agree, except Finder does indeed still present users with that one-to-one correspondence with the hierarchical filesystem -- strictly enforced (with the exception of smart folders).
One of the questions of this topic, explicit or implied, is whether or not we actually need that kind of file manager as a primary interface for managing and organizing our data. My bet for the future is that we don't.
One perspective is that the more "personal, isolated" desktop metaphor is being superseded by the more "social, connected" web metaphor. And the newer web metaphor more easily downscales than the older desktop metaphor upscales.
The desktop metaphor can and will continue to serve us, but we've also been held hostage by it -- insert list of the usual suspects. More alternatives are emerging as we're typing and reading here.
In the future, the way we manage files/folders now might seem similar to how assembly language seems to most programmers now.
Scalability is forcing the pedal to the metal. Finder-like file managers can't (and won't) keep up. The race is lost even if it's not officially over yet.
Anyway that's generally how I see it.
other apps that integrate with Finder
iTunes, for example, relies on the Finder to show the files corresponding to songs and, if the application is not available, just drops the call. Until all applications can abstract their requests and ask the system to "display" some "file" without needing to specify a path or talking to a specific application, dramatically changing the Finder would, I believe, be complex.
What you are talking about is merely integration of other apps with Finder. Since Apple is in control of both Finder and iTunes, it is not hard to change both dramatically and still have them "talk" to each other. Thus the requirement of iTunes-Finder integration would not preclude dramatic changes to Finder.
However, as you point out, 3rd-party apps are currently second-class citizens with regard to this integration. The situation is to be regarded similarly to that which applies to the "iDisk" menu item in Finder's "Go" menu. If you don't subscribe to .Mac, this menu item is non-functional. If you don't use Finder, any Finder-integration that is built into other apps is likely to be non-functional as well. But that doesn't imply anything as to the possibilities of changing Finder.
Why wouldn't SQL be possible?
Sounds like we're wandering into WinFS territory. Maybe someone who's more familiar with it than I am can comment on if and how that relates to your comments.
I've heard a few speculations about where Apple's going with future filesystems, including a rumor about using Sun's ZFS in Leopard.
Ohhh... battery's done, bye for now.
iCal
Personally, I can find more nits to pick with iCal than Address Book. I use the excellent DateBk5 on my Palm PDA as my primary calendar app. Since I keep the PDA next to my desktop computer while I'm working and with me when I'm mobile I haven't cared about synching. In his PalmSource DevCon interview, Stewart Dewar said he's working on a desktop calendar app (that'll sync with DateBk) but unfortunately (for us Mac users) it'll only be a Windows product. How can we bribe Stewart Dewar to be a Mac developer? :-)
other apps that integrate with Finder
Hi again!
Yes, we agree! The existing integration between the Finder and many applications, Apple-written or otherwise, would make such a transition difficult, but certainly not impossible. Should such a transition happen however, many third-party applications would no longer be functional, or entirely functional, hence causing much frustration (and fury) among users.
FJ
other apps that integrate with Finder
That's what compatibility layers are for. Older apps that use the proper APIs, e.g. Apple events, will continue to function as before. Were Finder replaced completely, for example, it would be trivial to provide a faceless background 'Finder.app' that implements the original AE interface and forwards incoming events, suitably modified, to 'Finder 2'. I suspect that would take care of the great majority of cases without trouble.
Any third-party apps that use undocumented APIs, direct GUI manipulation, etc. will get burned, of course, but that's the risk they accepted when they signed up for such cheats. And breaking a few dodgy programs seems a reasonable trade-off for major improvements everywhere else, especially if the replacement can also eliminate all need for such nasty hacks in future.
Mind, if 100% perfect backwards-compatibility were an absolute requirement at all times, we'd still all be stuck on classic Mac OS - and Apple would probably have gone down the tubes by now as a result.
Cheers,
has
Just Bring Back Tabbed Windows
Not really advocating a return to OS9. Just want my tabbed windows back!
other apps that integrate with Finder
And Intel-based Macs should really put the nail in the coffin for Classic Mac OS since (AFAIK) they won't support it.
Re "I would like to see a dramatically different Finder come up one day, one making use of visual effects for real"
This sums up what Mac users are all about, more concerned with 'visual effects' than the ability to organise and control information (the essence of what a computer is supposed to do well). How dumb, just buy a PC and get a computer that does the job correctly. Without all the Mac's useless graphical garbage and crappy operating system.
Ed,
Visual effects, when used appropriately, can be a great help in presenting content such as files and folders. I am not, that goes without saying, asking for gratuitous effects that, as you rightly point out, only get in the way of practical use. As for all effects being "garbage", I guess we will have to agree to disagree.
FJ