I hate Macs

19 Mar

Continuing a discussion of desktop UI from the previous post. Be clear that most of what follows applies equally to Windows and the Linux desktops; my point is that Apple popularized these ideas and the others—-misguidedly—-still follow Apple’s lead.

Compared to Microsoft, I don’t especially begrudge Macs for their existence, and I do recommend them over Windows to naive users who don’t have anyone to maintain and set up their boxes for them. Still, it annoys me how many people have drunk the Apple koolaid and believe that OS X has anything on the basic Windows experience beyond gloss (and an ‘it just works’ quality earned only by a controlled, minute hardware and software landscape); just about everything beyond a few features of the OS X interface is just arbitrarily different from other desktops. Macs wouldn’t annoy me so except for how their influence perpetuates through fashion stupid graphical interface design ideas which both Microsoft and Unix desktops have slavishly followed. Contrary to popular opinion, Macs are not the end-all/be-all of usability, and in fact, Macs have long perpetuated some erroneous thinking about usability. There are several things seriously wrong with the desktop/windows metaphor, and Apple is responsible for most of them.


1) the metaphor of files and directories as physical objects

It’s not 1985 anymore.

Compared to the detailed list view of files, the icon view is a paragon of form over function. Not only should icon view not be the default folder view, there shouldn’t be an icon view. It’s flat out stupid. The browse-ability of a list of words is far superior to a grid of words (let alone stupid non-grid piles of icons). Yes, some users have trouble aiming the cursor, so give an option to make the lines a bit fatter. Problem solved.

Seriously, is there any point to files/folders as icons other than gee-whiz factor?

(Thumbnail view is fine, but it’s really a totally different thing.)

2) icons

Most things just can’t be conveyed pictorially (see earlier post, Why Icons Suck), especially with pictographs 1cm in diameter. To their credit, Apple has finally realized this and focused on making bigger icons. Still, Apple started this thinking, and many Apple apps still perpetuate illiterate, push-button design that values gloss over function.

3) allowing the desktop background to be used as a place to put icons and files rather than just a place to put wallpaper

  • First, this just creates clutter because it encourages people to just lazily dump their files there (I’m guilty of this myself).
  • Second, it confuses learners. I remember trying to explain Windows 95 to someone: ‘So the stuff on my desktop is in the C:\Program Files\Desktop\ directory on my computer…but isn’t My Computer on the desktop?’ Apple gets around this by generally keeping most users out of the real file system hierarchy altogether, but the desktop-as-folder still raises virtual-space disorientation: files on your desktop are also in your finder. So much for the metaphor of physicality.
  • Third, the existence of the desktop as a working surface necessitates a way to get at it quickly, like shortcut keys and OS X exposé. This added complexity wouldn’t be necessary if you got rid of the damn thing in the first place.
  • Fourth, the desktop serves cross-purposes: Apple and Microsoft encourage users to put application shortcuts as well as files on the desktop, meaning users are presented with the silly choice of whether to put application shortcuts on their desktop and/or in the start-menu/dock, and then later they have to remember where they put it, or at least make an arbitrary choice of which to use.

4) free-floating windows & 5) drag-n-drop:

Free-floating windows work against two basic facts:

  • In my experience, just about all real work is done with full-screen applications, but Apple seems to have something against letting you maximize windows. Just look at the screenshots here: http://www.apple.com/macosx/features/expose/ . Apple clearly thinks it’s neat to have non-maximized windows scattered artistically around the desktop, wasting screen real-estate, because it looks neat. [update: duh, bad example; that of course is the exposé feature in the shot; see the first shot here for a better example]
  • In the cases where I do want windows side-by-side, the scheme still takes a lot of work to get them that way, especially if I want to use my screen space well. And even once I have, say, two windows nicely side-by-side, switching between those windows and a third window is bothersome because I then have to make two dock/taskbar selections to switch back to the two windows.

Nearly as bad, Apple’s single-menubar design violates the classic rule against stateful interface: if a user momentarily forgets which window is active, they’ll get stymied when they go up to the menubar. (The way to mitigate this is to make the active window stand out glaringly, making it hard to not notice which window is active, but the standard OS X themes don’t make the active window stand out well at all).

What offends me most about the whole free-floating scheme is that it violates a principle: our interfaces should make the small annoying decisions for us; and allowing windows to float around overlapping each other violates that rule because it requires the user to make annoying random choices of how to get at the windows they want: shall I move or minimize windows to get at windows underneath? Shall I alt-tab directly to the window I want? Shall I use exposé? Shall I use the taskbar/dock?

The real promise of putting applications in free-floating windows—-the whole point of the idea—-is that users will be able to put applications side-by-side. This goes hand in hand with drag-and-drop because, for drag-and-drop to be efficient, the source window and destination window should both be in view. In practice, this is usually not the case because it takes too much work to arrange windows side-by-side to be worth the bother.

6) window activeness

I want to click on something in a window. Do I need to click on the window first, then click the thing, or can I just click the thing? I have to think about which window is active to know.

7) sub-windows and pop-up windows

It’s bad enough that applications are free-floating amongst each other, but then sub-windows of an application are allowed to free-float independently of each other such that it’s possible to have the windows of an application confusingly split-off from each other by windows of other apps. Naive users are confused by this arrangement, and as a knowledgeable user, I’m simply bugged that I’m being presented such a useless possibility.

Then we have further free-floating window pollution in the form of pop-ups and dialogues. Many people have pointed out how annoying it is to have your focus stolen by these mini-windows or to lose one behind other windows. Less commonly cited, though equally detrimental, is how their lack of attachment to a fixed space in the application degrades the user’s mental layout of the application. It’s always best for things to live in their unique place and stay there rather than to exist outside of space-time, as pop-up messages and dialogues seem to do.

8) redundancy between the menubar and toolbars

In most apps, the application menu bars are considered too cluttered and inaccessible by their designers, so shortcut icons to a selection of menu items are placed below the menu bar, e.g. the back button is a menu item in a web browser but also an icon below the menubar.

In simple applications, like web browsers, this redundancy is not so bad, but as the application gets more complex and the number of convenience icons grows (think Word or Photoshop), the redundancy becomes a nuisance to both newbie users and experienced users alike. For newbies, the preponderance of overlapping choices are confusing; for the experienced users, having to make the arbitrary choice of whether to look in the menubar or the mess of icons becomes mentally taxing.


The basic flaw with Apple design philosophy is that it chases the chimera ideal that users shouldn’t need to know anything about how something works before using the system, i.e. ‘users should only have to know what they already know‘. This made some sense back in the 80′s when computers were still totally mysterious and had limited functionality, but computers are such a presence in most people’s lives today that it’s absurd to think that users should never learn the most basic concepts of their use.

Imagine a hypothetical Apple iCar: users step into an enclosed space with no windows and press a button that takes them where they want to go; iCar users have no conception how the iCar does what it does—for all they know, it teleports rather than traverses through space. The iCar may sound nice and dandy, but its users are totally at a loss when the system fails to always work perfectly as real-world systems always do.

So ironically, Apple and Microsoft interfaces don’t live up to the ideal of discoverability because their solutions encourage naive users to remain naive and think of every interaction with their computer as ad hoc, i.e. perform such-and-such ritual to do x. When the rituals change even slightly, users are left totally helpless.

Even experienced users can run in to this helplessness. For instance, I tried helping my sister use her Olympus digital camera with her macMini, but when I plugged it in, it wasn’t detected—no error message, friendly or otherwise, no anything; Google searches turned up absolutely nothing. Apparently, Macs ‘just work’ except when they don’t, in which case there is no appeal, even for experienced users.

