Thank you all for your comments about VB. There’s certainly a lot of passion, frustration, and outright anger being expressed here. For those of you with kind words, I greatly appreciate them. We’re reading every comment, no matter what the sentiment. I’ve personally seen MacBU leads reading your comments on my blog.
I had intended to post yesterday and answer some of the specific questions raised, but I’ve once again caught a nasty fever and cold from my preschool-aged son and didn’t get to it. Sigh… In lieu of that, I’ve got a couple of more general notes to make on yesterday’s post.
In my note on resources, I used a slightly extreme example of our headcount. I did have an opening for quite a long time, but our overall delta between having someone leave our group and hiring a replacement is probably something like 2 months or so. I have no idea how that compares to any sort of Microsoft- or industry-wide average. The complicating matter is that departures and candidates tend to happen in clumps, so we often end up with some abnormally long or short gaps in staffing instead of a more normal distribution. We’ve actually had a lot of folks very interested in working at MacBU (i.e, us having open headcount really is not due to a lack of people interested in working here). We hire world-class developers and they don’t simply grow on trees. For those readers offering a smackdown on the intelligence or capabilities of our developers, nothing could be further from the truth. We’ve even had some developers leave MacBU to go to other renowned Macintosh companies and then come back to MacBU because the grass really wasn’t greener elsewhere. We’re all proud to be here!
As for keeping VBA in PPC to run under Rosetta, that could be done but just vastly overcomplicates an already very complicated piece of source code. Rosetta only works on a per-process basis, so we’d be moving code and data out of the single app process into two processes. There are many many points in which apps call into VB and VB calls back into the apps (not to mention VB’s dependence on other lower-level shared library code that is now Mach-based) and marshalling all those calls and data cross-process is a heck of a lot of work. It gets even more complicated when you have more than one Office app running at a time, because then the new VB process would have to keep its internal state separate for each client app!
People have also offered the solution of porting the current Win Office 200x VBA over to the Mac. That’s pretty much a no-go too, because 1) it still has the assembly ABI problems, 2) makes calls to the Win32 APIs that don’t exist on the Mac (well, without WINE or any of the variants) and 3) relies on features in the Windows OS that don’t exist at all on the Mac. We’d have to port over large swaths of the Win OS and that might take even longer than writing VBA over from scratch.
VBA just wasn’t designed to be portable across architectures. The Mac and Windows implementations are very different, even though the actual language is the same. If I could go back in time about 15 years and tell the original designers to do it differently I would, but I can’t. Thanks to the heroic efforts of a few developers (Shuyi and Ying) we managed to Carbonize VB for OS X, but the move to Intel is gargantuan. We considered many, many alternatives. Each one turned out to be no simpler and as much or more work as the plain port would be.
None of this is work that we can’t do, it’s just work that would take away from everything else that we do want to do and would delay shipping Office 12. As I said on Tuesday, delaying Office 12 has other ramifications for cross-platform compatibility such as dealing with the new Office XML file formats and related features (like the larger cell grid in Excel, for example.)
Back to the idea of AppleScript… Folks who want to develop scripting modules on the Mac should check out AppleScript Studio. You can create GUI applications with it, and it is absolutely free from Apple. Also, a few bloggers have been wondering about scripting Office with Python and other languages. Yep, you can do that with the AppleEvent bridges available for those languages. We actually test Messenger in-house with a large suite of Python scripts that drive it through OS X’s Accessibility AppleEvent suite. We also drive Xcode via its AppleScript dictionary with Python scripts that send AppleEvents.
So, what now? Well, it is pretty obvious to me that the MacBU needs to provide some guidance for folks who currently use VB. The best way for us to provide the information that will help you the most is for you to give us some first. I encourage you to provide feedback to us — lots and lots of feedback! There are several ways you can do this:
- Select Help/Send Feedback on ‘OfficeApp’ from within your favorite Office 2004 application
- Click on this link and fill out the web form
- Post a comment on any of the MacBU blogs
- Send me email from this link and I’ll forward it into MacBU
Please give us specifics in your feedback. Just saying “I want VB!” or ranting about how we’re evil doesn’t provide us anything we can take action on. We’d like to know what you do with VB, what the goal was, did you share the macro with anyone, was it specifically cross-platform or just something on the Mac, what app was the macro in, and things like that. So yes, do tell us what you really want. Please keep it civil, it’s no fun reading through pages of insults. Your feedback directly helps us figure out the best ways we can help you.
[Aug 11, 9:26am -- minor edit to correct the description of how we drive Messenger with Python]
Last year, I decided to create a program to transcode obsolete ancient Greek fonts into Unicode in all my Word documents (my PhD thesis in particular).
Since such a program could be useful to a lot of colleagues and students, I wanted to make it available not only for Word 2004, but also, if possible, for Word for Windows, even though I do not use Windows myself.
So, even though I would have preferred, being a Mac user, to explore Applescript for Word and use that along with Applescript Studio to create my program, eventually, I ended up creating a Visual Basic solution.
Programming a Visual Basic program on the Mac using Office 2004 is _really_ not fun. The editor is not user-friendly at all (I ended up doing most of my typing in BBEdit and then checking the syntax in VBE). It crashes a lot. The documents that contain the code get corrupted a lot. Etc. But in the end it worked and the program, GreekTranscoder, works under both Word 2004 and Word 2000 (or later).
The decision of the Mac BUT not to support VB in the next version of Office means it _wonâ€t_ work anymore on a Mac. That is to say on _my_ platform of choice.
In other words, selfish as it may sound, since I was creating that program first and foremost for my own use, even though it would prove useful to others as well, had I known at the time VB would be abandonned, I would _never_ have learned it and used it for that project! I would have dug into AS for Word and used that instead. Since such a solution, while Mac only, would still work next year in the next version of Office.
Right now, I’m inclined simply _not_ to upgrade and keep on using Word 2004. I’m an Hellenist, not a programmer, and even though programming can be a fun hobby, I don’t have much time to devote to it.
If I were to upgrade, I would have to rewrite the whole program as an Applescript Studio project.
So, what I’m asking is this: please include a utility to translate — even roughly — the VB code into AS, so that a good portion of the work can be done automatically, even if one then has to check everything closely. Simply getting a good translation to start from will be a big help understanding the AS syntax Word expects etc.
And include tutorial detailing how to recreate a VB form using Xcode and AS Studio. How to link controls to scripts etc.
In a nutshell, offer first-rate documentation. Example, Sample code. And — even rough — translation tools. Comment out the non-translatable portions if you need to. But make it easy to go from VB to AS.
Best.
What do I want from Mac Office?
1) “no matter what platform a file is made on, that it will look and behave exactly the same” as Joe says
2) old bugs fixed: eg the one that means that exporting a Word file containing pdf vector images to pdf produces a file with non-vector images. How old is this bug now?
3) proper support for Unicode in multiple languages. Word 2004 is only halfway there.
I don’t care about VBA, personally, but if it gets in the way of (1), I don’t see why I wouldn’t just run Windows Office and/or NeoOffice instead, unless Mac Office, unlike all previous versions (because of bugs and half-implemented functions), is a real pleasure to use.
I have read all of the comments for the previous article and this one, I know many have said it already, but I will as well.
I have coded in VBA, VB6, and AS for OS9, am now learning how to script for OSX. But this doesn’t mean I have the time and resources to create two versions of everything.
Office on a MAC is good only if documents can be seamlessly used on both platforms at the same time in the same Enterprise or by sending documents to others. A Windows user will add VBA, so this VBA needs to run for the MAC, and be able to be modified there so the Windows user can use it.
If VBA will be going away for Windows, then hook up with the Windows developers and make sure whatever replaces it is a solution for OSX as well. I don’t see a reason to upgrade to a version of Office that is not cross-platform compatible..
chris
There’s a 3rd category of users out there. All Mac companies that trade files with other companies. Architecture and construction are this way. None of the firms (well almost none) live independently. We trade files all the time. It maters to an all Mac architecture firm if VB vanishes even if that firm never ever ever writes a single bit of VB.
As to the two stated objectives of the MacBU for Office. The majority of Mac users I work with (all the way from my 78 year old mother in law to larger firms where I do their IT Systems Administration) only want office to “feel” Mac like. Applescript support is nice but 99% will never use it. Other “core” technologies are nice but what they really want is to be able to open up that Word document their credit union sent them to process for their loan app. Or the “I’ve read this” check off before passing on the critical change order.
Applescript is a total waste for most of these folks. Maybe a useful addition but in general a waste.
I’m all for a 2004 and a half release. Keep my keyboarding and visual styles Maclike. Keeping the PPC version running with Rosetta is much more important than a more Mac like new Office that breaks many of the reasons I work with it. There are other issues but this will keep many many many design firms in the Office 2004 camp with heavy research into alternatives.
Let’s make this very simple:
Office 2007 = Word 6 Fiasco
End of discussion.
I use VBA for Excel, both on Mac and Windows. I use VBA for solutions like this:
1) Delete blank rows from a worksheet
2) Automate the process of filtering
3) Create multiple PivotTables in a worksheet
I like that I can develop a solution on my Mac, and have it work on my PC, or vice versa. I immensely dislike having to redo my work one for each.
But I can appreciate the pain that the Office Mac BU is going through. Considering that so many userforms and controls in the VBE are tied to the OS, VBA for the Mac was always sort of a chewing gum and duct tape solution. (But damn it, I liked that solution…in absence of anything better!)
I might just have to get an Intel Mac and dual boot…get Visual Studio Tools for Office…not the Mac BU’s fault…just the winds of change.
While AppleScript may be a candidate for replacing VBA, it doesn’t appear to offer the same richness for seamless integration or customization of the Microsoft Word: Mac application. Or at least I haven’t figured out how to attach an AS to a button or menu item, capture keystrokes, or create global templates that automatically load AS ‘macros’.
While I can see AS being feasible for occassional use scripts, it doesn’t appear to allow the integration to make AS suitable for production. And without the ability to embed AS ‘macros’ within a document, it will severely complicate third-party solutions built around global templates. In many ways (from our POV), the defining characteristic of Microsoft Office as compared to other text editors on the Mac _is_ that it has cross-platform scripting. Without the macros, Word: Mac is just another word processor.
Our product relies heavily on VB macros (for both Mac and Win versions) for cross-platform compatibility of both file formats and functionality. The loss of VB for Mac has the potential to kill off further Mac development. If nothing else, it’s going to mean a significant redevelopment effort on our part and significant retraining for our customers as the present UI doesn’t appear to be possible via AS. Nothing something I’m really keen on as both tasks, due to their size, have the real potential to distract us from developing compelling new features.
All I can say is that I hope that there will be significant support to the Office: Mac add-on community to assist them with this forced migration. I’m concerned, very concerned… I don’t want to go all ‘woe is me’, but we definitely need details, and soon, of what features/possibilities with VB will NOT be available via AS, workarounds, equivalent and sample code examples, etc.
Pingback: tellEsfera - A Esfera do Telles » Blog Archive » Falta Gente
Having read the details in your posts plus the additional comments listed above I don’t believe there exists a “silver bullet” to this problem. I think the best compromise so far mentioned have been 1) IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation. 2) Provide for translation tools to help users migrate to the new scripting environment. 3)Some warning to users that documents contain VBA macros that will not execute and must be translated.
Aside from that I have to ask What has the MacBU been doing over the last few years??? Aside from a few hardware drivers, RDC and Office what are you doing? I would have thought that after Office 98 was released a small team of 2 to 4 programers would have begun to build Office using the Cocoa frameworks to eventually move away from the Carbon APIs. The understanding being that it may take two additional releases before a truely Cocoa based Office would be available. I know and understand the deep dependencies on C++ objects from Win Office but please in five years you could have found a very good solution ESPECIALLY in light of Apple allowing the mix of C++ and Objective-C. IF MS planned ahead, with the assumption that they were going to continue to market Office for the Mac, then a long term plan could have been put into place.
If you were to announce that the next Mac Office was 100% Cocoa based BUT had to sacrifice VBA I think that maybe you would not have gotten so much heat, MAYBE. OR five years ago when you made the first release of Office for OS X native had you begun the re-write of VBA then. From your description it sounds like hack built on a foundation that was known to be going away. Too many OS9 and CFM dependencies.
Lastly, related to “What are you doing?” How about porting some other tools like Visio or at least a Visio reader. Yes I know that there are programs that can read the Visio XML format files on the Mac but they are far from perfect. In Office 98 if I received a Word document with a Visio diagram embedded Word could display the diagram and print it perfectly. Today with Office 2004 that isn’t the case. Please spare me the “business case” argument, if there is significant demand in Windows, having a Mac version would have demand if for no other reason then to share files.
Finally how about implementing a full Exchange client for the Mac. Again it has been 5 years since Entorage shipped I would have thought your team, being the largest Mac Development team outside Apple, could have accomplished at least that.
Sorry for the rant but maybe now you can understand why Mac users are very skeptical of Microsoft’s Motivations. If you had workable solution to having a first class native Exchange Client for the Mac would the powers that be allow you to move forward? Or how about the ever elusive Access product? How much power does the MacBU have in setting its own direction and goals and priorities?
Joe Barisa asid “IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation”
Joe, I very much doubt that the Windows Office group would go for this. The Visual Studio group (responsible for the standalone versions of Visual Basic) would *love* for Office to do this, since they created an entirely new platform and an entirely new and incompatible version of Visual Basic to go with it. (See http://www.classicvb.org for details.)
But as far as I can tell, the Office group took a long hard look at the customer reception and the sales figures and decided they really didn’t want to have a comparable percentage lopped off their sales as well. Three versions of Office have been produced since the .NET platform was released (Office XP, Office 2003 and the beta of Office 2007) and VBA is still there.
I suspect that Microsoft has now done enough market research to convince itself that VBA cannot be dropped from Office unless there is a replacement that will enable VBA projects to undergo a conversion to a new language that is about 98% automatic and therefore relatively painless. 3 releases later there is still no such converter between the old VB6 and the current verson of VB.NET, so I suspect that such a converter is a far from trivial task. I would suspect that a converter to AS is probably harder still. How for instance would an AS program cope with the Application.ActionControl object – the button that caused the macro to run?
From what I can tell, even MacBU would be hanging on to VBA were it not for the recoding involved in the change to the Intel platform. They don’t actually *want* the loss of sales that may result from dropping VBA – even if they are spinning it in order to claim that there will only be a minimal effect.
I accept that MCBU are in a tight spot at present. But their choice really does seem to be between the following options, all fairly unpalatable.
1. Drop VBA for now, take the temporary hit in sales (whatever it might be) and work to put it back next time.
2. Drop VBA permanently and accept the consequences in terms of loss of compatibility and probably loss of sales.
3. Delay the next release until VBA can be included, and accept any loss of upgrade revenue in he meantime.
At present, it isn’t clear whether MacBU will choose between #1 or #2. I guess they haven’t themselves yet made the decision. Their actions are equally consistent (so far) with either path. They seem to have ruled out #3 which would be my preferred solution.
My Ideas!!!
Python sounds sounds exciting, and probabaly a better solution anyways. I’ll have to play a bit with that one. If I understand it right, it’s a write once solution? Now trying to get my windows friends to comply, another subject… It might not be so bad with 2007. That would be a very good how-to/best practices guide so we can write cross-platform scrips.
One of the things we use on the PC side is SmartDocs which from my understanding is tied to .net underpinnings. Namely VB.net. (uhhh… more VB) Mono says that their VB solution isn’t quite ready for prime time yet, but that seems to be the most resonable route. How much time it would require to implement it might be a challenge. I’m shure someone has tried it. Would be a very good post topic!
I have a few other things that would make my life easier. (notes and tasks from exchange, other interface improvements) but those i’m shure you have heard about countless times. That would be for another post:)
Rewriting VBA from scratch will not be impossible or too long.
It is not vital to have VBA pre-compiled: a small interpeter will work great.
The brand new Mac will be fast enough, and having the macro working is very important.
Think twice before destroying the only multi-platform (bi-platform) language Microsoft had.
Please.
bye
I believe this choice makes the upgrade to the next version of MacOffice much less attractive unless the new feature that will be included will make it a killer app anyway; this opens up space for competitors although unfortunately I still don’t see many alternatives out there.
Moreover what worries me is that if we’re still debating about these foundamental issues then delivery of the first UB Office version is probably VERY far in the future although the transition to the Intel plaftorm was announced one year ago.
You seem to understand that this announcement translates into “Don’t buy our product” for those of us who are in the know. But have you thought about all those people who will think, “Oh, no VB. No big deal, I don’t use it.” without having a clue that they are using templates that do or that they have third party software that does? And when that group starts clamoring about broken documents, what will you tell them? Remember, you could print in massive red letters, “No VB inside” and a huge number of customers won’t know what that means for them until they start using it. So will Microsoft offer refunds?
This is a massive cluster F*** and in the coming months instead of looking forward to compatibility with Microsoft’s new document files I’ll be looking for a third party program that will let me open those files in Office 2004. I hope I don’t have to write it myself.
On one side we MUST have VBA compatibility – even the simple circumstance of a bank e-mailing you a home loan spreadsheet will suddenly be a problem with a lack of VBA.
On the other it is plain fact that, after much consideration of these recent blogs, VBA as it stands cannot be ported – for the simple matter that the Mac implementation has been clearly a disgusting mess when you consider the efforts put into the Windows equivalent (of any MS product I might add). It is truly a shame when you think back to Excel, PowerPoint, heck even QuickBasic all being such spectacular products on the Mac platform so many years ago.
However let’s wake up to a simple reality of today’s age, and one that Microsoft is only recently starting to finally open their eyes to – open source. This is a perfect opportunity for Microsoft to genuinely embrace the resources and potential of community effort. Why not have Microsoft focus their efforts on providing the VBA:MAC interface into the heart of Office:Mac, while the development effort VBA itself be opened to the open source community. After all, as much as I understand why Microsoft is trying to ignore the existance of OpenOffice, the reality is they HAVE managed to make headway with an open source cross-platform VBA… so let us not kid ourselves that the almighty Microsoft can’t!
Or, alternatively, let’s take advantage of RealBASIC’s proven cross-platform compatibility with VisualBasic (in fact RealBASIC has become what I always thought Microsoft would someday do with Visual Basic years ago)… strike a deal with them to provide VBA:Mac.
I don’t use VBA day in day out – I’m just a regular everyday person who, once in a while through everyday events, does end up eventually dealing with a document that has VBA that until now has simply “worked” transparently but would now, under a new version of Office, suddenly be a problem.
Finally, I hate to make an unproductive remark, but the fact is that for a long time now new releases of MIcrosoft products have NOT had groundbreaking earthshattering features that we MUST absolutely upgrade for. They have evolved in their own ways, but the reality is that for regular everyday use even Office 95 is perfectly fine and there have been plenty of Office releases since then. Now you’re going to sell yet another new release that intentionally omits a major feature that was previously there…. not smart. Fact is, people can just simply stick with their old Office on PowerPCs and likewise Intel users can also use it via Rosetta… a shame but a cold hard fact.
As I said, I consider this all from a pure everyday regular point of view… so then try looking at it from a point of view where you actually do need VBA… there you have an enormous problem…
Before I go can I make a cosmetic request? Office:Mac has some gorgeous custom aqua widgets – the splitter bar, the ruler controls, page buttons, view buttons, etc… and yet in the toolbars the aqua widgets (eg combo box arrows, etc) are crappy “cartoons”… can they please be re-rendered as aqua looking, or will they instead now be native widgets under the new xcode version of Office? Otherwise keep up the good work
Schwieb Says:
August 12th, 2006 at 5:15 pm
“The OLE Automation layer is still there. In fact, the VB implementation and the AppleScript implementation are both written on top of the OLEAut layer (which is why if you could do it in VB you can do it in AppleScript.) If RealBASIC uses the OLEAut interfaces (which all still exist) then it can easily drive Office 12, just as it could Office 2004 and X.”
Then if the MacBU could work with REAL Software to make sure REALbasic drives the OLEAut layer quickly and efficiently, it would be very good solution to the problem.
Unfortunately, right now, the REALbasic Office Automation features work extremely slowly on the Mac. So much so that’s it’s actually more efficient to use AppleScript from within RB to perform relatively complex tasks ;-(
So please, work with REAL and turn RB into a _real_ alternative to VBA for Office Automation on the Mac.
I’m one of the few Mac users at my work. I’m also the only person experienced in developing Excel macros. So I develop them on my Mac and pass the results on to be used by my Windows-using colleages.
If there is to be no more VB in Mac Office, then this is a problem. I guess that my solutions are:
* don’t upgrade from Office 2004
* stop using Excel workbooks with macros and implement something equivalent, perhaps mySQL/PHP.
So what I want is some way to continue to develop Excel macros on my Mac, pass them to Windows users and have the macros run on the Windows PCs.
If the macros have to be written in something other than VB, that’s OK, I’m prepared to learn a new scripting language. But cross-platform compatibility is critical to me.
How about a simple interface to user-written C++ code? Like the Excel SDK in Win32 land (and yes, even PPC land). Just make it easy to use, and well documented.
A quick search suggests that no one here has yet mentioned the importance of the Auto Macros in VB. In Word, I use AutoOpen daily to force documents emailed to me to open in the Zoom and Normal view that I prefer. I use AutoExec daily to keep enabled some preferences that randomly uncheck themselves. These are relatively simple uses, but are the difference between happily using Word and constant seething frustration for this home/academic user.
FWIW, there is support for cross-platform VB and there are resources who can help.
A colleague of mine has developed and maintained, for many years, a complex spreadsheet underpinned by scads of VB that needs to work across Macs, PCs and Unix. While the task was a continual pain in the butt, he quickly decided that the best solution, with the least cross-platform bugs, is OpenOffice. That (business-critical) spreadsheet is now ably supported by an outfit in Belorussia.
Perhaps a test of your VB code against OOo would be worthwhile?
Why continue developing a separate Office for Mac codebase?
Why not run the Windows version virtualized on the Macintosh? You might have to bundle a runtime copy of Windows, but that has been done before by the Office team, e.g. early Word for Windows versions that could run on top of DOS. Access to features provided only by the Mac OS could be provided by a thunker or native DDE-like server.
Tweak the UI, and nobody would realize it was a Windows program. (Actually, with its new UI, it already does not look like one!)
Moving to one codebase would ensure feature parity and more timely updates. Insulating the codebase from the OS would also hedge against further seismic shifts in Mac architecture (which occur, on average, once every SIX years!)
I have invested literally hundreds of hours in thousands of lines of VBA code that perform custom text-parsing operations on MS Word documents. By pulling the rug out from under all this work, and destroying the value that it brings to my clients, when there are reasonable alternatives (as suggested in other posts), Microsoft is demonstrating its contempt for its own customers. Mac users who don’t need VBA already have other word-processing alternatives; it’s the power users who really need (and are willing to shell out for) Office. For me, VBA has been the only reason to put up with some of the other obvious flaws in Word/Office (e.g. who, if anyone, is in charge of fixing bugs? How do you even report bugs without beingcharged $35 for the priviledge?) At the very least, whatever alternative scripting platform you offer *must* have direct built-in access to the objects/collections that make up a Word document: paragraphs, words, characters, tables, cells, etc… And you should develop and offer for free a utility that accurately ports VBA scripts to that alternative scripting platform. Without these features, you will simply be blowing off (and blowing away) all the people who have relied on VBA over the years, and they will be lost to you as customers.
First off, I appreciate the time and effort you guys put in explaining the whole scenario.
Second off, there’s not much point crying over past design decisions. We are were we are.
Thirdly, while this can be seen as killing Mac Office in the Enterprise, it’s not as dire as you might think. Anyone buying a new Mac is buying an Intel Mac. Which can run BootCamp or Parallels. Which can run WinOffice. Which runs macros. Granted, it’s not a perfect solution, but it works and is future proof. The downside is the cost for enterprise of a Windows Licence and the training / exra time costs for staff. Microsoft could ease these pains by producing white-papers, technical guides and training materials for corporate-types, IT depts and end-users. They could also greatly limit the cost impact by producing ‘bundles’; where if you buy MacOffice you get a Windows licence and a licence to run WinOffice to run exclusively on Mac hardware, at a cost less than that of buying them all seperately. It’s the least the WinOffice team can do (taking the revenue hit) considering their contribution to the problem.
Where this decision really kicks is users of non-intel machines who want/need/ are forced to upgrade to Office07. They are stuck in limbo. Some will be able to upgrade to intel machines, but I suspect most will not.
Other folks have commented on their perception of decreasing committment to Mac products. I say I have to agree – the product foot print is shrinking, the feature footprint is shrinking. I don’t understand why – Mac sales are growing – so you’re in an expanding market.
Can one of you guys explain why the language VB for Office is so complex that you can’t write a new x-platform interpreter, along the lines of python, perl, ruby etc? All of these languages (from the outside) appear far more complex, and yet have relatively small cross platform compilers and interpreters.
I very much appreciate this discussion and your “two pillars of focus” namely 1) making Office mac-like and 2) maintaining compatability with Windows. But I think you have the relative priorities of these two pillars very much reversed.
I suspect that very few of your Office:Mac users install your software expecting to get a “100% mac experience” (whatever that is). Instead, they install Office because they want to be able to use the same excellent productivity suite as their Windows colleagues and they want to be able to communicate and participate with them. If you diminish the participate/communicate part of Office:Mac, there is really rather little reason to buy Office:Mac.
I strongly recommend that you:
1) keep compatibility and feature parity as the number 1 priority for Office:mac
2) make VB implementation a high priority
3) to satisfy 1 & 2, consider delaying a Universal Binary release in the next version, or entertain creative stop-gap solutions that will maintain the functionality of VB, even if it is a temporary hack job
Before I go on my rant, I would like to stress the point that the MacBU Office team has only a fraction of the size of the Windows counterpart yet it regularly managed to produce Mac-versions of Office that were nicer (and occasionally better) than the corresponding Windows versions. Must be a bunch of very talented people working there…
In science, in particular in life-science, Macs are very quite wide-spread, although Macs are more frequent in academic institutions where users can choose (and often have to pay for) their personal informatics equipment than in scientific enterprises where the IT department dictates.
I have personally considered Office a finished suite since Office 98. The only reasons I have upgrade to new versions of Office were compatibility with the current Mac platform (and I understand that Apple is asking a lot from its developers) and compatibility with the Windows counterpart. Otherwise, I think that with every release, the suite got more cluttered and resource demanding, but otherwise, it only gained little useful new features. The core functionality, in contrast, has hardly improved (I am therefore also not surprised to hear that a lot of the core-code of Office is ancient…)
As one example, Powerpoint 2004 has gained a lot of Keynote-like features (part of which were nicely – ehm – implemented, others less). Yet, when I open Windows Office-generated presentations, I often still have to deal with big-red-X-figures or vertical text that is not displayed correctly or figures that are otherwise screwed up. Not to mention that Office for Mac is a graveyard for OLE-data…. I personally think that this is pathetic, and I am really tired of not knowing whether my presentation will display correctly on the computer at the conference. I am also tired of spending a lot of time in converting graphics (e.g. vector graphics, various post-script formats) into formats that are high-quality but MS-safe (i.e. JPEG, PNG), in assistants who tell me that there is a problem but are otherwise not very helpful in solving the issue, or in testing my presentations on different machines. Similar things can be stated for graphics in Word, for that matter.
I really wished that the MacBU focussed an a good and COMPLETE Intel-port of Office because this is going to be the main reason why most users will upgrade (and not a fancy new animation of a toolbar). Please stop overloading the suite with new annoying features nobody is going to use anyway (wizards/assistants/other pseudo-enhancements) but rather focus on its core functionality including seamless and complete compatibility with most other versions of Office. This said, I really think that VB has to be ported, even if this happens at the cost that the Universal Binary of Office will not spot new features other than support for the new Office formats.
Well, the problem behind this is the approach of Microsoft developing first and foremost Windows apps and Mac apps basically just for fun.
Microsoft was to arrogant to develop Internet Explorer 7 for the Mac and Windows Media Player for the Mac, because 90% of it’s core business is Windows and 10% (best-case-scenario) is Mac. Virtual PC has been cancelled, too. A users has to feel dissapointed about this and feel betrayed.
Microsoft had the power to do this, because they could, but again there is a considerable downside to this arrogant approach, when they need their own technologies cross-plattform, well they just aren’t available.
Did you ever wondered why iPod and iTunes took off? It’s cross-plattform and easy. If you make the life of users a hell by getting rid of VB, you won’t make much friends. The same applies to the Office 12-format which is Windows-only for the next 3 to 4 months till a converter is available.
Adobe does it very differently, they do Windows and Mac apps just in sync e.g. Creative Suite or Acrobat. They (i.e. Adobe and Macromedia) get together and think about how to make a cross-platform solution for Windows and Mac.
The problem of scripting does exist in Acrobat 8, too. But on Acrobat 7 and 8 there is no such problem, because whoever wants to do cross-platform scripting never uses Visual Basic, they use JavaScript instead. And it works fine and on both systems!
Another arrogant move is introducing an XML-based Office 12 format which is Windows-only. Adobe has an XML-based PDF format which is cross-platform. It runs on Mac and Windows.
What can you do now?
1) Port VisualBasic to Mac OS X on Intel with Xcode 3 on Leopard (Mac OS X 10.5). Hire new Leopard-savvy developers for this. It’s a lot nicer too delay Office for Mac 6-8 months than searching a new job in about two years from now, is it?
2) In the future try to develop Mac and Windows apps in sync. Take a page from Adobe’s notebook and get smarter, a lot smarter.
3) Treat Mac users like human beings not just ‘cows to milk’. Adobe / Macromedia is quite too big for Microsoft to ignore them. And Apple is more successful with iTunes and iPod, because it works flawless on Mac and Windows. Think about it.
By the way, if you had a cross-platform scripting abstraction layer, you could translate such scripting files into a Windows- or Mac-format on runtime. But for this to take off, you would need one cross-platform solution for Windows Vista and Mac OS X 10.5.
Never the less, all the very best for the future.Take a deep breath and try jogging with an Nike-enalbled iPod. It works on Windows and Mac. Maybe this way you get better ideas.
Apple used to say that Microsoft has no taste. Well, Microsoft has fixed that, but they are still to arrogant. Consider being more open, less arrogant and think first and fore most what your users want to accomplish.
Maybe this gives you some clues what to do.
And whoever claims making great products for Mac and Windows doesn’t work, well check out Adobe. They are living prove that it works just fine. First you have to change your attitude towards your user base.
Read Dale Carnegie, maybe it helps…
)
Top 10 points of view/suggestions from someone who lives and breathes on Apple gear in a mostly Windows world. (in a somewhat particular, well maybe not, order)
1) Getting through this “transition” stage is going to be rough. I’m sure many of the MacBU team were wide eyed when Apple announced the move from PPC to Intel. This has exposed the legacy code for what it is. I know I had to pick my jaw up off the floor, as many products were still unfortunately not written within Apple’s development toolsets when the announcement was made.
2) I’d love to believe that Intel code is Intel code and that you can call over to the Win Office group and copy/paste. It’s far from it since each OS brings its own independent APIs – leverage the existing technologies as best you can – Rosetta, AppleScript, XML, etc. Produce what you can until the total death of VBA is complete – on both Mac and Win Office products.
3) As VBA is killed entirely, ensure that transition support is there (it seems like you’re doing this) for the major 3rd party vendors who built, no, resold their solutions based on it. If you can ensure their products will function moving forward, that’d be huge. Many folks utilize VB on the Mac without sending it roundtrip to Windows and don’t even realize they are.
4) Get to the next generation cross platform scripting/automation in Mac and Win Office AFAP (As Fast As Possible) if the VBA stuff is so old on BOTH platforms, get the braintrust working on the ‘next great thing’ TOGETHER, then get it into both Mac Office and Win Office – again, AFAP.
5) Don’t treat the ‘death of VB’ as secretive (as a marketing perspective). Honesty about a true future growth path would be better than just pulling the rug out from under people without a simplified, public explanation that things had to be redone, they’ll take some time, but the future will be good karma once more. But figure the future path and stick with a consistent message.
6) Make the next office rev Lean n Mean – a true Mac ‘suite’, worthy of being called the best ‘office suite on the Mac’ instead of just ‘the only choice’. Don’t try to make Word the be-all editor for web, DTP, and such. Focus needs to return to each aspect of the suite. (This being said as competition is obviously increasing with the resurgence of Apple in general) But don’t go overboard either. There’s a lot of insight in the “remember how people stuck with Word 5.x after 6.x came out?” comments.
7) Don’t get so caught up in Mac-ify-ing things for glitz that getting back to 100% cross platform compatibility never occurs again – it will hurt the Microsoft on Mac perceptions irreparably, and possibly tank the MacBUs reputation permanently. I think if there’s a ‘light at the end of the tunnel’ it can buy you time to get it done and shipped, but even that time will be limited.
People do use Office on the Mac independently – never sharing with Windows users or others. But more and more, people are using its outputs collaboratively, in workgroups, with designed workflows, server shares, restrictions, quotas, etc. Don’t think simply within the confines of Microsoft’s own server solutions – be aware that those collaborative environments are built atop a new OS X ecosystem of its own.
Just skimming the MS Kbase alone, the Office Suite Self-Centerdness (not that you guys are, just that the suite itself seems to be) seems to also plague the Win Office releases when deployed in highly managed Windows Server environments too, though maybe not as acutely.
9) As the previous poster noted – Releases that are in sync (Mac/Windows) would be huge, though I suspect that the resources on the Win Office side of the house are probably 5x Mac BU’s. If so, that’s just disheartening, as it would probably prevent this from ever happening. Hopefully the powers that be within Microsoft can be made aware and make the necessary changes.
10) Don’t give up! The work you do must be extremely rewarding in the long run. Make your mark! Us Mac afficionados await what’s next!
I’m a translator. I make a living using a CAT (computer-assisted translation) tool called Wordfast, which is a series of macros that build a database of phrases and interactively suggest the best match. It’s fast, finding matches in less than 0.5 sec among thousands of entries. It’s the only CAT-tool available for Mac and I’ve been using it for four years.
As of today, the Wordfast forum at Yahoo has 4833 members (http://tech.groups.yahoo.com/group/wordfast/members).
Proz, one of several translator-resource sites, currently reports 8535 members owning Wordfast (http://www.proz.com/cat).
For the sake of using whole numbers, I’d say there are at least 10,000 users of Wordfast out there. Of those, about 4% would be Mac users, right? To that’s 400 less copies of Office 2007 for Mac you will be selling.
Daniel
I agree with all of the expressesd sentiment regarding the importance of VB to the corporate market – it is a key component. That said, instead of porting it, would it be possible to work with Apple to write some Rosetta ‘glue’ so you could just keep VB running in emulation within the native Office? I suspect the engineering work would be relatively (relative to porting VB) simpler and shared with Apple. Yes macros would be slow compared to the rest of the system, but I doubt very much slower except for the most complex among them.
This provides a real ‘win-win’ since MacBU doesn’t have to port the code, yet Office 2007 retains it’s cross-platform capabilities. All they would mostly have to do is maintain the glue and any bug fixes to VB (but no more than they do now).
Thoughts?
Ok – I should have read the entire article first (I went striaght for the comments) as this is obviously directly explored and rejected. I do agree it would add complexity, but there are no easy solutions here. Given the focus, couldn’t it be possible to offer a ported version of VB at a later date? That could preserve the current schedule, while allowing the MacBU to focus testing/rework efforts on VB after GM and resources become a bit less scarce.
I agree this isn’t perfect and still has them reworking old code – but I’m afraid there isn’t really a good alternative. Droping support entirely is the least best option as it drives office (eventually) out of the corporate world. Not right away, but it will curtain sales of office (as pointed out ad naseum here). I know the smart folks at the MacBU realize this, so obviously they’re taking a calculated risk. How much risk? Probably not much in the near-term, at least once the WinOffice ’07 converters are available. Few corporations are going to immediately buy and deploy new versions of Office on either platform – they’ll start their integration testing, etc. Most corporations will keep the current Office ’04 + converters in place for now and it will work just fine. Long-term, though, the landscape changes considerably.
Over time corporate IT departments will turn their plans to phasing out Office on the Mac and looking to alternatives, such as Parallels + WinOffice, especially given Parallel’s new abilities to run Windows apps in a seamless window off a bootcamp drive. This will satisfy them, since it becomes a single support solution, while still allowing those ‘Mac heads’ to keep their current systems.
The morale of this story is that the MacBU could still turn it’s attention to porting VB, warts and all, over a greater timeframe than the main application. If they took that course and announced it will be delivered later this year (or heck, even early next year), it would change everything.
1. Corporate users would be fine keeping what they have today (plus ’07 converters) AND be able to justify Mac purchases going forward.
2. IT depts. would be assured that the new functionality was coming and could plan their testing/roll-out, etc. To them there would be no break in functionality.
3. Small-business/home/etc. users will purchase MacOffice ’07 when it ships (those that don’t need VB support). So they get a new release AND they get to debug it before corporate users get it later on. This is a good thing as there will be several bugs fixed before the VB-edition would be available.
So, while the cost and complexity is there, the pros outweigh the cons from a customer standpoint. We understand it isn’t easy (working with old, crufty code never is); however, it is truly necessary for the long-term longevity of MacBU. Not today, or probably next year, but starting in ’08 without VBA, MacOffice sales into the corporation will start to falter.
And no one wants to see that!
Delay the release, however long necessary.
Without VBA support, we will not be upgrading. In fact, I may need to pro-actively purchase Office 2004 licenses so I am not forced to use broken Office release. Because without VBA support, Office is broken.
Pingback: Blog personal de Vicent Cubells » Blog Archive » Maldecaps
For a further typical example of how people are hurt by not having vb6 in Excel, just go to my website at http://www.japaneselearningtools.com.
Honestly, if Office for Mac isn’t compatible with anything but itself, I can’t think of any reason for anyone to buy it (except if they are ignorantly assuming it can read Windows Office documents). Claiming compatibility without vb support is basically a marketing invention and not compatibility in any real sense (WAAAYYYY too many spreadsheets have macros for any organization that uses Excel to find this acceptable).
I can’t argue whether it is worth Microsoft’s resources to port VB6 to Office for Mac, but if it’s not, then just kill the product. There’s no reason to release a product if people will only buy it by mistake (i.e., thinking it will read Windows Office documents). There are plenty of free and cheap alternatives that read Office documents without macros, and none of them are used by businesses either.
I use VBA extensively in my use of Excel and Word to interface with 3rd party SDK’s. However, I think given the problems, go ahead and throw VBA out. I would rather have the R&D time spent on making the existing product work more efficiently than throwing away time and money.
That being said, I would like to see a “Rosetta-like” translation of code. VBA instructions written on Win Office get a checkbox to “Compile for Mac”, AppleScript instructions on Mac Office get a checkbox to “Compile for Win”. Each office product would then be able to translate the instructions into it’s native format. It’s a sort of .NET approach where it doesn’t matter what language it’s written in. Would it be possible to have the Mac / Win Office BU’s get together on this?
May I make a suggestion: either make the new XML Office converters available for ’04, or release ’07 and work on the VBA as a later addon (i.e. after 5-10 months, or however long it takes to port VBA to XCode/Mac-Intel). This might make users frustrated, but they won’t go lynching you over the fact they have /no/ VBA support at all.
Just my suggestion.
Also, I agree with the majority of the people on this blog: Make the next scripting language cross-platform from the get-go. If you (and WinOffice) do, you will hear the collective sigh of non-frustration as MacOffice users will use this language gracefully with their Windows neighbors.
Madd,
The converters are going to be released for ’04 in a few months – that’s already announced. For folks asking MS to use a cross-platform scripting language, they really have no impetous at this point, given the large install base of folks that know VB already.
Instead, if they took the Monad approach, where it was a generic scripting engine with language plug-ins, then VB is just one of the options, AS could be another, Perl, etc.
All I can really tell you is that Office 2004 for Mac is just terrible. I would like to see Microsoft office the same on both Win and Mac platforms.
On the Mac it is not really worth the money because it turns out to be a substandard product when compared side by side to it’s Windows counterpart. Office 2004 doesn’t even come close. Even the wizards are a goofy substandard version.
For example, viewing page layout after completing the envelope wizard, the text is there. Looks great and ready to print. Click over to Normal View or Preview and the text is gone… and that’s what it prints… a blank page. I’m no expert, but if this were Windows, it would have been fixed already and two hours later, I wouldn’t be typing this on Schwieb’s blog.
Why can’t Microsoft just make one source for Office and port it to Windows, OSX or other platforms? How hard could this possibly be?
Thanks.
It seems like REAL Basic is a viable solution, and the syntax should only need minor tweeks from what we’re used to – as well as be cross platform.
My bigger question is what happens to our user-defined functions and formulae in the new version of Excel?
A followup to my previous post.
I wandered through CompUSA today checking out the new Mac Books and I tried Excel 2004. Under the Macros area it offers a choice of either the VBA Editor or the Real Basic Editor – built in!
Does anybody know about the built-in Real Basic editor or will it also go unsupported in 2007?
I have noticed that people continue to add to this thread, and that many have suggested RealBasic as a possible workaround for the elimination of VBA support. Others have suggested open-sourcing the VBA code.
It seems pretty clear from reading these posts that cross-platform compatibility is higher on Mac customers’ priority list than you thought. Given the substantial impact the loss of VBA has on cross-platform compatibility, I wonder if you could respond to these suggestions, and give us an idea whether tweaking RealBasic or open-sourcing VBA are under consideration as possible solutions or, if not, what the barriers are.
Also nice would be some indication whether the “next generation” scripting language will be cross-platform, and Mac compatible.
Thanks
Carroll Wills
P.S. FWIW Though I am not a “power user”, I also believe that cross-platform compatibility is, and should be the highest priority. MacOffice is a great product, but its single most important feature is the universal file formats, which allow us to work in a Windows world. I daresay that, for the vast majority of us, Office 2004 will continue to be useful for sometime ahead, but only if it can play well with Windows … in whatever form it takes.
My .02
I noticed a post on Endnote, but no follow up – does elimination of VB in Office mean that Endnote will not work with future versions of Office? In my field (academic biologist), probably half my peers use Macs, and if they are writing a grant or a manuscript, probably half of them (or more) use Endnote for reference management. If future office versions won’t work with Endnote, that’s a lot of lost upgrades, and a significant problem for a large market. I for one wouldn’t be able to upgrade of Endnote won’t work in future.
Sorry, I only took enough time to read through half the above comments.
My suggestion to your problem :
- publish the current Mac VBA / VBE etc. code to open source
- contribute one FTE (full-time equivalent) to answer questions from the open-source community
- open handles between Mac Office and VBA, and implement a scripting engine plugin architecture between Mac Office and Automator/AppleScript.
This way, you could expect the open source community to design, develop, test and deliver an open-source VBA engine to plug into that architecture, maybe even in time for the Office 2007 product release.
If you could finance some of that development (or tesing), that would be even greater … !
I wonder how NeoOffice manages to have VB when Microsoft can’t do it.
What I most need to be able to do is complete spreadsheets issued to me by my clients/suppliers which are built on Excel macros. (E.g. I regularly need to fill out time sheets and accounting information.) Occasionly I also get send Word documents with macros that I need to be able to complete.
I don’t know whether there is an easy way you could achieve this.
Oh and I find the “Record, Macro” function quite handy. Please make sure this can still be done with AppleScript. (Actually can you give us this as an update to Office 2004? It would give us a chance to prepare for the change.)
There’s probably a reason I don’t understand why you can’t do this but I thought I’d ask anyway: Could you have a PowerPC-only build of Offic 2008 that keeps the VBA? That way users who need VBA for cross-platform compatibility could continue running under Rosetta (it’s more than satisfactory IMHO) until you work out what to do for future versions.
I am not a developer. I am a professor of forestry and hydrology at a university in California. I just heard the news about VB not working on my new MacPro for the next Excel version. I guess the users in the trenches are the last to know.
Our department has one Mac lab and one PC lab. We teach both platforms in order to provide students with the ability to work in both environments. As such, we have to have cross-platform functionality.
I have written dozens of Excel VB programs for our students and our college. They are used on Macs and PCs alike. I’m sure a programmer would wonder what I am thinking if I shared my code, but the point is, that I can do it, and the programs work.
Literally, I have spent thousands of hours over the past 15 years writing vb in Excel. For example, my graduation planning program has been in service since 1991 and still works fine. Nearly 2000 students have used it, on both Macs and PCs. Another program was written for managing an urban forestry database. It is 13 MBs of code. Why in Excel? Because that’s what the majority of the everyday users know, and they can use it with minimal instruction and with familiarity.
Excel is a fantastic program and I have taken every opportunity to expose our students to its capabilities.
Now what?
Run a whole computer lab with Parallels?
Stay with Excel 2004 until I die?
Only hire new faculty that use PCs or don’t use VB?
Dumb down the curriculum using non-VB spreadsheets?
I’ve never seen such a disservice to MS users in my life. Rather than share my feelings, I’d rather ENCOURAGE RECONSIDERATION. We have been faithful MS proponents since Excel 1.5. Don’t leave us without feasible or realistic alternatives.
What do I want? I want VB in Excel — even if I have to wait for the next release.
This appears to be consistent with the the “Thou shalt not allow any Microsoft product to be used to create anthing resembling applications on a Mac.” rule. The only reason that I continue to purchase Office is the cross-platform compatibility. Now that this is gone I see no reason to put up with the “Microsoft treatment” any longer.
The same lame excuse was used by the IE developement group when asked why does IE _still_ not support XHTML in a standards-based way. What it boiled down to was a choice between doing it correct after several years of doing nothing and slipping the release schedule or leave it broken with promises to fix it now that they can catch their breath.
Cross-platform compatibility or nothing is how I feel. Stop wasting time making excuses and get to work _now_ on doing it right!
What about a VB – applescript converter. This would allow a Mac user to take VB code, run a converter on that translates it to Apple script allowing them to run it, alternatively, they could take an applescript and convert it to VB. Certainly going the other direction would require certain rules to be followed (Can only use vocabulary in the Office AppleScript dictionary) My concern is not having VB per say, it’s being able to ineteroperate with Windows users. The converter doesn’t necessarily have to convert VB sicne VBA is going away on the windows, side as well eventually, but if it did the latest and greatest application programing that would be far better then not being able to run them at all.
Mustafa’s suggestion from Feb. 9th is interesting and I think deserves consideration. Much like how we now have the situation of only having access to certain Internet Plug-ins if we run Safari via Rosetta (like Shockwave, and others), make VBA an option only if people check the “Open in Rosetta” box.
That way, you don’t have to port anything, and people still get access to the new features of Office. Then, when you’re ready to release the x.5 release and have figured out how to get VBA to be fully native, the first time Office notices itself being launched on an Intel Mac via Rosetta it can pop up a dialog box saying “Thanks for your patience! You can uncheck that box now!”