Personal Information

(This gets a bit technical, but bear with me, it'll all make sense by the end.)

One thing the macros need again and again is information about the author--their name, title, which office they are in, and various information about that office. Clearly I need to gather information about the user, and store it somewhere so they don't have to keep entering it. Therefore, I store information about the user in the registry (in HKEY_CURRENT_USER, under my own app key). If my keys aren't present when Word starts, I pop up the Personal Information dialog for the user to fill in.

But the office information is a bit trickier. I don't want 450+ people each having to type the same information about the same offices over and over, each one entering it a little bit differently. I therefore keep all the office information (address, phone number etc) in an ASCII file (offices.txt), which is stored on a server at the H&A main office in Boston. As part of their personal information, each user can then simply select their office name from a drop-down list. When Word starts, I determine which office the user has selected, read offices.txt, and use the information for that office. The office details are therefore 100% consistent, without a single user ever having to type them.

There are several cool side effects to this approach:

Simple to update. When office information changes (e.g. if an office moves, or if H&A opens a new office, both of which happen frequently), IT changes the office information in just one place--offices.txt. The change is automatically rippled to everyone in the company the next time they run Word, without having to roll out anything at all.

Each user gets their own settings. Because personal information is stored for each user, each person who logs in at a workstation has their own personal information. A temporary visitor can have their own personal information without interfering with the workstation's regular user. A public workstation maintains personal information for all the different people who use it.

Easy to visit another office. A visitor from another office can still produce documents as though they were in their own office, simply by choosing their home office in their personal information. Or, if they will be producing documents for the local office, they can choose to do that. This is the ultimate in flexibility, yet it is achieved very simply from the user's point of view.

Easy to produce documents for another office. H&A has a lot of multi-office projects. Someone in Boston can produce a document for a Tucson project by simply changing their office in their personal information for a few minutes.

Simple to maintain. H&A's stationery includes the office's address in the top right corner. The Fax Cover Sheet and Letter of Transmittal, both of which are standard documents that can be generated by the macros, look much like stationery--the office address must appear in the top right corner. In early years, I included the office information in the document templates themselves. This turned out to be a lot of work; I had to maintain separate templates for each office, and make sure that each office's WinInstall set had the right templates. Also, any time an office moved (or even so much as changed its zip code) all the templates on all workstations in that office had to be replaced. Now, the macros themselves generate the office information in the top right corner on the fly. This one fact has saved literally weeks of IT staff time.

H&A has a lot of laptops and other remote users, so I had to consider what to do about a user who isn't connected to the network and therefore can't read offices.txt when Word starts. To handle this, each time Word starts up and successfully reads the central copy of offices.txt, I cache a copy locally. If the user subsequently runs Word while they're not connected to the network, I just read the locally-cached copy instead.