When I say users should learn basic computer concepts, I’m talking really basic, such as a working conception of file system hierarchies and what a program is. Apple and Microsoft have tried hard to obfuscate these basic ideas. Apple thinks they created a desktop metaphor in which people don’t have to learn such basics, but they’re only half right because their metaphors don’t scale, e.g. the ‘files as objects’ metaphor works fine when you only have a few files, but more and more non-technical users are using more and more files and they’re making a mess out of their drives as a consequence. Similarly, the more and more uses we have for our computers, the more it matters that users rely upon a conceptual understanding rather than a memorized set of particulars. An OS interface, then, should be judged on both the learn-ability and generality of its concepts, not the gloss with which today’s finite set of computing tasks have been presented.

A better desktop (and better desktop apps) would embrace a few design principles:

  1. Software shouldn’t be totally transparent to naive users the way Apple thinks; rather, the mechanisms of discovery should be simply well-established and omnipresent so that once learners have been educated about them, they can apply them consistently to the unfamiliar programs they encounter and explore as needed.
  2. Interface redundancy is a nuisance and makes software look more complicated than it is, thus discouraging users. A good interface doesn’t force users to constantly make small, random decisions the way that giving users 5 ways to delete/move/copy files and 5 ways to close programs does. (Redundancy between mouse and keyboard is a special case.) A good desktop would adopt a Pythonic, one-way-to-do-it philosophy.
  3. When thinking about use cases, be conscious of keyboard and mouse use. In general, there should be a keyboard-only way of doing most tasks, a mouse-only way, and perhaps a mouse-keyboard combo. In particular, strive for one-handed usability where possible [no jokes here!]. However, the best designs often take a strong stance upon whether a particular task is best accomplished with the keyboard or/and mouse.
  4. Contrary to Apple’s opinion, features should not be cut just because they’re not instantly graspable by novice users. The real solution is to put advanced features out of sight while still making them discoverable.
  5. The greatest virtue of GUI’s is that they generally have great discoverability while CLI’s have virtually none. Still, there is a lot to be said for the syntactic power of the command line. I don’t foresee most users doing any scripting, but I think there is a wider userbase for scripting out there if it can be made simpler than AppleScript (Pygeon may be a candidate here).

My next post will present ideas on how to actually achieve these goals (for real this time!).

