Words and Software

Technical writing for Windows 10. (old: Intelligent Systems Service, Data Protection Manager, and Operations Manager)

December, 2005

  • Why I must install Visual Studio 2005

    I'm not a developer. I took a simplified Visual Studio basics course years ago, but I've never had anything I wanted to do with it so the few little things I learned have long been forgotten. Still, I need to download VS 2005 so I can look at the documentation because somebody likes it, according to Josh's Scooblog.

    Mickey Gousset says, "This new documentation app has a couple of cool features, and a couple of bugs that still need to be worked out. By far, the coolest feature is the Search." He gives a screenshot and good examples, but I still want to see for myself. Maybe there will be leveragable lessons...

    I also want to check out the part Mickey didn't like.

  • How not to: examples of poor UI design

    I apologize in advance -- the Interface Hall of Shame is curiously addictive. Do not go to this site if you have somewhere to be in the next hour or so.

    Non-examples are a great way to learn concepts, and the authors of this page provide a generous sampling of non-examples for:

    • Visual elements
    • Terminology
    • Tabbed dialog boxes
    • Error messages
      And much more...

    The Metaphor section even mentions a non-example I encountered many years ago, when a friend who worked at Apple demonstrated his computer for me:

    "Unfortunately, the designers decided to extend the trashcan metaphor to include the completely counterintuitive function of ejecting diskettes: drag an image of the diskette to the trashcan to eject it from the computer. The Macintosh simply took the trashcan metaphor too far. They imbued the trashcan with magical powers that are completely incompatible with the established metaphorical association of deleting files."

    I was using a Windows computer at the time, but I was willing to be convinced to switch. However, the weird thinking behind a trashcan meaning "eject" was simply too strange for me, so not only have I stuck with Windows ever since, I've also remembered that metaphor over all these years. Very cool to come across it again.

  • We interrupt this thought to bring you...

    ...another announcement. I was thinking about globalization and localization on the drive in this morning, and planning a blog post on that subject, but it came to my attention that we have a webcast this week that I should mention. So I'll postpone my global, localizable thoughts to tell you:

    Microsoft Webcast: Disk-to-Disk-to-Tape Backup with Data Protection Manager and CommVault
    Thursday, December 08, 2005 11:00 AM (GMT-08:00) Pacific Time (US & Canada)

    "In this webcast, learn how Microsoft is partnering with CommVault to deliver an integrated disk-to-disk-to-tape backup and recovery solution, extending the traditional disk-to-disk-to-tape scenario by offering freedom to recover the data regardless of media type and where it originated."
  • Protecting an Exchange server by using DPM


    Knowledge Base article 909644, "How to use Microsoft System Center Data Protection Manager 2006 to help protect an Exchange server" is published.

  • Supported - what does that mean?

    I had a friend who would install anything on his computer. "What they say is supported doesn't really mean anything," he insisted. "I can make it work." (Come to think of it, my friend and his computer were a lot like the guys in high school whose cars were usually in pieces in my driveway...)

    What brought him to mind were the questions we've gotten on whether DPM supports this operating system or that configuration. Contrasting customers' concern with supportability and the cavalier approach of "I can make it work" led me to explore exactly what it does mean that something is supported and what goes into that decision.

    What supported means is the simpler question: it means that it works, we made sure it will work, and we take responsibility for making it work. So unsupported means it may not work and we can't take responsibility for making it work. Supported and unsupported are about our agreement with our customers.

    So how does something make it to the Supported list? That's where it gets a bit more complex. To begin, think about the array of available hardware, operating system, and software configurations. Obviously, that has to be narrowed down.

    The technical aspect can rule out a number of the possibilities, such as an operating system that doesn't have the capabilities that the software requires. Market analysis provides a lot of information -- what products are people buying? What are our target audiences using? For example, we didn't invest in making the DPM end-user recovery feature support Windows 95 clients because that just wasn't an operating system that most of our target customers are using.

    The load of determining supportability falls on Test. Testing is huge. Automated testing, manual testing, stress testing, scenario testing -- and should something need to be fixed, it can mean a reset that starts every test all over again. And again. Just to give you an idea of the impact on resources, a final test pass on DPM required 50 people for two weeks. The smaller test pass of DPM with R2 took five people two weeks, and that was with 80% of the test cases automated.

    Thus, it isn't inexpensive or quick or easy, coming up with that final Supported list. And that information, including system requirements, should not be disregarded. So why is it in the smallest font and tucked away in an unimportant location on the boxes??

    For some interesting reading on software testing: