What's wrong with the Finder? - Page 2

I think Siracusa is a big bag of hot air on the finder.

Seriously, he has put so many hours of effort and wallpapered so much bandwidth with his blatherings that he could have designed the new atom bomb, cured cancer and figured out how to keep mice out of the bread sack in your kitchen cupboards.

Does anyone really know what he really wants? Does he?

I like Spotlight. I would like to see that get supercharged and blended a little better into the Finder or whatever it turns out to be. Spotlight pretty much finds everything I have lightning fast.

Right. Makes no difference to the end-user experience. And as Apple hasn't shown a lot of interest in developing the finder, it doesn't matter how fast the 'non-existent' development is.

This Cocoa thing is a read red herring, regarding the Finder.

Attention.

Is this sarcasm? Maybe I should just get an AMD. Heck, I've bought several entire, fully funcionting computers for the price of that memory. I wonder where you bought it, your price seems to be above market, even for ECC.

The biggest thing I want is an option that the Finder to sort folders/directories first, files next. In any given directory, generally what I want is usually up or down a directory. There is a hack that improves this, but it doesn't work well. Sure, I could use Spotlight, but I don't think Spotlight should be the only tool for the job, sometimes there were extenuating circumstances that meant I couldn't find the file I wanted with Spotlight.

In every pane, I think Finder should offer the option to have have an ever present "double dot" (..) equivalent that is in Unix and Windows so I can go to its parent directory, provided it's not already at root. It seems the Finder team leaves this out because it was Not Invented Here.

I'm not saying that everyone should do the things the way that I am doing, I just think that the Finder and other Apple software should be more inclusive and flexible rather than just assuming that no one wants to do it some sligthly different way.

I think you too are exaggerating the amount of effort.

How would Core Image and Core Video help? Moving files around doesn't seem to be something that can benefit greatly from those two features.


It should be fixed. In the short term, a program called Iridium that does most of what you want. It will change every program that it can to the "Unified" theme. Don't ask me why, that is actually the name of the look.

How is that an exaggeration? That's step by step what you have to do.

Windows' backwards-ass method of tying programs to Windows is what causes cheap hacks like the system tray to exist, which is a big part of the reason why Windows gets so slow once you've loaded it up with programs.

If you're in icon/list view, you could always sort by Kind. But that would definately be welcomed


One thing that happens when you add lots of features is that the Finder Preferences... gets insanely crowded.

For example, I'd venture to say that you are the only person, ever, that wants that double dot option from Unix. Ever. Why should everybody have to have a checkbox that only you would want? When you add in all kinds of options that appeal to like three peope, the Preferences begin to look like something from Microsoft Word, ie, mind-numbingly confusing.

So then some poor soul, who doesn't know what ".." means, accidentally enables it to find out. Then all these ".." folders appear. In each one of his folders. But even though they're inside a folder (because .. translates terribly to a spatial filesystem), they link somewhere else. Our dear poor soul can't figure out how to disable them, because he can't find that one option among the 500 in the Finder Preferences, so he trashes it. And all the sudden his entirely computer is in the Trash.

Not to hate on your feature of choice in particular, but options like these are never a good choice because they do so little good in comparison to the damage they do. They're really best left as haxies.

Finder is bad, but it really doesn't need much to bring it up to speed. Just some threading and a visual makeover. And better Spotlight integration (Spotlight, of course, needs lots of work to bring it up to speed... but that's another story).

command-up arrow will do the double-dot function. ("Open enclosing folder").

Or control-click the finder toolbar, choose "Customize toolbar", and add the item "Path". Or Command-click the title od the window to jump to any underlying directory (also works in most apps).

That is pretty neat, where I can jump to any parent/grandparent/..../root. Thank you. One less gripe against Finder.

Here's another Finder "feature" that needs to be fixed.

Link

Something else that has bothered me is that if I am at the end of a file list in icon view, and delete or move a lot of files from the current folder, I am left with an empty view, often without a scroll bar, despite there being files in the current folder that aren't in the current view.

What I have to do is bump an arrow key for the view to properly align itself so that the remaining files are displayed. My contention is that the finder should automatically do that without user intervention. Several times, the fact that the scroll bar is missing gave me the impression that the current folder is empty.