5 Responses to “I hate Macs”

  1. Michael Salsbury March 20, 2007 at 6:40 am #

    Great post. I agree with just about everything you’ve said here. GUIs are definitely more disoverable then CLIs. Advanced features should always be available but hidden from novices. Users definitely should be made, beyond a certain point, to understand how the system works and not coddled by the OS to think it’s all magical. Icon view IS stupid, especially as the default setting, which it is in OS X.

    I think I disagree with you on the desktop not being a place to keep files and folders. While it does tend to get cluttered that way, it’s also a useful way to quickly get at files you need frequently or use at the moment. Microsoft took a step in the right direction with removing unused icons off the desktop automatically, but I do agree that there is probably a better way to handle this.

    I’ll be looking forward to your next installment.

  2. Nathan Spears August 3, 2007 at 11:18 pm #

    Astute observations. I like your idea that no ‘window’ should ever be less than maximized. I have tonight discovered launchy, which has in two hours made me realize how useless the start menu and browsing hierarchically is, and TaskSwitchXP, which although not perfect is a big improvement over regular alt-tabbing. After reading your posts on Macs and on Window Management, I want to bounce a couple ideas off of you.

    First of all, I think we both agree that the idea of the desktop as it exists now is broken. It doesn’t necessarily need to be but when people can be lazy and save documents on it, then they will. If you aren’t saving documents on it, though, what is it good for? Well, you can put shortcuts to programs or folders on it. Isn’t that what the Start Menu and Toolbars are for? You can put widgets on it. Isn’t that what the system tray is for? Basically (again as you state) there are too many ways to do the same thing which do not offer anything unique. Pick one and go with it.

    So. What I think the desktop and Start Menu/toolbar offer are essentially all the same things, with one important exception – the toolbar is the only place you can select from among your open windows. Of the time you spend interacting with the window management system, this is probably what you spend most of your time doing, which is why it’s so annoying that the interface is so poor/slow.

    So here finally are my ideas:

    1. Make the desktop a combination of the most useful features of Windows Task Manager, TaskSwitchXP, and the Start Menu. A significant portion of desktop real estate would be a list of running applications, which can be grouped, switched to, terminated, etc, directly on the desktop. These could be in a numbered list, allowing you to use a keyboard shortcut to type in the number.

    2. Make it easy to reach the desktop and obvious that this is where you now control things. There could be an ‘always on top’ button at the bottom of the screen for beginners, keyboard shortcut customizable. Personally, I would like to throw my mouse to the bottom of the screen to show the desktop, or bottom left to auto switch back to the last app. All configurable of course, but the default behavior should be almost as helpful as any customized behavior.

    3. Make (by default) every open program/folder its own “desktop.” That is, it uses the entire screen (except for whatever button shows the desktop). As you say, some people want you to believe that it’s nice to have small windows artfully distributed across the desktop, but when is it actually helpful? I like the way (for example) Pidgin looks, but I keep it minimized all the time so it doesn’t even matter. It shouldn’t be designed to look good small – it should be designed to run full screen and take advantage of all the available desktop when it’s being viewed.

    4. These ‘desktops’ can be combined when necessary – ie you want to have two word documents side by side. This solves your problem of having to click twice to bring them both back up. You would be able to either combine running apps into one desktop, or specify when starting a new one which desktop it would join. More on this in a second.

    So this leaves a couple questions about how users begin running applications in the first place, and how they interact with files and such. I propose that there be two hardlinks on the desktop – one to interact with programs, and the other to interact with user documents. Basically the My Documents link that’s currently on the desktop, and the Programs folder that’s currently in the Start Menu. However, these desktop links would be more akin to the easy sliding hierarchy of a toolbar folder than the annoying “open each folder in the same window” functionality of the current window system. In addition, there should be a file browser with almost the exact same interface as Firefox – tabs for different folders, a favorites or quick links system, etc. Basically whatever solutions we come up with to improve our internet browsing experience can be applied to our directory browsing experience as well. The nested hierarchy view as a sole interface is ancient and horrible. Probably this file browser I’m describing is ubiquitous in linux and I haven’t used it yet.

    So users wouldn’t be “allowed” to store their files anywhere outside of this My Documents folder (hopefully just Documents so we can have a spaceless path to root . . .). In addition, it would be nice if programs would create folders intelligently for themselves inside this Documents folder. For instance, let’s say that Microsoft Word had been intelligently placed inside of a Office (not MS) subgroup in the Program Folders. Then it’s default folder for saving files would be Documents\Office\Word unless the user specifies differently. Eclipse would use Documents\Programming\Eclipse\workspace, etc.

    And thus you can guess at the nature of the Programs menu – it basically looks like the default KDE start menu – applications divided into sensible subgroups. The only difference is that every program on the computer would be listed there, because it is the only way for you to launch them. Perhaps you left click on it for all programs, right click on it for favorites. Once you get used to Launchy it’s kind of irrelevant because you can type so much faster than you can use a mouse.

    The last thing I can think of to allow on the desktop is widgets. A clock, perhaps an IM widget. Or perhaps not. Maybe a good IM client uses transparency to good effect to show you new messages without interfering with your current focus. Anyway there must be some things such that you do not want to have to perform an action to see the desktop, another action to see the thing (eg clock) then switch back to the former window. So those things could get space on the desktop. Perhaps there is a shortcut to show the desktop, then go right back to the window you were in. Or maybe a key to make your current window temporarily transparent so you can see the desktop through it. Amounts to the same thing I guess.

    So to review: there are two branching links to programs and documents, the TaskSwitchXP-like list of running apps (configurable of course for power users, ie processor usage, perhaps a separate section listing processes ala top), and any widgets configured to run on the desktop that don’t imitate or duplicate the functions of the previous items, and have some good reason for being on the desktop.

    What do you think? I think this would actually work pretty well with many of the ideas from your portal system, although there is some overlap in the ideas about how to display running apps for selecting among them.

    We agree on the fact that it should be easy and quick to switch between running applications. All my ideas about keyboard shortcuts apply as easily to your system – eg you could have a key shortcut to show the menu and a numbered system for selecting among them. As I look around I become more convinced that I haven’t seen any of your ideas about what should actually be on the desktop instead of all the clutter that’s there now. I realize the desktop is an illusion – a de facto full screen window to give users a warm fuzzy that their computer is ‘there’, but I do think it’s too valuable not to keep around and use it as well as possible.

    Oh, something else I was going to add about program launching – let’s say you click on the program menu and want to start a program in the same window as another running app. So you drag it out of the program menu and onto the app you want it to share space with. There’s no reason to assume that dragging an app means trying to move it from folder to folder in the menu – in fact whenever I do this now it’s by accident, so let’s remove that possibility and put the move functionality somewhere else entirely – an ‘edit menu’ somewhere. There are probably other possibilities for dragging programs onto the desktop (which starts them running) that I can’t see right now. Maybe you’ve got an applet such that when you drag an application onto it the applet asks for password and runs the app as root.

    Man, you really got me typing.

  3. Brian Will August 5, 2007 at 10:09 pm #

    Thanks for the reply Nathan.

    In my Portals design, I’m not yet sure if file browsing is a privileged component or treated just as a regular program, so I didn’t include it in my Portals mock-up. Still, I’m quite confident I don’t want to mix files and programs together in the Portals analog of the start menu. To me, that just seems like a band-aid over poor file browsing, and it’s just another redundant mechanism. In contrast, the reason users don’t go into the file browser to click on .exe files is because those files reside in program directories, the structures of which most users don’t care to deal with or memorize. So you’re right users generally want to deal only with their own directories rather than Windows, Program Files, and so forth. A user home directory is of course the Unix solution, but I’ve never really liked this scheme as I always want to control which drive I’m storing my files to, and often it feels inappropriate to file things under my name. If I store something, why should others have to think to look under my username?

    A better kind of file browser is something I’ve worked on in the past and actually written some of in Java. It combines search-based navigation with tabbed-browsing. Unlike other search-based files, it only indexed the file and directory names, not the contents. This is less sophisticated than what Google Desktop gives you, of course, but I think it’s actually more desirable to only get directory/file name search results. So users could enter the query, say, ‘dog’, and get back a pulldown list of all paths to directories and files where the file or the last directory starts with ‘dog’. Or you could enter ‘dog cat’ and get back all paths containing both dog and cat while ending in a directory that starts either ‘dog’ or ‘cat’. The idea was to eventually have this work more like tab completiong, but I didn’t get around to that. Rather than have tabs, the user saw a list of the last several paths they selected. Users could click on the path to go back to that directory, or they could click on one of the parent directories in the path to go to that parent directory. So if you have the path ‘c:/foo/bar/dog/’ in your path, you could click ‘bar’ to navigate to ‘c:/foo/bar/’; the path wouldn’t change except you’d see the ‘c:/foo/bar/’ portion highlighted; this way you could move back and forth between two related directories.

    Anyway, your ideas do sound interesting, but I must say it’s hard to follow just from a description (just like my example above must have been). If you want someone to take your interface ideas seriously, it’s always best to produce some kind of visual mock-up. It doesn’t have to be interactive. A few pictures go a long way.

  4. DvS November 12, 2007 at 1:56 pm #

    Sounds like you’ve got UI retardation.

Trackbacks and Pingbacks

  1. brian will . net » Portals: window management for those who hate window management (mockups in Javascript) - July 17, 2007

    [...] major design goal of my desktop UI design, which I’m calling ‘Portals’. Back in this post in March, I promised to present the Portals design, but I never quite finished the mockup demos in [...]

Leave a Reply