The Finder is dead. | Hacker News Reader

The Finder is dead.

sachin.posterous.com

39 pointsthedob63 comments

Do not want.

Limiting the amount of interaction the end user has with a hierarchical filesystem may well be a Good Thing. Increasing the degree to which each application is a black box containing all associated data is a Bad Thing. Making each application responsible for the mechanism by which data can be transferred, archived and synchronized is also a Bad Thing.

Excellent point. As frustrated as I am with the limitations of the "file" and "directory" abstractions. Without them, transfer, archival, and synchronization of data would likely be far more difficult than it is now.

Not that the systems we have now are anything to be proud of.

It seems Apple has evolved the iPad past "application / data - same place". It now looks like a common area with different types of data accessible by apps. This is actually a pretty good solution. People know how to use a search engine and the current hierarchy is not a good solution.

Right. Getting rid of the (constantly visible) filesystem could be a good thing if it's replaced by a metadata-rich database that lets you do interesting queries. But based on Apple's recent history they won't actually expose any of that functionality, and we'll be limited to what the apps are specifically written to do.

This article is full of flaws.

Finder was just rewritten from the ground up, from scratch. Heavy investment.

Spaces is about windows management, which has nothing to do with Finder. Same with Expose.

iPhone and iPad deal with files, one way or the other.

Finder was rewritten because Apple is aggressively moving to 64-bit code which means Cocoa, not Carbon. Despite such extensive changes, the Finder (as seen by the user) arguably changed less than it had in any previous upgrade.

Similarly, iPhone and iPad deal with files one way or the other, but the point isn't how it works underneath -- you could have a team rewrite iPhone OS to use Newton-style "soups" and have essentially no change to the user's experience. Files are a convenient abstraction for programmers (and, remember, an abstraction is all they are -- in the end, disks are just a linear stream of bits that the kernel/file system layer "artificially" organize into "files"), and there doesn't seem to be any need to hide a file system from programmers. But users are, in most cases, better off dealing with app-specific document managers.

iPhone and iPad deal with files, one way or the other.

For mere mortals, the 'file' as a concept is further up on the pyramid of taxonomy; most people think about their stuff in lower classifications like photos, movies, documents, etc.

When you see a bear, you don't say "Look, an organism!" You say, "Look, a bear!"

the finder was rewritten (so i was wrong about that) but it didn't functionally change. Apple isn't actively innovating within the Finder.

Spaces and Expose are not "Finder" directly, but they are still concepts trying to deal with the issues around windows, multiple apps, and sharing between apps.

Look at Gnome shell for some fresh desktop innovation.

Yeah. The command line is dead too. That's what purists believed in 1986. The Mac killed it. Except, it just keeps coming back because it's so danged useful.

How many people do you know, whose job title does not start with computer and/or IT and/or sysadmin, actually use the terminal?

Think of this as a "meta-filesystem". Instead of asking the OS for files and folders, an app just asks the OS for "photos" or "music". Most people, and by most people I am referring to the lowest common dominator like your grandmother, don't care where a file is and actually constantly loses where files are.

As with all things Mac, since Apple obviously dogfoods their systems and servers with their computers, the filesystem will not go away. But it will be hidden from the bottom 99% technical layperson who simply doesn't care. Files and Finder, like Terminal.app, will be there for those of us who do care.

You need to differentiate between what's good for the people/commoner and what's good for the developer/pro-user, since they are in extremely difference market segments given technical proficiency.

The terminal is not the only command line. I would imagine a lot of people use Start->Run, Windows Search, Spotlight, Google Desktop Search, and search engines, and those are all command line interfaces in a sense.

I disagree with you there. Yes, those are command line "interfaces" in terms of what the GUI (or lack thereof) is. But typing in a name into a search box and being presented with a graphical list of results as links or icons is not at all the same thing as a command line interface that lets you actually type commands, parse results, and execute other command line programs. Don't confuse a search box with a command line, because those are very different things.

