I’m a programmer but the same is true for anyone who works primarily in one large application. For instance, for designers it might be Photoshop or QuarkXPress. For writers it may be Microsoft Word. For business folks it could be Excel. We all need a web browser open and we all need our main productivity app. On Windows and Linux these days, this just works. You plug-in two monitors. You open two apps. You move between them as you feel like it, and do your work. This is what it looks like:

On the Mac, however, it doesn’t work. The Mac, which was perhaps the first platform to support multiple monitors, certainly the first consumer platform, a two monitor setup looks like this:

Do you see the difference?

The problem is that the Mac always and only puts the menubar on one screen. That means using any app on the second screen means constantly redirecting your attention back to the first screen. Furthermore, you have to constantly move the mouse between screens, rather than just slamming the mouse to the top as Mac users are accustomed to doing. It may not seem like much, but after you’ve grown accustomed to a multiple monitor setup on Windows or Linux, trying to use one on the Mac is jarring. Not only does it not just work. It just doesn’t work.

The solution should be simple: put a menu bar on each monitor, at least optionally. The menu bar can even be disabled until the app is focused with a click. Why Apple hasn’t done this, I don’t know. For single screen computers, the Mac still has by far the most efficient menubar design and the best multi-application UI ever invented. Windows and Linux still haven’t caught up with where the Mac was in 1984. A menu bar belongs at the top of a screen, not the top of a window. But unfortunately the Mac doesn’t put a menu bar at the top of a screen. It puts the menu bar at the top of one screen, and that makes all the difference.

A few applications can actually use multiple displays for their own needs without the single menu bar approach crippling the user. For instance, PowerPoint can show the slides on one display (typically a projection system) and speaker’s notes on the other (typically a laptop). The key here is that such applications are tiling a single application across several monitors, and are designed for this environment. However this is rare. Most applications are designed to run on a single screen, and can’t really make use of a second monitor. To gain extra productivity with extra monitors, you need to be able to show different applications on different monitors and still have each application be fully functional.¹ Without that ability the second monitor is just eye candy. In fact, maybe it’s not even that. I’ve never even found something as simple as a slideshow program or screensaver that can take over one monitor without blacking out the second.

Virtual desktops are not a solution either. The goal is to be able to see the web browser and the IDE (or whatever applications you happen to want to run simultaneously) at the same time, not merely to be able to switch back and forth between them. The eye can move faster than mouse, and sometimes that’s important.

I suspect this problem just wasn’t obvious circa 2000 when the last major refresh of the Mac UI was contemplated. At the time, multi-monitor setups were still rare and pricey things. However it’s 10 years later now. Video cards that support multiple displays are stock equipment in every Mac, and large flat screen monitors can be had for the price of a nice meal in Cupertino. It is well past time to fix this. Until Apple does, the Mac is, at least in this respect, a distinctly inferior platform for software development, photo editing, page layout, spreadsheet analysis, and other tasks that require a large, full-screen interface.

Further Reading

• Does More Than One Monitor Improve Productivity?
• Multiple Monitors and Productivity
• Multiple LCDs
• Joining the Prestigious Three Monitor Club
• The Large Display Paradox
• LCD Monitor Arms
• The Virtues of a Second Screen

1 We could also envision running different instances of the same application on two or more monitors. However most modern applications such as Firefox and Eclipse have too much implicit global state to make this feasible.

In the future, here’s how shutdown should work:

1. You flip the power switch.

That’s it. No shutdown menu item. No wait for the system to hibernate. No opportunity for applications to save data. Nothing.

Then, when you turn the power switch back on, the entire system is restored with all data, windows, and programs intact (optionally after typing in the usual username/password credentials.)

In 2009 there is no excuse for an application to lose data because it hasn’t been recently and explicitly told to save. Nor is there any excuse for an application to block the system from shutting down. When I turn my computer off, it should go off, and when I tell an application to quit it should quit. More to the point, the operating system should forcibly terminate that application. I am thoroughly sick of applications that think File/Quit (File/Exit for Windows users) is a suggestion. It’s not. It’s a command, and one they should immediately respond to.

Few applications today get this right: not on the Mac, not on Windows, not on the Web. (Web apps such as WordPress do actually get a little closer to this, but many still launch popups telling you you may lose data if you close a window. There should be no such popups because they shouldn’t lose data, ever.) Firefox helpfully offers to restore all the open windows when the applications is relaunched, including after a force quit. More applications should do this. However even Firefox occasionally gets wedged and refuses to quit when told to.

There are actually a few steps to reaching this simplified nirvana, so maybe I’m asking for more than one thing here. Most laptops and applications can handle a system going to sleep. We just need to make sleeping a little faster (or at least less intrusive to the user) and possibly hook that up to the power switch in the hardware.

However, when waking from sleep, the operating system restores each application to the state it was in previously. We also need to make sure that applications are ready to be terminated with extreme prejudice in circumstances where the operating system will not restore their stack and heap. In such circumstances a character or two of data loss may be acceptable, but no more. Applications should save constantly to persistent storage without waiting for the user to tell them to do so. Furthermore, when writing complicated data structures they should maintain integrity even when they’re interrupted in media res. The techniques to do this are not complicated are hard to understand. They have been implemented by server software like Oracle for years now. We just need to demand the same sort of reliability from our desktop software.

A little more bleeding edge (but only because no one has bothered to do this yet) applications should maintain data integrity even in the face of flaky and unreliable hardware. Filesystems should not be tied to any particular physical drive. (No, RAID helps but doesn’t quite achieve this. RAID controller failures still cause data loss.) Better operating system support and more abstract filesystems that aren’t tied to particular disks would help here. However in the absence of this, applications could still store their data across multiple file systems, and they should do this without asking the user where to save or how to configure the disks. (Whether a traditional hierarchical file system is still the right metaphor for storage is a subject for another article.)

We take too many things for granted merely because that’s the way they’ve always been. But what made sense in an era of 64K floppy disks that could write a hundred bytes a second no longer makes sense in an era of terabyte hard drives that write a hundred megabytes a second. It is time to make saving files as obsolete as remembering to fill your fountain pen.

By contrast, non-monopoly sites like Office Depot have long since learned that registration is an optional step they shouldn’t let get in the way of completing a sale. But the utility companies? Either they hire developers who are distinctly behind the state of the art, or they just don’t care because you have to pay them, or both.

How easy should it be to pay a utility bill online? It’s a form with about four or five fields, no more:

• Account number
• Credit Card Number
• Expiration Date
• Name on Credit Card
• Amount to pay (this one could even be autofilled based on the account number.)

Unlike an online store, they shouldn’t need to ask for a shipping address. Maybe they need a billing address (though that should default to the service address) or the CVV2 code, but utility bills are unlikely to attract the same sort of fraud that online stores do, so I’m not sure even that’s necessary.

They absolutely don’t need:

• Your e-mail address
• A username
• A password
• Service address
• CAPTCHA (They really think someone’s going to set up a bot to autopay utility bills?)
• The city where your mother was born. (No I’m not making that up. Cox really wanted that piece of information.)

Account number, minimal credit card (or debit card) info, amount to pay. That’s all.

1. Ubuntu failed to find my DHCP server automatically. I had to reconfigure the network after logging in.

2. The install image is missing about 50-80 megs worth of patches. It’s one thing not to ship new CDs to every store on the planet and recall all existing stock. It’s another to serve an ISO with known security holes from your website. Critical (and even non-critical) patches need to be rolled into the primary release ISOs.

3. Ubuntu still doesn’t believe there’s such a thing as a widescreen monitor. Trust me: they exist. I’ve had one since the late 90s. In this release, Ubuntu has actually gone backwards. It used to be you could configure new screen resolutions with some Unix text arcana, but Hardy Heron has hidden all that info in some new location I’ve yet to ferret out. They’ve replaced the text files with a GUI screen resolution tool that doesn’t actually let me set the screen resolution. I’m not opposed to GUI configuration tools–I prefer them in fact. However they have to be at least as powerful as the text files they replace.

4. The menu system hasn’t changed in years. It’s still the same disaster it was 3 years ago. When is Gnome going to realize what Apple’s known for 25 years, and even Microsoft has known for ten:

Menus belong at the top of the screen. You don’t show more than one menu bar at a time. Menu bars need to be consistent between applications. There’s always a File menu on the left, closely followed by an Edit Menu. The Help menu goes at the right, sometimes preceded by a Window menu.

I guess when your view of the world is a command line, you don’t think GUI menus matter all that much; but to anyone who’s not a programmer they do.

Ubuntu actually does put the main Ubuntu menus at the top of the screen where they belong. The problem is that it reserves that place for itself and won’t share with other applications. No matter which application you’re working in, the menu bar only has Places, Application, and System. If I’m editing in OpenOffice, I want to see the OpenOffice menus there. If I’m browsing in Firefox, I want to see the Firefox menus there.

