Introduction
This is the first in what might be a series of modest entries concerning my knowledge of Microsoft Word and programming word with Visual Basic for Applications (VBA); mainly for my own benefit, but perhaps also to help anyone else interested. I am also going to dabble a little with Word Add-Ins using the .NET Framework, in preparation for the future.
Word and VBA has been around for years, and I am an amateur, so I almost certainly won't have anything original to add to the immense resources already available.
My day job is as a lawyer, but it involves a considerable amount of word processing, which has led me to develop tools for automating various tasks in Microsoft Word, to make my word processing more efficient and save time on the boring elements of document creation.
I have developed these tools both in JavaScript (through the use of .hta
files) and Visual Basic for Applications (the venerable implementation of Visual Basic within Office).
I am a champion of Word at work, and am the first port of call for many people in the team I work in (informally) before they turn to our IT department.
I think that Word is a marvellous piece of work (once you get to know its idiosyncrasies and corner-cases), and, combined with VBA (Macros), it is a powerful working environment.
Pleas To Microsoft
In the faint hope of being heard, I would like to begin with a couple of pleas to Microsoft (I know, I am one person in 500 Million users, so I have more chance of winning a lottery than being heard).
Visual Basic For Applications
I have noted a lot of rumours going round that Microsoft plans to remove Visual Basic for Applications from future incarnations of Office.
I have noted reassurances from Microsoft, at least for the next incarnation of Office (2010), that VBA would stay, but no commitment beyond that.
My suspicions are not helped by the fact that the documentation for VBA in Office 2007 is slightly more messy than for Office XP / 2003. I use old XP/2003 help files rather than those in Office 2007.
I feel nothing short of fear that Microsoft will be doing away with VBA and not replacing it with something which has the equivalent fun, ease of use, and rapid development that VBA offers. VBA is what keeps me coming back to Word, and investing in the next versions of Office, and one of the things I can actually say I love that Microsoft gave us.
VBA offers me unlimited opportunities to create productive tools for use of Word in my job, and I have created with it:-
- Document generators, that generate consumer credit loan documentation, including doing all the necessary APR calculations.
- List managers, with tools that help me manage mutli-level lists, and convert documents to my multi-level list styles.
- Cross-reference managers that give me more powerful cross-referencing functionality than that offered by Word's own dialogue box.
I would like to make a plea to Microsoft to continue to provide VBA or an equivalent, built into Office, on behalf of everyone out there who is sufficiently skilled to program VBA macros and forms, but who does not have the time (it is much more complex) or money (£600+ for Visual Studio Professional) to invest in the development of Add-Ins using the full power of Vistual Studio and VSTO. (Note: I have now actually invested in a copy of VSPro, so there Microsoft, you have my money, now keep VBA in return!)
I recognise that Office Add-Ins with .NET through Visual Studio and VSTO are brilliant and powerful, but with that power comes a level of complexity that requires time to master, and I would argue that they are virtually inaccessible to the amateur (I have read some of Microsoft's documentation on the subject, and seen nothing to change my mind on this point).
In my opinion, VBA beats .NET hands down for ease of use:-
- No need to understand the vast and complex .NET framework, COM, or Extensibility
- No need to worry about registration for Interop, registration of COM components etc
- Sufficient power to create the range of applications I am likely to need
- Rapid development (I can develop significant productive applications literally in minutes to a few hours with VBA)
- Rapid testing (no compilation step)
- No installation
- Ease of use at work (my IT team is perfectly happy with Word macros, but would shoot me dead (or worse, switch off my computer!) if I were to bring a
dll
into work with me and seek to install it in the system registry).
In effect, VBA is simple and gets you where you want to be quickly and now.
.NET on the other hand creates a huge code / knowledge barrier between you and your application, and is worse, apparently, in terms of performance according to this link: Link.
The problems that come with .NET Add-Ins include:-
- Need for VS Pro 2008 (You need it to use VSTO and the AppDomain features to ring-fence Add-Ins in a process, or to use the COM Shim wizard for shared add-ins)
- Having to take responsibility for garbage collection in COM Interop, due to differences between reference counting in COM and .NET tracing style of garbage collection (although NOPIAs may help in the future in C#4). It renders the whole pleasure of using Word "Null" and "Void"!
- Need to micro-manage security, with signed assemblies.
If Microsoft believes that it is rational to move from VBA, can it not provide a powerful .NET equivalent integrated into Word. I don't mind losing VBA, if something better is offered, and in return, by constantly improving VBA as a ".NET" version, you will have me upgrading forever.
If VBA goes without an equivalent replacement, Microsoft is in effect saying, that Office and Macros are dead, and that it cares only about IT professionals, not the intelligent Word users who are capable of customising word as a tool for their document production purposes.
The User Interface
Like millions of others around the world, my job involves my using Microsoft Word for large parts of the day, with complex documents, containing automatic numbering, cross references, bookmarks, and tables of contents.
Indeed, it interests me to think that, apart from sleep, Microsoft Word probably occupies a large part of my life; and I am sure (hope) that Microsoft must bear this in mind when considering its future evolution.
As a result, it must have been a brave step creating the new Ribbon UI in Word 2007, as it represented a major departure from an existing interface their millions of users had developed a day to day working relationship with.
Accordingly, as another minor plea to Microsoft, I would say, when you consider making further changes, do not forget the fact that you are creating software which we have to live with, and have already been living with, for long periods of time; software which you can only design for the "general case"; but which we, the user, then need to adapt for, bend to and fit into, our "special cases", our particular requirements and needs.
I fear that there is a trend towards removing some of the flexbility and functionality that makes Word so great to work with. Word is more than just a tool, it is a utility (like water), and with the ubiquity and market penetration of Word, comes a responsibility in my view, or indeed a social contract, to ensure that we can rely on it as being a constant and consistent friend.
You know that every feature you include, will become important to someone, and the moment you take it away, we are hoping that you offer something better. One of your maxims in API programming is "do not change the interface". The same applies to the user interface in my view.
Accordingly I would ask for one thing going forwards: do not take away (and please add to) the flexibility / cusomisability that the every day skilled amateur user enjoys (there is a world between the basic user and the IT department, and there is a world between a static interface and a full-blown .NET add-in). The more inflexible you make your user interface, the less we will like it.
I think that the Ribbon it is a good development in general, and it does undoubtably provide a cleaner interface.
There are only two niggles I have with it:
- I don't completely agree with some of the groupings of the commands - sometimes certain commands can be hard to locate; and with no ability to re-order, except through XML files, this is a slight irritation from time to time.
- If you are carrying out a task which requires the use of buttons on two ribbons, then you have extra clicks and mouse moves to move between them, when before you could nestle the relevant tool bars adjacent to each other.
No comments made on this entry.