But in 2006, after a half decade of using Windows XP, I concluded that the new Vista OS was not the best fit for my computing expectations, and my upgrade path ended. After exploring various Linux distributions and OS X, I decided OS X as it was finally met what I wanted from an OS.
I love this OS. I made that quite clear already. But there are some deep flaws with this operating system that disrupt my workflow.
Here's my list from last year, as it was as of October 28, 2008, because sometimes it feels as though all those years of feedback form suggestions to the Apple team just aren't getting through. Feel free to add valid UI-related issues of your own. Here we go:
1. File menu in dual monitor displays
If you are working on the right-hand monitor but your file menu bar is on the left-hand monitor, then it's a pain to keep mousing over between monitors. This is an example where the one menu bar per application model of Windows beats the fixed universal menu bar philosophy of the Mac.
Workaround: Third-party application DejaMenu tries to compensate for this by providing a contextual file menu for the monitor lacking the file menu bar, but navigating nested options in a contextual menu is not as convenient.
2. Cannot keyboard-cycle between thumbnails of images in Preview
When you open an image in Windows with the default Preview viewer (Windows Image and Fax Viewer), you can keyboard left and right to view other images in the same folder. This behavior has been present since Windows Me and Windows 2000. This behavior is not the same in Finder as it is in Windows Explorer.
Workaround 1: The way to do this in OS X's Preview is to open all the images so that they appear in your drawer. This is, of course, a different way of doing things, but it's not ideal by my standards.
Workaround 2: If you're just previewing, view one file with QuickLook (Spacebar), and then use the arrow keys to preview neighboring files in the folder. This is available on OS X 10.5 Leopard or later.
3. Folders don't group first and separately from files in Finder when sorted by name
When sorting by name, folders appear among files, instead of being grouped first by themselves. You'll see this kind of behavior if you run the UNIX
ls command in a terminal. This is all preference, of course, but having come from Windows, I'm used to being able to move up and down a hierarchy of folders quickly because each next nested folder lists all enclosed folders grouped at the beginning, so that I don't have to scroll to find them.Windows:
A Folder
C Folder
B File
D File
OS X / Unix:
A Folder
B File
C Folder
D File
Workaround 1:
The next best thing is to sort by "Kind" (except that folders sort according the letter "F"), and then in edit the InfoPlist in Finder by using Terminal, running:
cd /System/Library/CoreServices/Finder.app/Contents/Resources/English.lproj
sudo chmod 777 InfoPlist.strings
sudo chmod 777 .
open InfoPlist.strings
This will open it in a text editor. In that file, where it says "Folder" = "Folder", change it to "Folder = " Folder", where there's a single space before Folder. Save the file, and then Control-Option-click on the Finder icon in the dock and select "Relaunch". In list view, the "Kind" column text for folders should be updated to "Folder" with a preceding extra space.
Workaround 2: Path Finder
Of course, what would be ideal is to show the folders alphabetized first, and then the files alphabetized. For now, we'll just have to live with it, or rely on third party apps like Path Finder.
4. No function to restore Trashed items back to original location
After files have been deleted, there is no function to restore them all to their original locations as in Windows.
Update 12 Feb 2009: It appears OS X 10.6 Snow Leopard is going to finally provide the ability to restore trashed items to their original locations, known as "Put Back". Apparently, this functionality was available in OS 9 as "Put Away". Why they took so long to restore this function is beyond me.
5. Behavior of the window shade prompt from the title bar - no tabbing and resizing from the center
While I appreciate the attempt to attach a prompt to the title bar to associate each dialogue window more closely with the window being referenced by the prompt, there are a couple things that it misses.
Firstly, you can't hit the "tab" key, or any key for that matter, to focus on a different button (Yes/Not Now/etc.) by keyboard shortcut. (Note that, for confirmation prompts detached from the window, you can tab/spacebar to focus and select by keyboard alone. There's no logic for this inconsistency between detached and attached windows.)
Secondly, when dragging the corner to resize a larger dialogue window (such as selecting a file to upload), it resizes from the center, so beyond a certain point, the left side of the window is going to expand to the left beyond the edge of the screen. To see what I mean, open, say, TextEdit and try to save the document to pull down the window shade prompt. Now resize the prompt larger horizontally, and you'll notice the left side falls off the screen. What would make more sense is if the prompt resized from the left corner as an anchor, so that it's impossible for any of the prompt to fall off the screen while dragging, even if pulling the lower right corner to its maximum reach.
Additionally, because the window shade is fixed to the title bar, there is no way to move the dialogue box aside to reference content underneath for, say, deciding what to name a file, or which files to upload to a post.
6. Ability to resize windows from the four edges and other three corners
In OS X, you can only resize from the lower right-corner of the window by clicking and dragging a standard visual cue suggesting it can be dragged. This allows for the essentially border-less look of the windows in OS X, which works very nicely in tandem with the window drop shadows. The problem is that if that corner is ever out of view, say behind a window or off the edge of the screen, you need to first put that window in focus and move it within the viewport before being able to resize it. It arguably reduces the flexibility of resizing. For example, if I think the vertical size is perfect, I can safely perform a fixed horizontal resize in other operating systems. But in Mac OS X, you need some precision with your cursor to perform the same task.
This one's a common complaint of users crossing over from other OS platforms. You could try to argue that the drag handle on the lower right corner has a larger clickable area than a border, but in all my years using Windows, and seeing others use it, this is not really a real life issue, even for those with lesser mouse precision. The other main argument is that window resizing is allegedly an infrequent task. And while I've gotten used to the OS X behavior, the OS X use of window "zoom" instead of "maximize" leads to more resizing.
Update 2009 April: It turns out that it's rare for cases where the window drag handle on the bottom right corner will fall outside the screen edges. I've had applications like iTunes occasionally exhibit the issue, but given that how it was essentially impossible to manually reproduce the issue (I tried resizing on the larger resolution monitor in dual monitor mode, but it would auto resize appropriately to fit the lower resolution once dragged over.), I would say this is more a tiny annoying corner case than a widespread problem. Still, they are real world behavioral problems.
Workaround: For now, one of the best options is to use third party application Zooom/2, which allows you to resize from the inside of a window with a combination of clicks and modifier keys, among other things.
7. Files in folder re-sort immediately while renaming
When renaming a folder full of alphabetized files, the files sort themselves immediately after each rename. In Windows, the files do not sort until a folder reload, usually manually. This kind of sandbox working environment makes mass file renaming (such as with photos) much easier, especially if you want to visually reference the file you just previously renamed. In OS X, that previous file has already been thrown somewhere else in alphabetical order. Currently, the fix is to sort the files by "modified date" temporarily, since that part doesn't change when a file is renamed. However, you also sacrifice working in an alphabetized state, which you might have wanted while renaming.
When copying a folder to replace another with an identical name, it replaces files inside instead of merging the contents
In Windows, when you 'replace' a folder, it merges the different contents, and asks you if you want to replace when there's a duplicate. In OS X, when replacing a folder, it literally replaces the folder by deleting the original and copying over the new one. This is cleaner and truer to the 'replace' definition, but I still wish there were a merge function built into OS X. For example, I often merge two folders with an abundance of family photos. I want the ones that weren't there to be copied over, and the duplicates to remain untouched.
Workaround: To get around this, you have to sort by one of the columns in list view that will not change upon renaming. Columns like "Size" and "Date Modified" will do this, but of course, the files will no longer be sorted alphabetically by "Name" as you're renaming files.
8. Hitting 'Enter' key on a selected file renames instead of opens
In Windows, I was used to being able to navigate within a folder using the keyboard arrow keys, and then hitting the "Enter" key to open it. But in OS X, this same action puts you in rename mode (equivalent to F2 in Windows). To open the file with your keyboard, you have to use Cmd+O or Cmd+down (the counterpart to Cmd+up - one folder level up). Or you could always sacrifice keyboard shortcut speed and resort to the mouse double-click.
To me, assigning the "Enter" key to open a file and folder makes far more sense, considering that the "Enter" key is associated with initiating the execution of a task in many interfaces, such as submitting a form. But more importantly, opening a file or folder is a far more frequent task than renaming, which leaves me wondering why the more common task was assigned the modifier keyboard shortcut.
Workaround: Unfortunately, this doesn't seem to be one of the configurable keyboard shortcuts from "Preferences". There's a third party application that does the job, called ReturnOpen, but this one forgets to reassign another keyboard shortcut for rename in its place. Otherwise, I recommend using Cmd+down over Cmd+O because of the proximity of the right-side Cmd key and the down arrow key.
9. Holding "Shift"-click on the first and last items does not select a sequence of items in icon view (as opposed to list view)
In many user interfaces, holding the "Shift" key while clicking a first and second item will select everything in between. This is the case in Finder in list view, column view, and Cover Flow view, but not in icon view. And this is where it differs from behavior in Windows Explorer. Now, perhaps someone thought that since icon view is the only scattered view, unlike the list-based views of the other three, there was no file sequence analogy. Yet, Windows handles this just fine, whether it's on the desktop or within a folder's windowed view.
Workaround: Toggle back and forth between list/column/coverflow view and icon view to perform a Shift-click selection.
10. Cannot rename/delete/manage files in Open/Save dialogues
In the dialogues that appear when opening or saving a document, such as from a text editor or image editor, pretty much the only file management function you can perform is to create a new folder. In Windows, you essentially have a full blown Windows Explorer session in an open/save dialogue, so you can move, cut, copy, paste, rename, delete, or anything else possible with your files and folders. This way, you can, say, move or rename an original copy of the file by the same name before saving your file.
Workaround: (No suitable workaround found yet).
11. Desktop items have no option to sort by latest file added while icons arranged
There is no effective generic auto-arrange feature for your desktop items to arrange themselves neatly into a grid (without spacing and without re-sorting).
Or to put it another way:
In Windows and OS X, if you save new items to your desktop, it takes the next open spot on the desktop icon grid (under the condition that it's set to "auto-arrange" on Windows and "snap to grid" on OS X). In OS X, new icons accumulate from the right to left, and in Windows, from left to right. Now try moving a few files to a spot in the far from the cluster of icons where there are open spaces. (In Windows, switch off auto-arrange before doing this.)
If you want these outlying file icons to cluster back at the end of the original group of files, you can "auto-arrange" again in Windows, but in OS X, the closest action is to "Clean Up", which simply snaps them into alignment with the grid, but keeps them in their outlying areas.
I can see the logic intended behind keeping the file icons in place, but this can get messy if any of these icons start getting placed outside of the viewport. This happens two ways - either from bulk movement of files on the desktop, or from switching back and forth between external/dual monitors with different screen resolutions.
And why is it messy? With auto-arrange, it's very clear which files aren't visible in the viewport. You're not left wondering if there's a random file hidden outside of the confines of your currently visible desktop, without having to first auto arrange or check the desktop in a folder.
Now, both operating systems allow you to auto-arrange with sorting. So OS X does auto-arrange when you sort by name, date modified, etc. But the whole point was to keep the desktop unsorted. Arranging by "Date Modified" on OS X is the closest workaround, but "Date Modified" isn't always the same as which-file-just-got-dumped-onto-the-desktop.
Oddly enough, "stacks" in the dock in OS X Leopard do allow a sort by "date added" in addition to the existing "date modified" and "date created".
Between the OS X "Clean Up" option and auto sorted arranging, it's almost as though they forgot to throw in "auto-arrange-as-is".
Workaround: (No suitable workaround found yet).
12. Minimized documents in the OS X dock
(This item was updated in March 2009 to include Windows 7.)
I have mixed feelings about the dock itself, as many users do. There are many areas where it shines, though I'm not going to outline them here. My focus right now is on the subject of minimized windows in the OS X dock. In OS X, finding non-minimized windows is done by using Expose (dynamic proportionately-sized thumbnails with titles), which is a well-executed visual multitasking feature. There is a downside to this, which I'll return to in a bit. Non-minimized windows, on the other hand, only appear on the right-side of the dock as thumbnails with no titles unless hovering over.
Now take the Windows taskbar. Up until XP, it was solely text-based, and each document (minimized or not) had its own taskbar representation. Expose shines where the difference between documents is more visual (masses of images or webpages with similar names), whereas the taskbar shines more with documents are visually alike (text documents or command-line terminals with descriptive titles).
Expose still works great with the latter, given that you only have a few of these visually-similar documents open. But beyond that, it starts to fall apart, but not nearly as badly as a row of similar minimized document thumbnails in the dock with text labels upon hover. Furthermore, as helpful as Expose is, I still find it a bit odd that open non-minimized windows do not have individual document representation on the dock. But then again, the OS X dock solely groups these open documents by application. Just right-click on Finder or Safari or Firefox or TextEdit to see the list of open documents. This seems to be the route Windows 7 is taking, except with thumbnails, but I will get back to that too.
Unlike the OS X dock's group-by-application approach, the current Windows taskbar instead displays a taskbar for every document, regardless of application. Vista added thumbnails to mouseover'ed taskbar items, which is helpful, as well a 3D diagonally oriented Expose that displays the upper and left slivers of the preview (not as helpful). The closest thing Windows has is grouping by application after a threshold number of documents are open (in XP), which makes Windows a hybrid. And here's where I get back to Windows 7. I want the best of both worlds, and if individual document representation makes it to the Windows 7 release, and goes hand-in-hand with the grouping by application, this may be closer to what I've wanted all along.
13. Merge and Replace
This one has to be one of my top gripes with OS X. I left this for last because this one's a bit more complicated as to which one's doing it right. In Windows XP and its predecessors, if you copied a folder's contents into an older copy of that same folder, it would tell you, "This folder already contains a file named 'Photo1.jpg'.", with the file sizes and last modified dates of both of the duplicate file names. OS X only gives you the name, "Photo1.jpg", which leaves me severely handicapped in deciding whether I want to replace it with the newer copy.
The only redemption OS X has here is that they display an explicit "No to All" option through its "Apply to all" option for "Replace"/"Don't Replace". In Windows, seasoned users will know the hold "Shift" while clicking "No" to achieve the same effect, though I've wondered over the years why the "No to All" option wasn't displayed when the "Yes to All" option was.
Nevertheless, the OS X file replace issues do not stop there. The bigger problem is that if you're instead copying an entire folder to replace a folder by the same name (Folder1 into ParentFolder, which has a slightly different copy of Folder1), OS X will only prompt you to wipe-and-replace, leaving you with none of the contents of the original folder. Windows, on the other hand, copies over all files into the original folder, and prompts about any duplicate file names. This is effectively a merge. Windows Vista took this one step further and actually provided both the options of "Replace" and "Merge and Replace", easily one of my favorite features of Vista.
The argument behind the full wipe-and-replace by OS X Finder is that it's a true analogy to "replace". All right, but Vista corrected that by finally distinguishing between "replace" and "merge and replace". Sure, merging can be far messier, but if users are performing a manual sync of family photos or work documents in folders, they're in for a nasty surprise in OS X if they're not paying attention.
Workaround: Path Finder
Yes, Path Finder again. I can only hope Finder gains some improvements in the near future.
Update 12 Jun 2009: Screenshots of OS X 10.6 Snow Leopard indicate there will be some level of merge options. It's also worth mentioning that the UNIX command
ditto comes in handy too if you're on older versions of OS X.
There are plenty of neat ideas in both operating systems. What I want to see is for people to get their preconceptions behind them, embrace changes outside their comfort zones, and pick out the cross-ideas that are being overlooked. It's in all of our best interests. Thanks.
-Gordon
Posts
