Office 97 for Windows doesn't run on Mac

There was a lot of debate yesterday at work about whether to state, in user documentation, what is not compatible with a software system. In this specific case, iPads and Chromebooks are not supported. The suggestion was to include that information within the user guide. The technical writers in my department do not agree. The other side of the discussion is that putting in what is not supported will prevent calls to customer support.

Let me be clear: I don't buy that argument and remain unconvinced. When given a URL to a website, I don't believe a user is going to first go to the user guide. My opinion is that the user will go to the URL first. The scenario that is being proposed seems to be cut and dry:

1. User gets URL
2. User enters URL in browser.
3. URL doesn't work.
4. User reads ""I/C are not supported" in the user guide.
5. User thinks, "Oh, well at least it's in the user guide".

In that scenario, I think the user will still call customer support if for no other reason than to ask when the URL will support I/C.

The other dimension that comes into play is that we were discussing a new user guide for a new product. The suggestion was made that we should include what isn't supported as an "exception to the rule." The suggestion to include this information in a memo, in an email, and/or in training was rejected. As I watched the flurry of emails fly, I tried to analyze what I was reading.

As a side note, I consider myself flawed. I have the curse / blessing (pick one) of the ability to see both sides of an issue.

• Is Anakin Skywalker (Darth Vader) not a hero? Consider, just for a moment, that he was just a kid that was screwed up because he was in love and when he sought acceptance from Obi-Wan Kenobi, he was put in his place. 

I'm not the only one, though, with this trait.

• Fictional characters like "How I Met Your Mother"'s Barney Stinson famously considers "Johnny" to be the hero of "The Karate Kid", not Daniel LaRuso. 
• On "The Big Bang Theory," Amy ruined "Raiders of the Lost Ark" when she told Sheldon that Indiana Jones had nothing to do with the Ark of the Covenant being recovered - the Nazis were going to find the Ark and open it anyways. 

I get the 'both sides of the coin" idea in my brain. So, yesterday, after a flurry of emails from both sides of the discussion, I offered this analysis:

---

I think there are two issues.

The first is the idea of setting a standard / precedent for this product. The product is "new" & the documentation is "new" so upon its release, we are defining rules so, right now, there are no 'exceptions' to the rules - just rules for how the documentation for our new products are going to be written.
The second issue is finding a balance between two types of information that need to be communicated effectively: what the product / system does and what it does not do.
Personally, I don't see an issue with stating, in a training class / demo / video that "This product doesn't run on ____" and not having that tidbit in the user guide. The user guide is intended to tell the user what is supported and what they need to use it.

---

During the course of the discussion, Matthew, bassist extraordinaire for Lou's Classic Ride and my co-worker, summed up the issue we, as technical writers, face. With his permission, I give you these words:

---

Back when we bought software in boxes, say Microsoft Office, the packaging would tell you what the enclosed software would run on and might occasionally say something like "This will not run on a Mac". The manual or other documentation inside would tell you only about what it did run on and how it worked.
Today, we download our software and the provider tells us up front which version to download or whether the software is for specific platforms. The documentation discusses how that software works on the platforms it supports.
I'm sticking with the industry standard here, guys. Sorry.
<snip>
We are producing the technical documentation about what the system does and how it does it. That is our job and we commit to do so as clearly and completely as possible and make changes as quickly as we can when changes to the software happen or errors in our information are found.
It not the technical documentation's job to communicate information outside that realm. We do not document policies, procedures, or what platforms the software won't work on. We're sticking to that now and setting the long term expectation.

---

Ironically, when you go to the system in question, you select a value from a drop-down and click Next. On the page that displays, there is a note at the bottom that says "NOTE: I/C are not supported." The problem is that that page won't load if you are using an I/C so the user will never know why the page didn't load.


What makes the discussion even better is that there is no sense of "You must do your job the way I say you must." Instead, it's a discussion, an honest exchange of ideas. No one wants the user experience to be negative. Customer satisfaction is everyone's goal. Whether to state "I/C are not supported" in a user guide as a way to satisfy the user is where the fine line is being drawn. We say, "It won't satisfy the user" whereas others say, "It will satisfy the user."


More developments as they happen, but probably not today.