Office 2004: Mail Merge with Word and Excel

Posted by Pierre Igot in: Microsoft
October 19th, 2004 • 4:18 am

Not being a secretary myself, I don’t often use this kind of feature (mail merge), but I have to help out people who need it. So here I am with a letter typed in Word and an Excel worksheet containing a list of addresses to be inserted into the letter in Word in order to print a mass mailing.

It’s fairly easy to see why people are intimidated by this kind of feature and reluctant to learn how to use it unless they absolutely have to. For one thing, the entire thing is managed through a palette that is opened by going to the “Tools” menu and selecting “Data Merge Manager“.

Data Merge Manager

This “palette” is effectively a UI monster. In the Mac world, palettes are normally used to access formatting options that affect the current selection. This palette is an entirely different beast. It’s actually some kind of “wizard” that supposedly guides you through the process of creating a mail merge type of letter. Each section of the palette corresponds to one step in the process. Compare this to the Formatting Palette, where each section corresponds to a particular category of formatting. There’s nothing chronological about a palette, yet that’s exactly how the Data Merge Manager palette is designed. That in itself is already totally weird.

Then I click on the “Get Data” button in the “Data Source” section of the palette to create a link to the Excel worksheet. What does Word ask me to do? It asks me to select the sheet that contains my data!

Data for Mail Merge

Why does it have to ask this? Because for some reason, by default, every new Excel document contains three worksheets called, appropriately enough, “Sheet1“, “Sheet2” and “Sheet3“. And even if you leave “Sheet2” and “Sheet3” totally empty, as I am sure most people do, when the time comes to get the data from Word, Word has to be told that the data is in “Sheet1“!

Imagine the average secretary, who doesn’t even have any idea that Excel puts three blank sheets in each Excel document that she creates. Then she wants to create a mail merge and is asked which sheet she wants! Of course, the sheets still have their generic numbered name, so there is absolutely no indication of what the sheet contains. “Sheet1” is the one that’s selected by default, and is of course the one where the secretary has put all her data, but imagine the confusion generated by this extra step, which is totally unnecessary.

Then there is of course the issue of terminology. In the normal Mac OS X interface, each file is a document. An Excel file is an Excel document. But then when you open an Excel document with the Data Merge Manager, it asks you to “open document in workbook“. What on earth is this supposed to mean? What is a workbook? What is a worksheet? What is a document? What is a sheet?

Words fail me.

It’s not over yet. Once you’ve clicked on “OK” in that superfluous and confusing dialog box (which you have to go through each and every time you open your Word letter to edit it, by the way, even if you haven’t made any changes to your worksheet/workbook/document/whatever), the way to insert specific fields into your Word letter is… to drag and drop palette buttons (in the “Merge Field” section)! Argh. So now a palette button can be dragged and dropped into a Word document. This stuff is beyond belief.

Finally, if you want to preview the resulting mail merge, you have to open the “Preview” section of the palette and click on the first button, which is labelled “View Merged Data” and has an icon with quotation marks and “ABC” underneath the quotation marks. Presumably that’s Microsoft’s idea of a information-rich button icon. It doesn’t mean anything to me. And “View Merged Data” doesn’t mean much to me either. How about “Preview document with merged data“? It’s a tool tip. It doesn’t have to be ultra-short.

Well, I could probably go on and on. I imagine that secretaries who really do need to use this stuff on a daily basis end up mastering the art of using Microsoft’s unintuitive, non-standard, confusing interface. But really, this stuff is quite shameful.

Somebody at Microsoft would probably say: “Fine, you try and come up with a better interface for this then!” Is it really that hard? Obviously it is when you work for Microsoft.

One final note: in the second picture above, note the white artifacts around the letters in “Sheet1” and the button for the pop-up menu on the right, which is from the Mac OS circa version 1.0. Yet another example showing how Office’s support for Aqua and Quartz font smoothing is only skin-deep.


5 Responses to “Office 2004: Mail Merge with Word and Excel”

  1. Pierre Igot says:

    As far as I remember, it was already like that in previous versions. Choosing the fields from a drop-down “Insert” menu was also the UI that I expected. These drag-and-drop buttons are just weird.

  2. Patrick Wynne says:

    Wow, that’s bad. To support the users of our app here at work, I occasionally have to work with merge documents in WinWord2k and it’s much better about how to build your merge doc. Not perfect, but not that hard, either. After selecting your data source and determining which kind of merge document you want (letters, labels, etc), you add the fields from a dropdown menu on a toolbar. Looks like MS has combined the Mail Merge Helper window with the toolbar. Ouch.

    What was MacWord like in previous versions? Is this horrific palette thing a new “feature”? Just curious.

  3. Henry Neugass says:

    About a year ago I needed to turn a spreadsheet containing a 100-name school roster (student name, student address, parent 1 name, parent 2 telephone, … etc. etc.) into a directory “book”. There were lots of complications — family structures simply aren’t simple any more. I ended using MailMerge in Word X?

    I was successful in a reasonably short time. Of this experience, I recall nothing but three realizations: 1) The user interface was a thin and awkward veener controlling more or less the same methodology I used over 20 years ago for similar functions in Wordstar: “dot commands” embedded in the document text. 2) How in the world would a civilian learn to use this incredibly non-intuitive interface? Finally, 3), that I did NOT want to remember how to use the interface.

    The screen shot looks only partly familiar, so I’m guessing that the UI did change somewhat in Word 2004. I’m not going to bother checking to see if functionality changed. It is a good bet it didn’t. There’s little scope for improvement using a 25-year old model.

    I think this example confirms again that MS has a strong rule against any functional changes, perhaps simply to save money, or possibly to avoid dealing with archaic spaghetti code. Even the most revolutionary new mail-merge functionality isn’t going to sell any more copies of Office, right?

    Building good UI’s is difficult work even for expensive experts. I’m guessing that MS assigns, well, just about anyone to design UI’s and third-tier interfaces like this one are done as training tasks by the least experienced folks.

    Finally, I’ll bet there’s really very little coordination between the UI and the functionality. Since the programming tasks are really quite independent, why expend the effort to coordinate form and functionality? A good designer knows that the two are intimately involved with each other, but …

    If there’s little coordination between form and functionality, is it any surprise that the Mail Merge UI is so –well– disconnected from what users actually do.

  4. Pierre Igot says:

    Good point about the lack of coordination between the UI and the functionality. The whole Data Merge thing is field-based, and the UI is just layer of veneer on top of actions involving field codes. Microsoft are actually generous enough to include a “View Field Codes” button in the “Data Merge Manager” palette — which is a tacit admission that fine-tuning data merge functions might require fiddling with field codes.

    As we all know, you cannot develop the UI independently from the functionality, but it looks like that’s what Microsoft does on a regular basis. And since their team of UI designers cannot decide whether the UI should use toolbars, palettes or wizards, we end up with a mix of everything. What a mess.

  5. Henry Neugass says:

    I don’t think they feel under _any_ pressure to get it right (elegant , concise, clear, consistent, etc.) in any given release, because there isn’t, in fact, any such pressure, as there’s no viable alternative product for most users.

    Under the circumstances, why waste money, especially on some very difficult issues?

    To sum up: You and I and some others who have joined this and similar discussions have different aims, but generally share a conviction that to do precise work, we need precise tools. The mail merge tool is … not exactly precise, but it is ultimately possible to achieve the results we want with them. You’ve pointed out a number of Word issues in which no matter what one does, the results are not strictly controllable, and I think those are much more important cases.

Leave a Reply

Comments are closed.