Apple and Microsoft both do better here: Apple by taking a single menu in the bar (the Apple menu) for its own use while leaving the rest of the menu bar free for the application; Microsoft by making use of the bottom of the screen for its system menus while leaving the top free for the application. Ubuntu/Gnome seems to be doing cargo cult UI design. They sort of know that menu bars belong at the top of the screen, but since they don’t understand the reasons why that is so, they end up making matters worse.

On the positive side, I’d say the fonts do look better in this release. That was a major sticking point for me in previous releases. Other notable improvements include a smoother, less technical install process, and a bootup that doesn’t spew random techie gibberish all over the screen. Ubuntu is improving. If only they’d fix the menu bars, and make it work with widescreen monitors, I could think about letting my parents use this.

To summarize, here are the critical differences between the two platforms. These are worth keeping in mind when you’re designing a cross-platform application such as Firefox or Limewire, or any web site.

The Maximize Button

On Windows the maximize button fills the screen with the current window. On the Mac it doesn’t. First of all, the Mac sets aside space for the menu bar at the top and usually the dock at the bottom. However, even taking that into account, the maximize button still does not expand the window to fill all available horizontal space. Users browsing on Macs rarely if ever have browser windows expanded to the full screen width. Doing so requires manual dragging and positioning of the mouse. Consequently designing a site for a specific resolution such as 1280×1024 will break the site on Macs with precisely those specs. Even if a Mac user sets their display resolution to match your requirements, they still won’t be able to handle your page. Window size is not the same thing as screen size. Do not design as if they were. Window and screen size are only loosely coupled, especially on the Mac.

Maximized Windows

On Windows, a maximized window cannot be dragged to the other monitor. Neither can it be expanded or contracted by dragging the edges. It is locked to one monitor and its size.

On the Mac, even “maximized” windows can be expanded, contracted, and dragged. It is possible to “over-maximize” a window by dragging it across more than one monitor. (You can do this on Windows too, but only if the window is not maximized.) You can even overmaximize a window on a single monitor system by dragging the window partway off the monitor while leaving the grow box visible. Programs that resize windows for the user need to be very careful that they don’t exceed the screen bounds.

The Menu Bar

The top menu bar on the Mac is clearly its single biggest weakness in multi monitor setups. In Windows, you can freely switch between two applications on two monitors while keeping both visible. Each is fully and independently functional. However on the Mac there’s only one menu bar, and it only lives on one monitor. You can show two windows on two monitors but you can only really work on your primary monitor because that’s where the menu bar is. You can use the second monitor for reference documents or simple games. However any program that needs a menu can only effectively live on the main monitor. This is a huge disadvantage compared to freely switching between menus as on Windows. (The exceptions that prove the rule are Parallels and VMWare. If what you have on the second monitor is a Windows program, then it does have its menu bar, and you can effectively task switch between two apps on two monitors.)

Linux

Linux is once again trailing far behind. I tried to install the latest version of Ubuntu on my pretty standard Dell PC with two regular aspect Dell monitors, and all it could do was mirror them. It could not use them as dual monitors. I’m sure with a few hours of research and forum posting, I could have found some XF86.config tweaks that would have made it all work, but I didn’t have the time. These days Windows and the Mac both “just work” with dual monitors. I remain dually astonished at Linux: on the one hand that it still clearly isn’t ready for prime time on the desktop after all these years, and that nonetheless people seem to keep insisting that it is. This was hardly the only significant flaw I found within ten minutes of popping in the live boot CD, though it was the worst.

Bottom Line

It’s been claimed repeatedly that developers (and presumably other knowledge workers) are much more productive with multiple monitor setups. I suspect that’s true, but only on Windows. Mac and Linux users are better off blowing their money on one really honkin’ big display than on several somewhat smaller displays.

Nonetheless, many applications persist in creating pointless, incomprehensible toolbars. Icon design is hard. It is not something that just any art school graduate with mad Photoshop skills can accomplish. Icon design is about conveying an idea with pictures. not merely making a 32×32 bitmap look pretty. It’s hard enough coming up with a good icon for basic actions like cut and paste. Now try imagining one for “Analyze Module Dependencies” or “View Breakpoints”. There’s a reason Susan Kare gets the big bucks.