What about tab-completion?

I never said it was the same thing, and I'm a little insulted that you'd think I did. Of course a shell is different from Spotlight or even Start->Run. But they do share the basic UI paradigm of typing in commands rather than graphically navigating to them, because that paradigm is more usable for many tasks.

My apologies; looking back at what I wrote, I realize I did respond harshly. Your comment (and you) deserved more courtesy than that...

I guess my disagreement stems from the fact that I don't see what I type into those boxes as commands (even though some search boxes, like the one in the Windows start menu, can work that way). I think of those boxes as fixed to one command, search, and all I get to type are parameters.

Yes, but what you type into a shell is just parameters to a system call ;)

Seriously though, from the user standpoint, typing "vim" into the shell and typing "TextMate" into Spotlight are more similar to each other than either of them are to navigating through the Finder and double-clicking TextMate, or even clicking it on the dock. The shell is smarter, but perhaps too smart for some users.

How many people do you know, whose job title does not start with computer and/or IT and/or sysadmin, actually use the terminal?

Loads. They are called working scientists. Sometimes there is a perception that the world is divided into geeks and "appliance" users. There is actually a non-trivial amount of grey area in between.

Why do those scientists have to use the terminal?

Not a snarky question: I'm not very familiar with scientific computing and am curious (from a UI perspective) why, say, applications for office work manage to keep things essentially all in the GUI, but apps used by scientists can't. Is the problem that scientific apps don't devote enough resources to good/comprehensive UI or is it that what scientists do is better done from a command line?

Regardless: as I said elsewhere in this thread, this is why I'm starting to think of PCs/Macs as the workstations of this era. There will always be a need for them. But they're probably needlessly complex for most uses.

well, I'm a doc; I and every other doc in the military use a ncurses-like system on a VT500-7 emulator hundreds of times a day because it's insanely fast compared to the slick java/IE7 GUI that the gubm'n't spent $20B to write (AHLTA, look it up. Tons of money for you if you can beat it. Would be willing to help).

Ahh, thanks! I was thinking of terminal usage as being synonymous with shell usage, when, of course, there are many users of character-mode apps that never see a shell.

An iPad running a terminal emulator and with a keyboard attached would be a comparable experience. Though, clearly, it's not the best solution for most such users. Linux/etc all the way for that.

To answer your question, there's a number of reasons. Undoubtedly some do just come down to "historical reasons" but there are many reasons why a command-line is actually the right choice. The main reason is that the scientist wants to run a very specialised analysis of her data, and so is almost certainly either running custom code, or at least code that was developed in an academic environment. Creating GUIs that are flexible enough to cover all the things somebody might do with their data is a complex and time consuming task, and does not directly produce "science". It is a lot easier to use the command line to interact with your dataset. Moreover you often don't know what you want to do in advance ("if we knew where we were going, we would't call it reasearch"). Therefore a typical user may fiddle around with the command line trying to get the most out of their data, and then string it all together in a script - so again, a command line makes a good prototyping environment.

Certainly in my area (astronomy) I have seen some attempts to provide gui based intefaces to data reduction, and even mocked up a few myself; but the effort to reward ratio isn't worth it - especially since you are dealing with people who can, in general, follow instructions.

Also, do not underestimate the higher effiency of the commandline - after all, there is a good reason we all use it. Even if there was a system administration gui out there, would most sysadmins use it? It's actually faster to type.

I think the "appliance" model of computing (eg. iPhone/iPad) is perfectly valid for a good percentage of the population at least for some of the time, but it won't render "classic" computers obsolete.

I also have to say that personally, I have generally been dissatisfied with attempts to disguise or flatten the filesystem by, for example, using tags instead. I actually think pretty damn hierarchically, so I often organise my material as IF it was a filesystem, when the application will allow me to do so - maybe it's just me?

