Word 2004: ‘Close’ button in footnotes/endnotes pane leaves mark

Posted by Pierre Igot in: Macintosh
July 12th, 2004 • 12:58 am

This one is not a bug. It’s just a perfect example of Microsoft’s sloppy software design work.

If you have a Word document open in Normal view mode and that document includes footnotes or endnotes, and if you then open the Footnotes/Endnotes (still in Normal view mode), here’s what it looks like:

Cursor over 'Close' button

Cursor off 'Close' button

See the problem? When the cursor is over the “Close” button, Microsoft uses its proprietary Aqua-like effect to reflect the active status of the button. But that effect causes the line of grey pixels immediately above the button to be erased. And when you take your cursor off the “Close” button, Microsoft doesn’t refresh the display so that this line of grey pixels reappears.

It’s just sloppy. And even if it has no impact on the actual use of the software, it gives the impression that one is using a rather badly designed piece of software. Which is more than just an impression, of course.

Oddly enough, if you move the bar that separates the Footnotes pane from the main document area manually using the control on the right-hand side of the window, the problem is corrected. Somehow that grey bar at the top of the Footnotes pane acquires an extra line of background pixels, and the line of grey above them is no longer affected by the behaviour of the “Close” button. But the problem reoccurs every time you open the Footnotes pane, without moving the separator bar.

Sloppy, sloppy, sloppy (and not new in Word 2004, by the way).


5 Responses to “Word 2004: ‘Close’ button in footnotes/endnotes pane leaves mark”

  1. Henry Neugass says:

    Right, I’ve reproduced this.

    Maybe I’m missing something, but it seems to me “Close” doesn’t seem to be a button in the quiescent state. On my screen when the cursor is not over this text, it has exactly the same appearance as the text “Footnotes” at the left, which is not a button at all. I’m not an expert, but this really doesn’t look very good to me — a button that doesn’t look like one.

    From a software point of view, with respect to your comments, I guess it is possible that there’s simply been a off-by-one error. I’ve made a few of these myself. I’m betting this error fell to the bottom of the priority list for just the reason you give: it has no functional impact. Well, the truth is I hate making errors like this, I will work hard even at my own expense to eliminate them, and I hate doing business with anyone who is so… sloppy.

    There’s a potentially darker side to this, though. There _should_ be very little for-purpose programming to Word’s human interface. Everything _should_ be made out of pre-fabricated functional blocks — there should be almost no traditional code at all. By now (how many years into MacOS X?) all this stuff should be fully proven, not only with respect to functionality but in terms of self-locating and checking for just this kind of error. It could be a simply off-by-one error, but if it is not, there’s a chance for something seriously broken in one of these pre-fab blocks, and that _should_ concern MS. I hope they are at least aware of which one it is.

  2. Pierre Igot says:

    The “Close” button is a “normal” button in Microsoft Word’s interface, which uses a proprietary interface for its toolbars. Try adding any button to one of your toolbars without using a button icon (i.e. with a text-only label), and you’ll see that it will look exactly the same. In their “quiescent” state — i.e. when the mouse is not hovering over them — such buttons do not look any different from regular text labels. It’s only the visual feedback you get from hovering over them with the mouse that indicates that they are buttons.

    (Office 2001 used to have a “theme” setting that let you switch to a different visual appearance for toolbars — but I don’t think that feature made it in the Mac OS X version of the software.)

    The bottom-line is that the Word toolbars are definitely not made out of pre-fabricated Mac OS X interface blocks. Microsoft has never been known for embracing Mac OS interface standards, and has always tended to force their own “standards” down Mac users’ throats. Their usual excuse is that they needed to do so because the built-in Mac OS controls were not flexible enough for their purposes. Of course, what this usually illustrates is the lack of interface design skills of Microsoft’s own designers.

    Interestingly — and distressingly — other major software vendors, such as Adobe and (gasp) FileMaker (a fully-owned Apple subsidiary), are guilty of the exact same thing. But Microsoft are typically the sloppiest of the lot.

    If you want to have “real” Mac OS X applications which are made out of Mac OS X’s own interface building blocks and do not require multiple fixes each time there is a new system update that throws non-standard interface elements off, you need to turn to smaller, independent Mac developers. But of course, it’s not exactly easy as a Mac user these days to avoid using Microsoft, Adobe, and FileMaker products altogether.

  3. Henry Neugass says:

    Sorry, I didn’t make myself very clear. UI elements are clearly available from the system, but it’s simply common and necessary practice that software vendors do as much of their work as possible using such building-block techniques, so I expect MS does, too.

    In the case of the “non-button-button” we’re discussing, someone would simply create such a button as a particularization of a generic MS Word button, which itself is (or should be) a component of a generic MS Word toolbar… and so on. The more this is done, the less actual code needs to be written, the less to be tested, and the more consistent the look-and-feel.

    I’m guessing the top priority driving use of non-standard UI components at MS is product differentiation — even though there really isn’t any effective competition from which to differentiate, which would seem to unhinge the process.

    The next priority is opportunity to innovate. (Notice: I find the MS tagline “Freedom to Innovate” as in http://www.microsoft.com/freedomtoinnovate/, incredibly distasteful, not the least because it is so self-serving.) As practiced in the Word context it seems “innovate” is a synonym for “tinker”, as in –and largely limited to– “tinkering around with the UI just enough to induce people to buy what appears to be a new version.” In effect, if MS followed the Apple guidelines, Word 2004 simply could not be made to look much different from Word X.

    This wouldn’t be worth discussing if the trend of other vendors to do the same did not appear to be increasing. There must be a common thread, and we users ought to be considering what to do/how to adapt.

    Sure, we’re used to “New Package, Same Great Ingredients” notices on our soap and toothpaste. These seem to be a feature of our system which I suppose most of us consider inconsequential noise as long as the product is reasonably cheap and functional — and our livelihoods don’t depend on them.

    In the case of the “non-button-button” design –if you can call it that– I’m willing to accept a little tinkering just as I’m willing to consider using “them” as the best available non-gender-specific third-person singular pronoun in English. (Did I get this right?)

  4. Pierre Igot says:

    In most respects, Word 2004 does not look much different from Word X! :-)

    The physical box it comes in definitely looks different, but that’s about it… and that’s more in line with your toothpaste analogy — except that toothpaste is reasonably cheap. :-/

    That analogy doesn’t work all that well, anyway. You keep buying toothpaste because you run out. You can’t run out of Word :).

    The bottom-line is that, yes, the “Close” button here works in exactly the same way as other toolbar buttons in Word, so it’s made using common “building blocks” that are used throughout the application. My problem is that the building block itself is of debatable quality — and it’s obviously not flexible enough to work properly in an environment that’s not purely a toolbar, like this striped area above the footnotes/endnotes pane.

    Anyway, that’s probably more than enough time/words devoted to this particular issue :).

  5. Henry Neugass says:

    Amen

Leave a Reply

Comments are closed.