Lately, this trend seems to have seeped into menus, where text used to rule supreme. For instance, look at this File menu from IntelliJ IDEA 6.0:

Not only do the icons add nothing to the menu items. They actually make the menu harder to scan and read because the items are no longer left aligned.

By contrast consider this File menu from Firefox:

Notice how much cleaner and easier to read it is? The eye can scan straight down the left hand side looking for the item it wants. There’s a reason books, newspapers, and websites all use left aligned columns.¹

Swing is partially to blame here. The Action interface encourages programmers to add icons to every action, and then displays those icons in the menus and the toolbars. However icons only belong in toolbars, not menus. Swing should be configured to never show icons in menus. I suspect Swing is merely trying to support a bad user interface design from Windows and Linux. I could be wrong, but off the top of my head I don’t think I’ve ever seen a native Mac app make this particular mistake.² However, on Windows and Linux/Gnome it’s endemic.³

If you simply cannot resist the urge to add icons to your menus, at least do this: add icons to every item, even blank icons if you must, to make sure all the menu items are properly left aligned. Gnome gets at least this much right, as shown in this File menu from the Gimp:

Windows gets this right too, and properly aligns the text even when some menu items have icons and some don’t. Java apps are really the odd ones out here.

But really, icons don’t belong in menus and never have. Menus are for text. Toolbars are for icons, and you shouldn’t mix the two.

² The Finder actually does display icons in some of its optional menus: Script, Input, and Accounts. The Input menu at least has the excuse that a potential user may not be able to read the text but can pick a flag. However the Script menu has no excuse. In all three cases, the Finder misaligns the menu items.

³ I don’t use KDE, so I don’t know if it shows up there too. Anyone happen to know?

I’m not sure his analogy really holds, but I’m not sure it doesn’t. His conclusions are correct, even if his reasoning and/or evidence turns out to be faulty.

He makes a good argument that SWT is the right way to design a cross-platform GUI, and Swing is the wrong way. The problem here is that empirically Swing delivers more native cross-platform apps than SWT does. When theory clashes with experience, either the theory is wrong or there are factors not accounted for in the theory. I suspect the latter here.

Let me quote here from Apple:

Pressing the Home key is equivalent to moving the scrollers all the way to the top and to the left. In a text document, for example, pressing Home scrolls to the beginning of the document; in a spreadsheet, it may scroll to the beginning of the spreadsheet or to the beginning of a row. These keys should also work in scrolling lists to display the top or bottom of the list.

End is the opposite of Home: It scrolls to the end of a document.

If the beginning or end of the document is already reached, pressing Home or End produces a system alert sound. Pressing the Home or End key has no effect on the location of the insertion point or selected data.

Many applications, however, including some otherwise consistent programs such as Microsoft Word for the Mac and Firefox get this wrong. Usually they move to the beginning and end of the line rather than the document. They may also move the insertion point.

Mac native programs like BBEdit and Safari usually get this right. Misbehaving applications usually derive from Windows code bases. On Windows the convention is different. On Windows the Home key is supposed to move the cursor to the beginning of the line and the end key is supposed to move the cursor to the end of the line. Control-Home moves the cursor to the beginning of the document and Control-End moves the cursor to the end of the document. That is fine for Windows applications but it is not fine for Mac applications, not even Mac applications ported from Windows. It confuses users and causes your application to feel un-Mac-like.

It’s not hard to get this right, and it’s a really simple thing to do. I suspect it’s so commonly done wrong just because it’s so small that most developers overlook it. You’d notice immediately if the close button on a window were a black X instead of a red lozenge, but who even thinks to check where the Home and End keys put the user? Nonetheless, it is significant, and it is worth fixing.

When writing a Mac app please remember:

• The Home key moves the view to the top of the document.
• The End key moves the view to the bottom of the document.
• Neither key moves the insertion point.

Mac users thank you for paying attention to this.

The problem was all the VRML vendors looked at the Mac’s marginal market share, and decided they couldn’t afford to support it. (Linux either.) Of course they completely missed some very important factors:

1. Many Windows PCs were doing boring, ordinary tasks like data entry that were never going to need VRML.
2. Mac marketshare was much higher in education, though still not a majority.
3. Mac marketshare was much higher among home users surfing the web recreationally.

Thus VRML chopped off a good portion of its potential user base at a stroke. In fact, it chopped off enough that nobody who actually wanted to reach end users could seriously consider it. However, that’s still not the most important reason VRML failed.

