[Macworld]

Post your comments for Microsoft Excel 2008 here

[AntonLitvin]

That is awfull! No VBA = no macros =( WTF?! I'll continue using 2004 ;(

[AntonLitvin]

Lack of VBA will bury alive the mac office.

[David_Foster]

Pathetic.

Given the lost functionality, unfixed bugs, continued inability to access services (how long have they been shipping product now for OS X?) and lack of improved performance (the program is a dog compared to Excel on fast Wintel machines), Microsoft should have mailed this version to current users for free.

[freddiepingpong]

Granted I've never worked within a large office environment, but do people really depend on large, complicated macro-driven Excel documents to do the job of a simple relational database? Granted full compatibility with Office for Windows is one of the primary features, but I think for the most part people are best served by taking the temptation away.

[Hurley42]

I think I might be officially unsold on this product. My good old Office 2004 is looking just fine until Apple takes Numbers (and Pages) more seriously.

[mdawson]

New features
While the addition of the Elements Gallery may be a nice touch for those that have not fully explored Excel’s feature set, it should be collapsible. Not everyone has a 30-inch display and on a laptop, the user is losing far too much vertical real estate to the Elements Gallery from what I can see of screenshots. In Excel in particular, having as much of the screen as possible available for data is a big deal. That is more a matter of fact for users with smaller screens.
Having the Elements Gallery expanded by default so that people know of its existence is fine, but it should be a collapsible toolbar so that people can regain screen real estate for the crux of Excel: the data cells.
Formula AutoComplete is long overdue for Excel:mac as that type of functionality has been on Excel for Windows since Excel 2002. I will reserve judgment on the new design of the toolbox until I get to see how it works. I have always tended to work from Office toolbars instead of the Formatting Palette, mostly because of inertia; when I am at work I use Office for Windows and my workflow remains much the same when I get on my Mac. I have found the Toolbox useful in Word when using the dictionary and I use the Formatting Palette for creating/modifying styles, but in Excel, the toolbars have always been my feature access point. That stated, I will very likely not upgrade to Office:mac 2008 for reasons that I will touch upon later.
As to performance, the fact that Rob saw little measurable performance difference between Excel:mac 2008 and Excel:mac 2004 demonstrates that Apple should be commended for its design of Rosetta and that Microsoft deserves a stern Colbert-esque wag-of-the-finger for Excel:mac 2008’s design. Data analysis in Excel can get pretty intensive and Excel should be multi-threaded on the Mac and, with the advent of multi-core processors being standard on Wintel PCs now also, in Windows. Excel has always suffered from substantial lag when workbooks get moderately sizeable and on modern computers that should not be happening.
I have dealt with large data sets in Excel that have substantially slowed down Excel’s performance and in my case we are talking large data on one worksheet, even if the workbook has other worksheets with smaller data sets, summaries, charts, etc. For me a large data set is one with a large number of observations (rows) but typically not more than about ten columns. I would hate to imagine how long it takes for Excel to perform calculations for those that have multiple worksheets containing tens of thousands of rows and upward of 100+ columns of data. Excel’s computation engine is long overdue for an overhaul on both the Mac and Windows versions.
Regarding Macros and AppleScript
“As the review of Word 2008 noted, Excel 2008 doesn’t support Visual Basic for Applications (VBA), which is the language used to create and record macros in prior versions of Excel. If you try to open a macro-enabled worksheet, you’ll have two choices: open and remove the macros, or open and leave the macros in place, though they won’t run. (You can also cancel the open request.)”
The above statement basically means that where Excel:mac was crippled when it came to macros up through the prior version it is completely impotent now. Microsoft has basically locked Mac users out of collaborating with Windows users using automated Excel workbooks. In my work this means that I go from not being able to run many of my Excel documents at home due to missing features in VBA Excel:mac that should not be absent to not being able to run any of them.
What do the “options” mean for those with macro-based workbooks. Well removing macros means looking forward to a large number of cells containing #VALUE! and other such errors and that is in the best case. For those with workbooks that border on moderate to full-blown software development, like many of mine, it means staring at a blank workbook because everything is done through a VBA-based program with a user form-based user interface. Leaving macros that do not run in place will result in much the same.
AppleScript is not cross-platform and therefore a poor substitute for VBA. If this type of feature disparity faux pas were present in any other software I would consider it a major blunder, but as Microsoft is the company in question, this is nothing short of sabotage. Unless Microsoft plans to also cut Windows VBA coders off at the knees in the next version of Office for Windows my point will be proven. Microsoft’s “excuse” for not adding VBA support to Office:mac 2008 is due to the transition to Universal Binaries combined with the umbrella decision to drop VBA across-the-board; the alleged sole reason that Office 2007 has VBA support was due to a loud scream from Windows users.
Even when the next version of Office for Windows is released, Microsoft will have some type of scripting language in play either based on .NET or C# and will very likely have a means to support legacy VBA code just as Excel 4 macros have long been supported in modern versions of Excel. It is highly unlikely that Microsoft will simply cut off Windows VBA coders the way that they have cut off Mac VBA coders who have always had to deal with a lesser version of VBA. Without the ability to run legacy VBA or have cross-platform scripting capabilities, future versions of Excel:mac will effectively be useless for Mac users that must collaborate in macro-centric environments. That, unfortunately, is perhaps exactly what Microsoft is hoping for as their support of the Mac through the MBU, while typically providing excellent releases of 75% of Office, has been lackluster at best if you look at the larger picture.
Lastly, what has not been discussed in terms of VBA is its other extenuating circumstance: the death of add-ons. Most Excel add-ons are written in VBA. Unless Microsoft has rewritten all of them in AppleScript—which I find highly unlikely—this means that things such as Solver, Analysis ToolPak, etc., die with Excel:mac 2004. Can anyone at Macworld confirm this?
Missing features and other foibles
I am unsure as to how much anyone uses the Services in OS X, but Microsoft should support that feature just as any other Mac software. I have already stated my opinion on how the new user interface wastes vertical space and offers no means to reclaim it, so I will not repeat myself here. I have not experienced the path issue in Office:mac 2004, but the fact that such a bug exists, is unacceptable.
A long missing feature in Excel has been support for more advanced technical and scientific graphing. Microsoft seems to be under the impression that the only people using Excel are still accountants. Excel has become a staple product for anyone working with data including scientists, engineers, data analysts, statisticians, operations researchers, et al. The problem is that when these very technical users need to create charts and graphs they need to either settle with a poor representation of their data or do an excessive amount of tweaking to the built-in chart types to present data correctly.
Excel has not updated the charting features in Excel in quite a few versions and there is no mention as to whether or not that has been done with Excel:mac 2008; given that it has not occurred with Excel 2007, I am doubtful that anything has happened on the Mac side. Excel needs to revamp the Chart Wizard, add new charting types to include those that are needed by people outside of the traditional Excel market segment (read: accountants and stock brokers) and make it easier to add multiple chart types in a single graph.
Also, while it was not mentioned in this article, Excel has increased the number of rows and columns that can exist in a single worksheet. Hopefully that shedding of the limitations harking back to the day when 64 MB was considered quite a lot of RAM, extends to the maximum number of points in a graph that remained at a paltry 32,000 points for so long.
My buying advice
Sue Microsoft in a class action suit once their buddies are removed from the White House. I am not one for frivolous lawsuits, but due to Microsoft’s position in the productivity suite market and the fact that they have been found guilty of anti-trust violations, they must keep feature parity with Office for Windows. Macro support on the Mac has always been weak, but this is the final straw. Microsoft has intentionally stifled Excel power users ability to collaborate cross-platform and as Intel-based Macs have been the norm for two years now, the need for this crippled Intel-native version of Office makes the eventual need to upgrade a must for some.
Otherwise, I agree with Rob’s buying advice. Based on a number of previews and this review I see no compelling reason to upgrade to Excel:mac 2008 unless performance of Excel on one’s Intel-based Mac is sluggish. For power users, Excel:mac 2008 is useless.

[mdawson]

Obviously you have no idea of how VBA is typically used in Excel. While there may be some Excel users that use Excel as if it is a database that is not the primary reason why people write macros in Excel. A relational database, whether simple or complex, cannot perform complex calculations nor are they designed to operate as a spreadsheet.
People that write macros in Excel do so to minimize tedium and reduce redundancy. That ranges from writing simple macros that perform a complex calculation that would be inefficient to perform with a cell formula to full-blown programs that analyze and summarize data across worksheets/workbooks for the (less technical) user. Yes, there are coders that write in-house programs in Excel that simplify and automate data analysis for their co-workers.
Automated workbooks are still spreadsheets, which is a wholly different entity from a relational database. Databases are designed to deal with categorical record-based and relational data not empirical analysis. And, any database created in Excel is likely to be flat and not relational. It is far too much effort to attempt to create relational tables using VBA to make it worth anyone’s time and any sizable company does have and uses database software when such data is in question.

[mdawson]

I do not think that Apple does not take iWork seriously. Apple’s productivity suite is simply not intended to compete against Office, just as Appleworks was not a direct competitor to Office. iWork is designed for the individual user and not collaborative office staff. Apple has never developed a pro-grade office suite and I doubt that they are attempting to do so with iWork.

[Hurley42]

I guess when I mean Apple should take Numbers seriously - Numbers cannot do something as simple as display a formula on a graph which is a basic requirement in the sciences. I am not a "power user" of spreadsheets, but I do need basic features which should be part of any spreadsheet software. Granted, Numbers is version 1.0, so I will hold out further opinions until the next version to see if Apple adds basic features.

[leicaman]

It's too bad business users never caught on to databases for that kind of thing. I think they would do better to move to Access (Win) or Filemaker Pro. (Bento is for home users, really.)

Everyone seems to be forgetting that VBA is going away in Office for PC as well. I guess Microsoft wants to drive people to Access? Regardless, this is just an early push in that direction from Microsoft for Mac users first. Too bad it too Mac Tech magazine to write a comprehensive document on moving from VBA to Applescript, and not more publications. (You'd think it would be a natural for Mac publications to do more with Applescript. But they never do comprehensive at all. Why don't they have Apple's Applescript guru Sal Saghoan doing articles at MacWorld? Or why don't MacWorlds tech gurus do more on that topic? (How to read a dictionary could be a whole year's series!)

The one hallmark where I work about how people use computers is that they are familiar with spreadsheets, so they overuse them. Databases are still too unapproachable for most people to put them to good use. Too bad there isn't something between Bento and Filemaker pro that has real relational capabilities. And it's too bad Access is too complex a job for the MacBU to tackle. Though I have to say, when I worked on a PC, I absolutely hated Access. I was a dBase and later Paradox user. I actually made money programming Paradox for a while. Never like FoxPro or Access.

[palane]

Regarding a few comments:
Neither Excel or Numbers should be used for scientific graphic/plotting. I'm a heavy user of Excel as it's great for playing with numbers and has much more flexibility than the scientific packages. If you will, I can doodle in Excel. Once I'm done, off the numbers go to a program that does proper plotting (Kaleidagraph for me as I don't need 3D).
Dropping VBA is a deal killer for me. I don't use many macros in my work, but they're critical in the spreadsheets I developed for running my bowling league (I'm league secretary).
MDawson wrote: "People that write macros in Excel do so to minimize tedium and reduce redundancy."
As SJ would say, just one more thing. Macros save me about an hour each time I enter the league information. They have also completely eliminated copying and pasting errors.
I will inform MS that I will not be upgrading Office as a direct consequence of eliminating VBA support. I suspect this is a competitive measure. It forces anyone in a heterogeneous environment to use Windows and Office for Windows.
BB

[LSlugger]

The reference to Excel 2004 in the first paragraph indicates that it was awarded three and a half mice, but the linked article shows four. While Word held steady at three and a half mice, Excel actually dropped a full mouse.

[griffman]

"But they never do comprehensive at all. Why don't they have Apple's Applescript guru Sal Saghoan doing articles at MacWorld? Or why don't MacWorlds tech gurus do more on that topic? (How to read a dictionary could be a whole year's series!)"

You have answered your own question in your comment -- it could easily take an entire year just to explain the concept of the dictionary to users. Another year to introduce them to the basic syntax. Another year to do anything more complex than pop-up simple dialogs.

AppleScript is a language -- sure, the way you work with it isn't anything like C or Fortran or Basic or anything else, but it's a programming language. Not everyone wants to be a programmer; we just want to be able to customize our worksheets. Teaching Macworld readers to be AppleScript programmers is not really our charter -- and it would take probably every page in the magazine to provide even a basic education on the subject. For those readers who do want to become coders, MacTech is an excellent magazine.

One major failing of AppleScript/Automator in Excel 2008: they're post-processing code, not in-spreadsheet code. They help you do things with worksheets that are already built. But since you can't tie their functionality to an objectin a worksheet, you can't design easy-to-use worksheets for users. There are also a huge number of things you could do in VBA that you simply cannot do in AppleScript. As but one example, using VBA, you could build a complete custom set of menus to drive your worksheet. AppleScript isn't able to do that.

The other huge issue is that, even if you want to use AppleScript, you can't record it in Excel. You've got to know the language well enough to write your code by hand! With macros, you could record something and have a functioning macro in a matter of seconds -- even if you don't know the first thing about coding.

-rob.

Edit: I moved a paragraph that made no sense where it was...