Excellent answer, thanks, and I think my (also-hierarchically-inclined) gut agrees with your last paragraph: if you're gonna expose a complex filesystem to the user (and, for many usages, that's a good thing), hierarchical — with metadata/content indexing for fast querying — is probably the way to go. I'd like to hear of situations in this area where people think a tag system is/would be better than the hierarchy+index system, though.

A lot of people use Google.

You're right, the command line isn't dead, just as the Finder isn't going to die. But like the command line, the Finder will asymptotically approach uselessness for most people. iTunes just manages music better; iPhoto manages photos better.

Ask ten random Mac users how to find a file by name via the command line.

Interestingly, the Finder might go away before the command line. The first answer that popped into my head to give you was "mdfind"—and then I realized that it wasn't "by name," but rather by Spotlight metadata. File names have already hit the limit of infinitesimal usefulness.

You clearly don't get the semantic power of written language over gesturing over icons. I wonder if we are not intentionally de-evolving ourselves with all this gesturing.

One of the reasons I love the unix world and despise Windows is precisely because things are not in black boxes. I can read and parse log files. Config is in text files that can be grepped. Automated processes are run from scripts that I can open and examine. Very little is done in a walled garden closed binary format. Even Apple's applications are folders inside of which I can find yet more scripts, text files, resources, etc. When something goes wrong I can usually figure out why. When something fails for some god-knows-why reason in Windows, I get an error box, and nothing else.

Please don't try to hide the guts of a system from me. It is the thing I value most about my Mac.

This is exactly why I think "computers" (using the 'folk' parlance here: I know iPhones and iPads are "computers") are on their way to becoming, essentially, workstations.

Complicated tools to do complicated things.

I don't see any reason that the Mac should ever move away from having Finder and Terminal (though they will become less and less used by the average user), but the vast majority of things that "end users" do with computers don't need to deal with this sort of stuff. The tools to make end user tools (end user tools such as device OSes, apps, and server software for end user apps to interact with), will always necessarily be of another level of complexity.

Let the Mac stay a Mac (read: UNIX), I say. But I don't want to do most of my non-techie stuff on it anymore.

While 90% of the time I agree with the ease of sandboxed and cloud-synced file management, there's still that 10% of the time that I'm annoyed by it.