The real reason VRML failed is that Mac market share approached or exceeded 50% among the Web designers creating the early Web in the mid-90s. Every web shop in business at the time was just raring to jump on the next hot bandwagon, but when they looked at VRML the first thing they saw was that there weren’t any tools for them to use. So instead they looked at Java, Shockwave, Flash, HTML, Acrobat, and other things that at least ran on the Mac, even if they didn’t run well. VRML never recovered.

OpenOffice is in a little better shape than VRML was. It does run on the Mac, but so poorly no Mac user can seriously consider it for anything but opening the occasional OpenOffice document emailed to them by a Linux zealot. NeoOffice is a much better alternative, but it is still crippled by sitting on top of a code base written with little to no concern for the Mac. Too many user interface idiosyncrasies are the result of anti-Mac design decisions made in the core OpenOffice code base. NeoOffice is painting a pig to look like a tiger, but it still oinks instead of roars.

If OpenOffice is serious about supplanting Microsoft Office as the standard office suite (not merely the standard office document format) then it has to learn something Microsoft learned decades ago. It is not enough to run well on the preeminent desktop platform with 90% market share. You have to run on the Mac too. Microsoft Office is the de facto standard because people don’t have to think about who they’re sending a document to or what software they’re running. Publishers don’t have to force authors onto a specific platform. They just send out a Word template, and everyone’s happy. OpenOffice doesn’t make everyone happy.

Linux users will put up with crappy user interfaces that are never consistent from one program to the next. Windows users often will. Mac users never will, and there are too many Macs out there to ignore. On the Mac, OpenOffice and NeoOffice are dancing bears. It’s amazing that the products dance at all, but what we need are ballerinas, not bears.

It is possible to write good, cross-platform software that Mac, Windows, and Linux users will all enthusiastically adopt because they want to, not because it’s cheap or because some Linux zealot sysadmin installed it on their PC when they weren’t looking. Firefox proves this, and consequently Firefox is well on its way to 50% market share or better. Until OpenOffice makes a similar commitment to treating the Mac on an equal footing with Windows, it will not supplant Microsoft Office. It can achieve a few adoptions here and there in cost conscious businesses and government agencies. It can find a reliable place on the miniscule fraction of the desktop market running Linux. However, it’s never going to come close to 50% market share or establish itself as the standard office software.

Suppose you’re playing piccolo in a marching band. You want to play the Stars and Stripes Forever because it really shows off your skills as a piccolo player. However the rest of the band is playing the Star Spangled Banner. The talented piccolo player plays the Star Spangled Banner like everyone else. The pointless prima donna plays Stars and Stripes Forever. It sounds awful and everyone stops listening to the band.

User interfaces are no different. Some are advocating that we each choose our own tune, and indeed designing libraries to help us do that. However this serves only the egos of the players (or programmers). It does nothing for the audience (or end users) except make them walk away in disgust. I reiterate: it is the goal of a Java application (or any other application for that matter) to fit in with other applications, not to stand out.

Consistency is a virtue in user interface design. It doesn’t matter if the user interface of an application is best considered in isolation. It matters if it works the same way as every other application on the system. Users should not have to learn a new user interface for every application. We’ve tried that before (remember DOS?) and it doesn’t work. A large and mostly unrecognized reason why the Mac is still easier to use than Windows is that Mac developers mostly know this, and other developers mostly don’t.

This is why Mac users are far more likely than non-Mac users to install and try new applications. They have a much greater expectation that the applications do not have a huge learning curve. A person can only hold so many user interfaces in their head at once. It doesn’t matter that your design is 20% better than the Mac standard design. The mere fact that it is different makes it harder to use. This is why Mac users on average use several more applications daily than Windows users do.^*

Custom look-and-feels are like playing the wrong tune because you want a different tune. Changing the UI for Mac OS X is like changing the tune for the whole band. The conductor decides what tune the band plays, and if he chooses wisely the band sounds better. If he doesn’t they sound worse. Either way, though, they’ll sound much better if they play what he has chosen than what each individually wants to play.

Most of us are piccolo players, not conductors. It is our job and our responsibility to play the tune the conductor sets on the instrument we have chosen. It is not our job to change the tune, and when we do that ugliness (in music or user interface) is the expected and natural result. It doesn’t matter that Steve occasionally changes the tune we’re playing. That’s his prerogative as conductor. When he does that, we change our tune too. But we should not change to a new tune we happen to like while the rest of the band is still playing the old one.