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.

Haven’t we learned by now that I/O is an unreliable operation, and that you should never assume that any read call will succeed, or will return data in the format you want? That’s true whether you’re talking about files or FireWire packets. Furthermore, critical components like the Finder should not block on synchronous I/O. Any I/O needs they have should be serviced asynchronously.

It’s hard to take the Mac seriously as a reliable server platform when it’s so easily brought to its knees by one misbehaving hard drive.

On the plus side, I just ordered two new 500 GB drives to replace the failing and failed 250 GB drives.^* Two 500 GB drives cost almost exactly the same as one 250 GB drive did three years ago. Also, each 500 GB drive is about half the size of the old 250GB drive. That’s progress.

One downside: the USB drives only have one port so I can’t daisy chain them like I did my FireWire drives.

Second downside: the data transfer rate on these drives seems to be roughly half what it was on the FireWire drives. Those could back up about half a gigabyte a minute. This one is only doing a quarter gigabyte per minute.

The new drives are USB 2.0 instead of FireWire. Maybe the Mac is a little less trustful of data coming in over the USB port. We shall see.

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.

• 32GB solid state drive
• Intel Core 2 Duo Ultra Low Voltage chip running at 1.2GHz
• 1-2 GB RAM
• 802.11a, b and g wireless; built-in Ethernet
• Carbon fiber case
• 276 x 199 x 29mm
• 1.15 kg
• 11.1 inch screen 1,366 x 768 pixels
• Integrated webcam
• Integrated Dual-layer DVD writer
• USB 2 and Firewire
• 6 hour battery life
• Price (the number I’m least certain of) $2995

No, I don’t have any inside information. These are actually the specs for the new Sony Vaio VGN-TZ12VN (except for the price). Sony’s the only manufacturer that really competes with Apple in the “cool laptop” space; and Apple is not going to let them win.

I was most impressed with the internal DVD drive. I had expected a form factor this small and light would require an external drive, but apparently it is now possible to squeeze in an optical drive, and a writer at that!

The limited 32GB “hard drive” is disappointing. My MP3 collection alone is over 60GB. If only there were some decent sync software for the Mac, maybe I could put together a subset of my files that I actually need to take with me. However, until someone invents that, I was hoping to be able to just blast my 250GB desktop onto my laptop before I leave for the airport. This size means I’ll have to be even more parsimonious than I am now with my old 55GB TiBook. I suppose just possibly Apple might go up to 64GB of solid state memory, perhaps as a configurable (read extra-cost) option, but there’s no way they’re going to the 250GB I want.

The price is the real kicker, and the number that could change a lot between Sony and Apple. Apple is extremely competitive these days when you compare apples to, well, apples. They could easily come in a $1000 or more under Sony’s price (not that this will keep the PC-hordes from complaining that it still costs a $1000 more than a nine-pound plastic monster from Dell).

Nonetheless, I’m expecting a very interesting machine, and I look forward to owning one. (And if I’m wrong and Apple doesn’t come out with a Vaio-killer by MacWorld? Then there’s always Sony.)

As some of you may remember, I started the Amateur Project mostly because I was pissed off that Apple wanted to charge me again to play movies in full screen mode, even though I’d already paid for QuickTime Pro once. Amateur is written in Java on top of Swing and QuickTime for Java.

Amateur became capable of playing movies in fullscreen mode fairly quickly, and it even has a few useful features Apple’s own player does not. I’ve used it for most of my media playback needs ever since. It never achieved full parity with QuickTime Pro in other features though because:

A. Apple has more or less abandoned QuickTime for Java, and many new features of QuickTime 7 and even 6 simply aren’t available from Java.

B. I’ve had limited time to work on it for the last year or so.

C. Nobody else competent ever stepped forward to contribute. A couple of dozen people did fill out a generic java.net form requesting developer privileges without contacting me first, or giving me any indication of who they were or what they wanted to do. All I got was an opaque username and a request for commit privileges. Sorry that’s not enough. I did not get a single patch or even a usable bug report from anyone.

I may yet hack on Amateur as time and interest permits. I did get some good ideas for improving the user interface at JavaOne this year. However, I don’t plan to spend a lot of time on it. Even if I or someone else were to put some serious time into Amateur, it’s ultimately too crippled by QuickTime’s poor API and worse documentation. (Even the Objective C QuickTime API should be a case study in how not to design an API.)

I suspect it would be a more effective use of my or (or anyone else’s) limited time to learn Objective C and Cocoa and start from there. Better yet, it might be worth forking VLC to skin it with a half decent interface, improve its robustness, and add the features it’s missing.

It’s also worth noting that the Perian folks have done great work supporting media CODECs even QuickTime Pro can’t handle. That’s definitely worth a look. But $30 for QuickTime Pro and $20 more for MPEG-2 support is still a ripoff.

Do you remember the first iPod? the first Newton? the first Mac? These were also very cool Apple devices that leapt beyond what anyone else had done, and consequently didn’t work quite right. It took a few iterations not only to work out the bugs, but more importantly to work out the design flaws that inevitably arose when inventing radically new product categories and user interfaces. The iPhone is no exception.

The phone that Apple releases tomorrow will be cool. It will be the best combined phone/PDA/music player that has yet hit the streets. It will certainly be the best keyboardless PDA ever designed. It will actually legitimize the whole category, much as the iPod legitimized MP3 players, the Palm Pilot legitimized PDAs, and the Mac legitimized GUIs. However, just like those products, version 1 won’t actually work all that well.

I don’t know what the problem will be, but I guarantee you there’ll be at least one. At worst, the iPhone will be like the original 128K Mac: a cool toy with lots of promise but too little power to get any real work done. At best it will be like the first iPod: a product so good that won’t even notice the problems until we see the version 2 that fixes them. But either way, I’m sure you’re much better off waiting for version 2 than buying one now.

There will be an iPhone 2 in six months, and an iPhone 3 six months after that, and an iPhone 4 six months after that. By the time the contract is up, maybe there’ll be an iPhone that really delivers the smooth experience Apple is known for. However, version 1 Apple products are just never that smooth. (Mac OS X 10.0 anyone?) It takes some real experience in the market, before you can smooth out all the rough edges in a product. The iPhone doesn’t have that yet. The iPod and the Mac do, but that’s because they’ve been through many, many iterations. When the iPhone has had a little time to mature, it will likely be a great product too, but until then it’s going to be an annoying, overpriced chic toy.

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?

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.

I’ve tried every open source media player and QuickTime component I can find for Mac OS X, and at this point in time I don’t think it’s possible to burn an AVI to a DVD with either Apple consumer software (QuickTime, iDVD, iMovie) or with open source software (MPEGStreamClip, VLC, Handbrake) or with any combination of the above.

However I have finally found a way to do this. Roxio Toast can actually burn these files to DVDs and video CDs that play in a regular DVD player. So far it is the only product I have found that can do this. Toast retails for about $80. You’ll need version 7 or later. Roxio advertises a $20 rebate for owners of previous versions but:

• Roxio has never sent me a rebate check when I upgraded an earlier version before.
• Even if they did finally honor their rebate for this version, I still don’t think the upgrade should cost 75% of the full non-upgrade price.

Consequently, I’m extremely hesitant to recommend this solution. If anyone knows a cheaper way to accomplish this task on the Mac, please leave a comment. However, I’ve tried just about everything out there under $100 and a lot of the products that claim to do this can’t.