I couldn't have said it better.
In Addition: I give you two numbers to consider:
active AI Posters, say, about 100
active ARS Posters, say, about, 100+
active Mac OS X users, say, about billions over billions (being quiet).

Most Mac users i know are a pretty satisfied with Finder.app,
Despite all rants and rambles the Finder gives you
quite a good computer experience on a daily basis.

Consider.

Of course...and you'll probably find hundreds of millions of people satisfied with Windows. Because they don't *know*.

If everyone cattered to the lowest common denominator, we'd be a deep shit right now (maybe even literally).

Here's even more to consider:

The 100 AI posters and 100+ Ars posters are the people tech companies should listen to if they want an edge.

ditto.

Here's my gripes with the Finder. I work with column view, so most of my gripes are related to that. Some have been touched on already. Someone else stated that quite a few problems are "nit-picking". There are two things to consider: sure, some, if not all, the problems are quite small, but there are a huge number of them. Add them all up, and the problem is significant. Additionally, Apple brand themselves as paying attention to the details. (Steve Jobs talks about this in nearly every interview he gives). The Finder is one glaring example of an area where Apple have not paid attention to the details.


1. Poorly threaded


2. Handles networked storage poorly.


3. Icon only display for the sidebar in the Finder:

At the moment, the separator between the sidebar and the main part of the window can be moved so that the names of the items in the sidebar are no longer displayed. However, this also means that the eject buttons that show up for removable items in the sidebar are not displayed. There should be an option in the sidebar Finder preferences to show icon only, text only or icon and text, just like there is for the toolbar. All three views should ensure that any eject buttons are visible.


4. "Open new windows in column view" Finder preference:

I am constantly wondering what the point of this preference is. I have it checked, but I can't remember the last time a new window (e.g. a newly mounted CD, Network drive or Disk Image) actually opened in column view. When the "Open new windows in column view" Finder preference is checked, a new Finder window should NEVER open in anything other than column view. It's as simple as that.


5. View options for column view in the Finder:

Why are the only view options for column view: "text size", "icon" and "preview column"? Why aren't there options for "icon size", "keep arranged by...", and "background colour" and why is there not a persistent column width for each folder? At the moment, the view options for column view seem to be global. Surely each folder can have its own individual preferences for when it is viewed in column view, just like for other views such as "list". At the very least, it would be nice to have a preference to "auto size" all column widths (i.e. set the Finder to automatically perform the task that is performed currently if a user double-clicks on the bottom of a column separator).


6. Cut and paste of files in the Finder:

At the moment, a file can be selected in the Finder, "copy" selected from the edit menu, a new location navigated to, and "paste" selected from the edit menu in order to copy a file to a new location. It should also be possible to select "cut" from the edit menu in order to move a file from one location to another, just like in Windows. (I know there are issues with this in relation to the Cut/Paste metaphor and in some people's opinion it would therefore violate consistency of interface. If this is why the feature has not yet been implemented, why not call it something other than "cut" (for example, it could be called "move"), and give it a different keyboard shortcut?)


7. The addition of a "shelf" to Finder windows would be very helpful when moving files. The shelf could be implemented as a "drawer", and the user could choose which side the drawer should open from.

Let's say I have the shelf set to open on the right. I have file "A" that I want to move from its current directory to a new one. I click and drag file "A" outside of the Finder window to the right, and the shelf drawer opens. I let go and the file is now on the shelf. Now I navigate to the new directory, drag and drop the file from the drawer, the drawer automatically closes, and the file has been moved.


8. Switching between items in the Finder sidebar using the arrow keys:

Picture the following scenario: The Finder sidebar contains hard-drives, removable devices, the network, applications, the home folder, documents, movies etc. In the Jaguar Finder, pressing the left arrow key when in the "documents" folder in column view would scroll the user back to the home folder, then "Users", then to the root level of the hard drive. However, in the Panther Finder, if "documents" is selected from the sidebar and column view is active, it is not possible to scroll up the folder hierarchy using the left arrow key. This is fair enough. It would be extremely useful however, if pressing the left arrow key in this case made the sidebar like the "active" column, so that the items in the sidebar could then be navigated using the up and down keys. So, for example if "documents" is selected in the sidebar, but I want to go to my music folder, I can press "left" to make the sidebar active, then "down" until my music folder is selected, then "right" to navigate the music folder.


9. Unzipping files stored on read-only media

If you double-click on a zip file in the Finder, the archive will be decompressed. The Finder will attempt to write the decompressed files to the same directory as the source zip file, so if the zip file happens to be in a read-only location, such as a CD-ROM, the decompress will fail. The resultant error message by the Finder is deeply unhelpful, simply stating that the archive could not be decompressed. It would be better if the Finder checked to see if the intended destination is writable, and if not, ask the user to choose a destination for the decompressed files.


10. Shift-arrow selection behaviour. Like someone else said, this is not limited to the Finder, but is worth mentioning because it is IMHO the single most annoying thing in OS X. It really pisses me off. Really.

\tUsing iTunes as an example: In an iTunes playlist, multiple tracks can be selected by clicking on a track, then holding down the shift key whilst pressing the up/down arrow keys.

\tPressing the down arrow key always extends the selection downwards, whilst pressing the up arrow key always extends the selection upwards. This means that it is impossible to contract your selection, you can only make it bigger.

\tI find this highly annoying and think that the selection process should work like selection of text in other applications such as TextEdit. This would make the interface more consistent and more intuitive. The function of the up/down arrow keys should depend on the direction in which the selection was originally extended.

\tFor example, imagine wanting to make a selection starting at a particular song and extending downwards: if you overshoot your intended selection, you should be able to contract the selection by pressing the up arrow key. Correspondingly, if your original selection was upwards, pressing the down arrow key should then contract the selection.

The finder is definitely sluggish for me. I also find it sort of generally cumbersome, but that could also be because I still have a hard time understanding and thinking OSX sometimes.

eek! Hell no. The proper differentiation between windows and applications is the biggest difference between Mac OS and Windows. I'd actually go the opposite direction and say that all apps that currently quit when you close the last window (e.g. iPhoto) should be fixed so they don't.

Thank you pointing out this issue. That's what i keep claiming for
years. Apple didn't listen to me.

Most of the programs that do this don't really seem to have a reason to keep running, your instance, there is only one window rather than multiple like Finder, a document editor and so on. If you still want to use the program later in a session, it seems to be much quicker to hide and unhide apps than it is to close a window and re open it.

Some apps, such as iTunes, have lower CPU usage with no windows open (whether those apps are hidden or not). Also, it is totally inconsistent. Why should the user have to remember which apps quit when you close the last window, and which don't? For example, Address book stays open when you close its window, but calculator does not. In order to fix the consistency problem, I'd much rather that things change to all apps staying open until you choose "quit" than all apps quitting when you close their final window.

As a single-window app, Address Book used to quit on close. Apple changed this upon adding Bluetooth support, where an incoming call can display caller ID on the Mac's screen. To maintain the Bluetooth connection, Address Book must remain running, hence the change.

Excellent use cases can be provided for both types of behavior, and IMHO this 'inconsistency' does little if any harm to users. The simple cases - iPhoto, PhotoBooth - *are* simple, while more complex cases - mulitple window/document apps, Adress Book - aren't, and necessarily so. Shoehorning everything into a single model would eliminate the simple cases and possibly introduce greater complexity in the long run via complex corner cases. For strawman examples to the contrary, witness the disaster that is MS Word's "what will this 'X' button do?" MDI-bastard-child interface on Windows.

So I think Apple is being open-minded and possibly even forward-looking. Eventually, I suspect we'll see the notion of 'Quit' or process termination removed from interface vocabulary altogether. Applications will always maintain a user's working state and won't ever terminate or quit - they'll simply suspend to virtual memory. The processes will automatically come and go as the app and OS deem necessary.

If you have enough RAM, OS X functions much this way already; just leave everything running. At this point the only compelling (inteface) rationale for 'Quitting' is to free up the dock and return its icons to a reasonable size - solely an interface contrivance, to be sure.

I said this before and got no responses, but wouldn't it be easy to make applications that quit upon closing a window have a square red button instead of a round one? Instant feedback on what will happen.

If you are going to keep some apps quitting upon closure of final window, and some not, this is the obvious solution. I have no idea why Apple doesn't do it or something similar.

Why would you choose to complicate a widget that appears on *every* window just to communicate a bit of information most users don't even need to know in the first place?

Don't even need to know?? I think it's important that users know whether an app is going to quit or not when they perform a particular action.

You use the cmd (Apple) key for that. I always combine two keys for selections, cmd for single or selective selections, shift for filing the gaps if neccessary. It works, but most people don't know you can use cmd for it. And I'm not sure if the use of the cmd-key is a consistent or logical UI feature for this.

No, you can't. You have misunderstood.

Do this: Open a folder that contains several items in the Finder, and set it to list view. Now, select one of the items in the middle. Now hold down the shift key, and press the down arrow. Keeping the shift key held down, every time you press the down arrow, the selection will extend downwards. There is no way to contract the selection. If you press the up arrow, the selection will extend upwards.

Do the same in text edit when selecting text and you will notice different, and much more intuitive behaviour.

Yes, I would argue (and do so, above) that we will soon reach a point where users will neither have to know nor care whether an application is 'running' or not. But, granted, that time has not yet arrived.

"Is it important that users know whether or not an app will quit when they perform a particular action?" (specifically, clicking the red 'X' button)

No, it is not. As long as that action does not result in loss of user data or other relevant state, it is not important. *Certainly* not important enough to introduce an interface curiosity whereby some 'X' buttons are shaped differently than others... talk about inconsistency!

Now, let's try a slightly different question: is it important that users know whether or not an app has quit in response to a particular action? For the sake of this argument, sure. Look at the menu bar; is the app's name there? Check the dock; can you find its icon?

My point: there is no need to know 'in advance' exactly what the close button will do, so long as it doesn't do anything 'bad' *and*, if you're an individual who happens to care, there are means for determining the result after the fact. If you care, and an app's close button behaves consistently, you will quickly learn its behavior.

Are you trying to tell me it's not a pain when an Application quits when you are not expecting it to?

I agree that making the round widget square would probably be going too far, and that's why I said "or something similar" would be a good idea. If the app is going to quit, the "x" that appears inside the circle could be itself enclosed in a square. This would give the user some advance warning that pressing the widget will result in the application quitting.

There are some applications which people do not use very often, and it is therefore easy to forget whether it is an app that quits upon closure of final window or not. Also, the application may have been updated (as part of an OS update for example) since the last time you used it, and its behaviour in this regard may have changed. Some visual indicator of what is about to happen would be nice.

It is important to note that I don't think this a major problem, mac os is not doomed because of this flaw. It is just one of those "little things" that would be nice if it were fixed.

Actually, i like what you are proposing.

Generally, I do understand theoretically why there is some
different behavior regarding on clicking the red X button.
(1) Apps, which create and manage docs (content) do not quit by clicking
the red X. A no brainer.
(2) Apps, which are single window apps like System Prefpane, Calculator
and some other quit on clicking.
But i do not agree the philosophy behind that. I think it is a flaw
in UI design, yes, ... talk about inconsistency!
I am always asking myself, why the very same action (clicking the red X)
produces different results (either quit or close). No big deal, but
the inconsistency does exist. MS Windows produces more consistency
in this regard.

I belong to that specie that never ever quit any app, i almost always
use CMD-H. I just want to have my apps steadily on standby. I feel
more comfortable that way.
As a sidenote: in the Mac OS 8/9 days, hiding an app gave us
a huge speed advantage over MS Windows, remember.
Opening a large PS doc was almost instantly, just because the
app was already running in the b.g.

I don't like the Finder very much either. One thing that I keep thinking though is why would it be so hard to make a new one? We have a very efficient and stable unix base that can do pretty much everything the Finder does. Why not just turn the Finder into a scripted front end for unix tools. Finder style file moves and renames can call the unix mv function. Finder copies can call the dd function and could even do IO error handling where the Finder currently fails. Isn't disk utility just a front end to the diskutil/hdiutil commands?

I think that with that approach, you could very quickly design a fully functional, stable, lightweight, multi-threaded finder. It would also tie in much better with terminal commands as it would just be using the same commands itself. If it was mostly done in some sort of scripting way, it could be more easily customized by end users too and that would also speed up development.

I also wouldn't mind seeing some sort of revolutionary file viewing feature. The column view is my favourite of all of the 3 we have but it still has that sliding problem when moving files. Since Spotlight indexes a lot of the filesystem, I wonder if it would be possible to have a big window that displayed every folder in the entire filesystem at once as some sort of tree view. This view would encourage users to have a more ordered filesystem. Often times I see people store lots of files on the desktop and then put one or two files 20 hierarchies deep. That makes finding the files you want inefficient.

Obviously with so many folders in an OS X system, the window would need to have a zoom function (preferrably with the mouse wheel and +/- buttons for users of crappy mice ). When a folder was selected, it could show a list view of the files in it maybe on the right of the window. It's then pretty easy to move these files to any folder in the entire filesystem. The list view could be tabbed too and changed to icon view.

Lastly, I think it would be good to have the Finder always accessible without switching the current application to the background. Maybe if there was a menu item like spotlight that dropped down the file browser. One use I could see is for dragging images out of Safari. You can drop images straight into your filesystem.

I like command hide as well.

just then click on the app and there you are.

Saves a lot of real estate and makes things look a whole lot better.

Path Finder 4

If I was running 10.4, I'd definitely be giving this a go.

It wouldn't be changing on every window, just the ones that have a different behavior. Maybe my solution isn't the right one. I like the back and forth on the topic here though, because it is an issue.

PathFinder is probably the best alternative Finder but it's too slow for me. When I can do file operations in the blink of an eye in the terminal, I should be able to get close in a file browser app. If not then it's wasting time doing something I don't need it to do. When I'm trying to sort through thousands of files, I can't be doing with all the delays.

Sadly that seems to have happened a lot to OS X. Yes it's pretty but there are times I just feel I want to get at some raw power.

For the most part, I don't have much of a problem with the Finder but it lacks features and it is buggy. Imagine if the Finder was just an open source front-end to the unix base. We could all have tabbed views by now. I wonder why Apple just don't open source it or I mean start an open source project to make a better Finder.

I'm with Marvin. The unix commands are tried, heavily tested, and rock solid. They are optimized. Copying files via cp is instantaneous, or as close to it as you will ever get. HFS+ gets dissed now and then for being 'slow' when in fact it is Mac OS X's copy command.

I'd also like to see use of cpio in Marvin's hypothetical Finder. cpio allows you to browse zipped (gzipped, bzipped, etc) archives as though they were folders. You can copy files from and to these archives, without decompressing the archives. Open Terminal.app and do a "man cpio." Apple: Hello?

cadaver (GPL command line WebDAV client) is 1000x faster and way better threaded than iDisk.

Also, and I've stated this many times before, a virtual file system such as Gnome's. With the Gnome VFS you can mount (eg) an FTP volume and browse it as an extension of your hard disk, copying files to and from it, opening files on it with your local apps (instead of launching <networking app x>, downloading the file first, etc).

Think iDisk behaviour, but for every form of networked storage. Double click an icon in your home folder that represents some form of networked storage, and start browsing. Add it to the left hand tab of the finder's window.

Allowing people to browse zip files like they were folders brings a lot of usability problems and confusion to newbie users. Instead of unzipping a file, a newbie user will simply try to run apps or manipulate files inside the zip file as though it were in a folder.

And that just doesn't work.

A lot of apps just can't run or run correctly within a zip file. Adding this feature to the Finder is a disaster waiting to strike a poor n00b.

But, yes, we can all agree that the Finder is a crusty old bag of shit.

I've actually wanted to browse compressed archives too. If you can't do stuff with the files like kim kap sol said then that would be a limitation but maybe there could be a scrollable preview window that lists the contents and lets you extract selections.


Tiger mounts ftp servers when you click an ftp link from Safari whereas Panther just downloaded the file. That actually annoyed me but only because OS X sometimes takes so long to mount the thing. As you say, using some of the unix tools would likely speed this up enormously as they are tried and tested.

In Tiger, I can use the connect to server option to access the ftp account for my website. I just type in the ftp server address, login/pass and it mounts where my other drives are in the Finder.