If I want to copy, rename, share, or email a specific file I find it easiest to do it in the file. I find it almost as easy to do it in an app that facilitate it easily like iPhoto (with it's built in share and email buttons). I find it much more difficult to do it in an app that doesn't make it quite as easily facilitated through the UI, like iTunes.

I would love for the finder to go away, but I'd hate for it to go away at the expense of every app developer having to rebuild mechanisms into each app to expose general file manipulations that the finder handles quite well right now.

In June or so (according to macrumors: http://www.macrumors.com/2010/01/23/mac-os-x-10-7-appearing-...) 10.7 will be pushed out to developers at WWDC and we'll see for sure. Personally, I can't stand this speculation that, just because Apple designed an iPhone and iPad, that they're going to cripple the Mac. I think if they think people will be better off with a limited device, they'll just try and sell them an iPad instead of a Mac.

Hierarchical file systems aren't terribly usable--how many people do you know who just splay all their files across their desktop--but I can't imagine Apple replacing it with just an app model. (Personally, I like Gmail's archive/label/search system for a filesystem UI, but it's hard to see what wrinkles we'd run into translating it into a general FS.)

Yay! Lockin!

The future is one big black box that it difficult to manage or migrate.

Doesn’t have to be, though. Can’t you have both?

iTunes does pretty well but doesn’t make it all the way. More a fault of the of metadata than iTunes. You are be able to access your music the old-fashioned (crappy) way – which doesn’t make any sense for music – but there you go. All nicely organized in folders. That’s how it should be. I want specialized apps, I don’t think any generic file browser could be as feature rich as specialized apps without turning into some kind hybrid monster and usability abomination.

So it’s possible. Sure, it’s also hard.

It's possible sure, it's not hard, Apple will just never want to do it. Just like Microsoft, lock-in is not something they want to avoid.

I hope I'm not alone in really disliking the current over-use of the word 'App'. An 'App' is merely a shortening of 'Application', they are not different things. Even on the iPhone an App is still just an Application.

Postulating that the current model of user's interacting with files mostly because Applications are now called Apps is faintly ludicrous.

On the other hand I think that hiding the intricacies of the filesystem in a user-friendly way would be welcomed by most people that use a computer for non-technical purposes. It certainly reduces the likelihood of problems caused by accidental deletion of config/application data.

This is exactly why I hate iTunes and the Apple ideology. I was using it for a while before I decided that the UI sucked for my massive collection of music. But getting those files out of proprietary codecs is a pain. No I do not want your monolithic Apple apps.

It may not be dead, but its been in perpetual suck-mode for multi-monitors since its inception.

It seems unlikely that the file system would disappear/become inaccessible altogether. Sure, when you want to edit photos you should have to dig around in folders. But existing apps already insulate you from these details - just by layering suitable abstractions over the file system.

Having the more general layer underneath gives you more power when you need it. It also gives all apps a simple, standard place to store their data. The raw file system has been slowly losing its prominence over time, but I really don't see a benefit in scrapping it altogether.

Macs will be touchscreens. The OS will look like iPhone OS. This is not hard to see.

Web Designers: Wake Up And Smell The Touchscreen Coffee! http://ebooktest.wordpress.com/2010/01/31/web-designers-wake...

Edited to add: This does not necessarily mean access to the CLI will be taken away. I think Devs would revolt over that.

I think you can go one step further and assume the browser is going to be the only app most people use. It's happening on the desktop, and there's no reason the same phenomenon won't happen on devices.

If this seems far fetched, look at it this way: most desktop apps are becoming more like browsers given how they use the network. Spotify is a perfect example (for those who've used it).

In this delightful future, how do I change the app I use to edit my photos? Or change the app I use to listen to my music?

Every app should be able to access the music, photos, videos, and other files on a system through smart APIs. But the user doesn't need to know about it or manage it

So the user is going to be able to organise their files through smart apis, but doesn't need to manage it? How's that going work work?

This is bad. Sure, you can make the user forget about files most of the times, but not kill it completely, because:

1) It'll be a hell of work to parse everything. Should my music clips go into the music folder or video folder? Sure, you can associate file extensions, but what if the software isn't installed yet? If two programs have to share files? The relations can fail in too many ways.

2) All software to ever run in this machine would have to fully implement it's own "file explorer". The picture manager will have to be able to rename, organize move files, as will the document editor, the video player, the text editor...

3) Less freedom of movement. What if I want to send a set of videos, documents and audio files to someone else? Would I have to open each app and politely ask it to send an email (which they will have to implement, too)? What if I want to backup an entire hard drive, with hundreds of different file types?

3) It'll be a complete hell if things go wrong, and you will have to resort to file management anyway. File lost extension somehow? Major file extension conflict? Unknown file type? You are screwed without manipulating the files themselves.

And don't even get me started on the reliability of your "in the cloud" future.

Has this guy seen the video for the iPad announcement? It makes it pretty clear that Apple intends on keeping Macs as the high-end/advanced machines, the iPhone as a somewhat limited portable device, and the iPad situated comfortably in between.

I don't see why the Finder and file concept have to die just because personal computing's storage model is evolving.

In fact Finder capabilities should only grow as many people choose to de-centralize and sychronize their storage.

And so, the gap between those who can make and those who are limited to consuming widens. A computer ceases to be a bicycle for the mind and becomes just another environment for consumption.

Is this really what we want?

I, for one, hope not - not specifically Finder, but the file/folder model in general.

I cringe every time I HAVE to drop to shell just to manipulate a specific file the way I would like to.

Try attaching a photo from iPhoto to an Email.

