Microsoft Office isn’t among the apps that will run natively on Intel-based Macs—and it won’t be until the latter half of 2007, according to media reports. But when it does ship, Office will apparently be missing a feature so vital to cross-platform compatibility that I believe it will be the beginning of the end for the Mac version of the productivity suite.
Here’s the background. Back in August, Microsoft’s Mac Business Unit updated Mac users on the status of its development efforts for the next version of Office. According to the software giant, things were going well, and we learned that there will be free XML converters for current Office users to read the new Office for Windows’ file formats. (However, we’ve since learned that there will be a three to four month gap between the release of Office for Windows and the availability of the Mac converters. Those could be a few painful months to be a Mac Office user in a Windows environment.) The MacBU also noted that tens of millions of lines of code had been successfully transitioned to Xcode. Amidst all the good news, however, was this little lump of coal, as we reported it then:
For those who don’t know, Visual Basic scripting (also known as Visual Basic for Applications, or VBA) is the technology behind macros in the Office applications. Basically, VB makes it relatively easy to add automation and customization to Office documents. Macros can be used to help Office’s applications do some pretty amazing things. You can create data entry forms for complex Excel spreadsheets, create your own menu buttons in Word that are tied to specific actions, and even go so far as to create your own menu structure for customized programs used within Excel.
Even if you’re not a “power user,” you may have used VB in one of the Office apps to do something simple—it’s very easy to use the Record Macro menu item to create simple macros. For instance, I rely on a simple “paste clipboard as unformatted text” macro—it saves a trip into a separate dialog box when I just want to paste text from the clipboard in an unformatted style. I also have a number of spreadsheets that use macros to good effect, such as playing “what if” scenarios with mortgages, car payments, and savings rates. Come the next version of Office, though, I’ll have to find another way to do all those things.
To me, while the automation features are nice to have, it’s the fact that macros are portable across platforms that has helped the Mac versions of Office succeed in the market. With today’s versions of Office for Windows and OS X, macros written on the Windows version will work on the Mac version, and vice versa. (There are some exceptions for very complex macros, but most macros work the same on both platforms.) In any sort of mixed-platform environment, this is a very important capability—calling it mission critical for many wouldn’t be an understatement.
There was something of an uproar when this decision was made public in August, though not as much as I was expecting. This thread on the Ars Technica forums, for instance makes it clear that this wasn’t a popular decision—using some very strong language, I should add as a warning—and that many people were affected.
Since August, however, things have quieted down—and I think that’s a bad thing. This is a critical issue that demands attention. As a typical user, you might not think discontinuing support of Visual Basic in Office is that big a deal—“I don’t use macros, and they say they’re going to add in AppleScript and Automator support, so that should help replace Visual Basic, right?“ But it is—I think this move marks the beginning of the end of Office on the Mac.
Why they did it
Let’s first consider the MacBU’s perspective on the decision. I had hoped I would be able to discuss this with someone at Microsoft, but the company declined to speak on the VisualBasic issue at this time. Instead, the best source I’ve found is a blog written by a member of the programming team, Erik Schwiebert. The day after we reported the news about Visual Basic, Erik posted a very detailed explanation as to why the MacBU made this painful decision. He lists a number of very good, very technical, and very compelling reasons why Microsoft felt it had to drop VB support: complicated legacy code, exceedingly difficult to move to Xcode, very tricky C++ code used for form generation, and so forth. Erik then goes into great detail as to how each of these issues made porting VB to the next version of Office basically impossible. I am not here to argue any of his reasoning, as I lack the technical knowledge to do that. What I am here to do is to argue that, despite the complexity of the task, the MacBU made the wrong decision when it chose to drop VB from Office Mac.
As Erik himself notes in the above-linked blog entry, “VB on the Mac exists for cross-platform compatibility. There is no other software on the Mac that also uses VB, so it doesn’t help Mac Office integrate with other workflows based purely on Apple solutions.” He then proceeds to use this statement as part of the reasoning for why VB support was dropped. From where I sit, though, it supports exactly the opposite conclusion: there is nothing more important to the success of Mac Office than figuring out how to support VB—and that’s true if even it’s a feature that not all Office users put to use.
Why it’s so important
Very roughly speaking, buyers of Office will fall into two camps: home users and corporate users. While the general home user may not miss VB support in Office at all (especially if AppleScript and Automator are well supported), for many corporate users it will be a show-stopper on any purchase plans. Why? Because many companies rely on Office’s macros to make it easier to create, share, and update information amongst multiple users within the organization.
Consider my experience prior to joining Macworld. In my prior life, I was a corporate finance guy—I worked with budgets, forecasts, new business plans, cash analysis, and other such incredibly exciting things. In other words, my working life was spent in Excel. As such, I quickly learned the importance of macros in getting things done. For instance, when we had to do the annual business plan for our 200-person organization, we sent the managers an Excel budget template. But not everyone is an Excel wizard. So what to do? I created a simple customized form (using a macro) into which the users entered basic things such as their planned hires, capital spending budget, and so forth. We then used another macro to take the data from the simple form and populate the complex spreadsheets hiding in the background. By building our templates in this manner, we had a tool that was easy enough for beginners to use, and yet complex enough to pull together the overall budget for management. Of course, most of our users were on PCs running Windows, not Macs using OS X, but everything just worked—thanks to the cross-platform support in VB.
Fast forward to 2007 and the arrival of a Visual Basic-free Office, and the above solution isn’t possible. Having AppleScript and Automator support won’t do me a bit of good—no Windows user is going to be able to take advantage of those tools. And if I happen to be the one receiving an Excel template with macros from a PC user, things are just as bad. The MacBU promises us “macro transparency,” which means I’ll be able to open, edit, and save such files without damaging the attached macros. But I cannot actually use any of the macros. So forget about using your Mac to prepare your department’s spreadsheets in a company that relies on Excel macros. Your best solution, assuming you have an Intel-powered Mac, will be to purchase Parallels Desktop and a copy of (you guessed it) Office for Windows XP.
To put it succinctly: Anyone who works in a multi-platform office environment where Office macros are used will actually lose functionality if they upgrade to the newest Mac Office next year. In most companies today, Windows is the dominant platform, and the loss of VB support will take away a compelling justification for the existence of the few corporate Macs out there. No longer will a Mac user be able to say with complete confidence, “Just send me your files; I’ll be able to use them just fine.” Even a Mac-only shop might not be immune from cross-platform issues, if it deals with macro-enabled documents from Windows-based clients.
If businesses simply used the basic features of Office, the removal of VB support from the next version of Office for the Mac wouldn’t be much more than a minor annoyance. However, based on my experiences and what I’ve read elsewhere, Office macros play an important role in helping many businesses get things done. When Macs lose their ability to use those macros, they’ll lose a very important justification for purchasing Office for the Mac.
What about existing files?
Users—both corporate and home—who rely on macros will be affected by this decision on another front. From what I understand, any existing Office 2004 file that uses macros will still open in the new version of Office. Without VB support, however, those existing macros won’t function. From what’s been publicly stated, it appears you’ll be able to write an AppleScript or Automator action to replicate the functionality of the lost macros—but we won’t know for sure to what degree until the MacBU releases more specifics on the AppleScript and Automator support. If AppleScript is fully supported within Office, to the extent that we’ll be able to Record New AppleScript as simply as we Record New Macro today, that would certainly help ease the transition—one can only hope. If it’s not, then the process of recreating existing macros will be much tougher.
Keep in mind, too, that once you convert your macros to AppleScript- or Automator-based solutions, Windows users opening those files will not be able to use those macros, as the Windows version of Office won’t know anything about them.
A lose-lose situation
For anyone contemplating a pricey upgrade such as this is likely to be—just as a reference point, an upgrade to standard edition of Office 2004 costs $239—you have to ask yourself what you’ll be getting for the money. At present, what we know about new features is minimal—some mention of improved AppleScript and Automator support, some new UI features, a larger Excel worksheet area, and we know it will be Universal. We also know it will read and write the new XML Office file formats. Beyond that, though, we know very little about the other new features of the upgrade.
On the negative side, it seems certain that the upgrade will mean that all existing macros in Office files will no longer function. We don’t presently know that we can recapture all of the lost functionality, nor what skills will be required to do so. On that last point, Erik suggests in this follow-up post on his blog:
I don’t know about you, but selecting Tools -> Macro -> Record New Macro certainly strikes me as much simpler than learning a new programming language—I don’t want to be a programmer, I just want to write and use some simple macros in my projects!
Finally, to reiterate my main concern, the lack of VB support in the new version of Office means that corporate Mac-using customers won’t have a fully cross-platform solution available. As more of these companies migrate to the newest Office for Windows, this will become a large problem for the Mac users in those companies, as they’ll have no ability to use macros in any macro-enabled Office documents.
So no thanks, Microsoft; to me, it doesn’t really matter what nifty-but-not-yet-known features you add in to the next version of Office. If you don’t include support for VB, then there is simply no way I can upgrade, even if I wanted to—too much stuff I rely on will simply cease working if I upgrade. And while I’m but one user, I’m very concerned for Office Mac’s future, as I can see many companies reaching exactly the same conclusion.
How it might have been done
What could Microsoft have done differently? I’m not privy to its business plans, revenue figures, or long-range strategy, but here’s how I might have approached the problem.
The first thing to realize is that using Office in Rosetta on an Intel-based Mac is not like using, for instance, Photoshop in Rosetta to work on a 300MB TIFF advertising layout. Office in Rosetta is a very usable application suite. Speed is excellent, apart from some initial slowness on launch. As an example, I made a short movie of scrolling in Word on a Core Duo mini—the slowest Intel-powered Mac you can buy. The document in question is a 4MB 74-page OS X guide loaded with images that I wrote a few years back. As you can see for yourself, scrolling speed is zippy enough:
Most Office users will be doing the typical daily office tasks—working on budget spreadsheets, typing memos and simple reports, creating presentations, and reading e-mail. Office in Rosetta handles all of these things with ease, and once the apps have launched, most users won’t even notice that they’re running under Rosetta. So while converting Office to a Universal application suite is important, the lack of a Universal version doesn’t make it impossible to use.
Given that, if I had been in charge of this project, these would have been my top three objectives, in order: