Tuesday, 19 November 2002
Last Thursday's post complaining about the Mac OS X Finder attracted a bit of attention. At the time I had been sufficiently delayed in my work by Finder failings already, so I took the screenshot and posted a teaser regarding the problems I noticed. The message appeared as I was trying to move applications from my tiny, supposed-to-be-temporary-pending-reinstall-which-I-still-haven't-done Jaguar startup disk to another disk in order to make more room for swap files (currently occupying 547 MB in size on the 2 GB volume; despite having 896 MB RAM, I think I need more).
Here is my list:
- The alert message is poorly written. To use Apple's own interface guidelines on the subject, it doesn't use the user's vocabulary (what are “special permissions”?), and doesn't mention what the user can do to get ouf of the situation (what if the user really wants to move the item?).
- The message doesn't mention which items have the permissions in question, or even how many items have those permissions, when the Finder is obviously aware of which items are problematic, and the user probably has better things to do than check every single one (especially when application packages are involved).
- Moving items across disks/volumes consists of two phases: first the items are copied, potentially overwriting files in the target; then the items are removed from the source. The user is not necessarily aware of this, and referring to the operation as a “copy” (in the window title, and the alert message) is confusing.
- It's unclear whether the items with the special permissions are located at the source or destination: the message should be specific: “cannot be read”, “cannot be moved/removed from X”, “cannot be overwritten”. The answer can be inferred from the “copy” terminology used in the message, but again, you need to understand the mechanics of how a cross-volume move is performed.
- The alert message asks a yes or no question (buttons should be “Skip” and “Cancel”), yet provides only one option (the ever-helpful “OK”), which doesn't give any indication of what will happen.
- Assuming you consider “OK” to be the equivalent of “Skip”, the Finder doesn't skip the item: it moves nothing instead. This makes it very difficult to isolate the item, because you need to move each item in turn until you find the one with the message, instead of all but the problematic item being successfully moved.
- Various visual anomalies: extra space below inactive scroll bar, progress bar and alert icon bizarrely positioned, button and text spacing apparently random.
Some examples of moving and privilege conflicts, including reproduction recipes as requested:
% mkdir test test/from test/to test/from/a test/from/b % chmod 700 test/from/b ; sudo chown root test/from/b Password: % open test
Move (Command-drag) the contents of “from” into “to”. You'll get a message that reads “Preparing move to 'to': The operation cannot be completed because you do not have sufficient privileges for some of the items.”
Note that the folder “a” has already been moved to the “to” folder. This is inconsistent with the status message “Preparing move to 'to'”: obviously if items have already been successfully moved, the Finder is not preparing at all, it's actually performing the move. A preparation/preflight pass is useful, and I'm glad the Finder still performs it, so such confusing situations as half-completed copies can be avoided in most cases. Preexisting permissions which will unambiguously cause an operation to fail should be caught at preflight time.
Here's a better (though still imperfect) replacement error message:
“The folder 'b' could not be moved from “from” because you do not have sufficient privileges to read its contents.”
Ideally, the user should be given choices to (a) take ownership of the file, (b) authenticate and move the file preserving privileges, (c) don't touch the file and continue with the move, and (d) get help on the problem.
% sudo rm -rf test % mkdir test test/from test/to test/from/a test/from/b % chmod 755 test/from ; sudo chown root test/from % open test
Perform the same procedure as described above. This works well: “You cannot move the selected items because you do not have the privileges to remove them from 'from'. Would you like to copy these items instead?”
% sudo rm -rf test % mkdir test test/from test/from/a ; touch test/from/b % sudo chown root test/from/b ; sudo chmod 4755 test/from/b % open test
There's only one folder now; Command-drag it to another disk, and you'll see Thursday's message. Unlike in the earlier example, the “preparing” status is correct: nothing has been moved by the time you receive the message.
To people who say I should report these bugs: yes I should, but more importantly, Apple should fix this stuff internally before it ever reaches beta. There are systemic issues at Apple causing these kinds of UI disasters to happen, and identifying such problems one at a time is an inefficient way of dealing with them. Mac OS 8.5 was the last version of the OS to have any kind of consistent UI quality. The line can be drawn rather clearly: the “Index selection…” contextual menu item, one of the few visible additions in 8.6, managed to violate a bunch of guidelines (capitalization and wording) in just two words. New UI in OS 9, of which the most egregious example was Multiple Users, was no improvement. And here we are, four years later, with Jaguar continuing the downward spiral (an “Enable journaling” button in 10.2.2's Disk Utility, anyone?)
Someone should be sitting down with the OS 9 and OS X Finders, trying everything they can think of, comparing behavior, and keeping consistency where appropriate, and filing bugs. Better yet, that someone should have been the programmers implementing the OS X Finder in the first place.
For example, that it took until Mac OS X 10.2 for “replace all” to be an option in the Finder, though still not keyboard-accessible, when it was both easily keyboard-accessible and the default in Mac OS 9, is inexcusable. Who do they think has the patience to sit and click “Replace” repeatedly as the progress window resizes itself over and over again?
Similarly, the dialog box you receive when attempting to unmount a disk with files in use is completely useless, simply stating that the disk is in use. The OS is entirely aware of which application has a file open on the disk, and the name of that file nothing but some thoughtful programming stops the OS X Finder from giving the important and useful information that a user needs to fix the problem (and which OS 9 provided perfectly well). Not everyone has the knowledge to run 'lsof', and if it turns out no applications have files open, then quit the Finder as a workaround for a known bug, as I do several times a week. What do they do? Quit every open application in turn, and finally log out or reboot in desperation when it turns out that it's a DiskArbitration bug causing the problem?
That's the essence of my complaint: either the people who write the Finder at Apple have an incredibly high tolerance for flaky software, they don't use it at all, or are placed under pressure from management such that they don't have a chance to deliver quality software. Anything I write – for my own use, even – I would fix if it were as broken as the Finder is, and if it were heading for use by potentially millions of users, I'd feel incredibly guilty to subject them to such garbage.
This will be my last “OS X sucks” rant for the year. Time to affect what I can really affect instead: my own software.
11:48 PM