There is a button in iPhoto for that. You click it, it asks you what size you want the photo(s) to be, compresses them for you if needed, opens up Mail, opens a new mail window, and inserts the photos for you. What any other mail client does by requiring you to search through folders, potentially needing to go back and "save as" the photo if it's too big, iPhoto does with 2-3 clicks.

Just found that, but it only seems to work with OS X mail. I use Thunderbird.

You're kidding, right? iPhotos email button for photos is exactly my point. There should be intelligent communication and data sharing between apps, not at the Finder level.

in iPhoto, there's a preference to set which email client it sends to

What if I want to do something else with my photo, that iPhoto doesn't yet have a button for? How does a universal interface look like, that allows arbitrary other apps to get photos from iPhoto?

Intents on Android do something like that, but I am not sure how much they live up to their potential yet.

I am new to iPhoto and don't know about the config. I saw other people having problems with emailing photos from iPhoto, too.

Not everything Apple does or want is automatically the best way of doing things. This model they push works best if all applications are from the same vendor. Guess who has a vested interest in pushing that model?

Will all apps have the same kind of config? Or will I have to learn each new app, to make it work with another app? If I don't want to listen to my MP3s in iTunes, what do i do? Suppose I can send photos from iPhoto to Photoshop (or should I request them from within Photoshop, or should it work both ways?). Can I send them to The Gimp, too? If the Gimp adds a "request from iPhoto" button, will it add a "request from <Flickr|someOtherPhotoApp>" button, too? Will Photoshop?

Because the file system is pretty simple and universal. It's true that a lot of people have some trouble with it, but there might be trouble with the alternatives, too.

I think something like desktop search has maybe a better chance than the shiny GUIs.

"How does a universal interface look like, that allows arbitrary other apps to get photos from iPhoto"

Apple has an iLife media browser. It lets any application access any of the media on your system, including photos and music.

What if I want to do something else with my photo, that iPhoto doesn't yet have a button for? How does a universal interface look like, that allows arbitrary other apps to get photos from iPhoto?

The email export function is implemented with AppleScript. To add support for Thunderbird (for example) just means writing a similar script for it. Indeed, it appears that someone has already done so: http://softpixel.com/~cwright/programming/iPhoto/

Note that this is a minor hack, to get the button within iPhoto to support Thunderbird. It isn't necessary to get the same function as a regular Scripts menu item. Such scripts can be written in AppleScript, Ruby[1], Python, and Objective-C.

This is not really a solution to the more general problem being discussed, but I thought it worth mentioning.

[1]: http://developer.apple.com/mac/library/documentation/cocoa/C...

The file browser in OS X shows the iPhoto library in it’s source list.

Not on my Mac, OS X 10.6.2.

Any Cocoa application (it’s an Apple thing obviously, so it’s only going to work if the application is using their file browser), File > Open. Source list on the left, under the “Media” heading find “photos”. All there, browsable by events and groups, or as a continuous list.

A 10% market share company is going to change the face of computing... in a way that everyone has been predicting for the last 15, 20 years? I somehow doubt it.

To be fair, they were a 0% market share company when they changed the face of handheld computing (iPhone).

Has it? The iPhone is popular with geeks and rich folk, and mostly only in the US. Last I checked, such people weren't the majority of people. The iPhone has certainly pantsed WinMobile and Palm... but those were pretty easy targets to begin with. They haven't even come close to touching the global Symbian marketshare.

Who knows how accurate this is, but AdMob reports the iPhone as having a 50% share of the worldwide smartphone market. Moreover, even if they had a 1% share, I'd still say that Apple has utterly transformed that market. Any new versions of WinMo, Palm, Blackberry, Symbian, Android, etc will be influenced by and compared to the iPhone OS.

src: http://www.tgdaily.com/mobility-features/49169-report-androi...

Apple's mindshare is far greater than its market share.

Reply on news.ycombinator.com