Document maintenance is critical

I had two appointments this past week.  The first was one for my car to get my oil change and to make sure everything was in good working order (it was).  A couple of days later, I had a dentist appointment.  It was a routine cleaning (I also had a procedure done — one that I’d been putting off for a while).  While the two appointments were for different reasons, they both served the same purpose: to perform maintenance.

Just about everything, especially anything mechanical, is going to break down over time.  Maintenance ensures that things remain in good working order.  But when we think about maintenance, we usually think about car repair, roadwork, furnaces, and water heaters.

I’m sure many people in tech industries consider periodic hardware and software maintenance.  Hardware can break down.  Drives crash occasionally.  CPUs are upgraded to keep pace with emerging technology and to support software.  Speaking of software, bug fixes are constantly made.  There’s also the matter of security; virus software definitions are constantly updated, and operating system patches are distributed to ensure computers are safe.

But here’s another question: when was the last time you maintained your documentation?  Does your documentation, which was written for, say, Version 1.0, reflect what is in Version 2.0?

The trouble with documentation, even the best-written documentation, is that it can become obsolete over time.  Processes and systems change.  Interfaces are redesigned.  Steps become more efficient, or in some cases, even eliminated.  Change happens.  It’s one of the sure things in life.  Documentation should also change as well.  How often has your help desk received calls from frustrated customers saying things like, “your instructions say ‘press the red button,’ but there’s no red button on the interface!”

If your product changes — and it inevitably will — your instructions should change with it.  It’s important that systems are maintained.  Your documentation should be maintained as well.

Advertisements

SQL Saturday #723, Rochester, NY

My next SQL Saturday is scheduled!  I will be speaking at Rochester, NY on March 24!

I’ll be giving the following two presentations:

Hope to see you there!

My first podcast interview!

About a week ago, I received an email from Carlos Chacon of SQL Data Partners inviting me to take part in a podcast.  This was my first such request, and I jumped on the opportunity.

The podcast recording took place last night.  My topic was along the lines of “writing and communication: why it matters to data professionals.”  It was a lot of fun, and I very much enjoyed talking to Carlos and his partner, Steve.

The podcast should air sometime in March.  It will be posted on their ‘blog.  When it does, I’ll make sure that I post a link to it!

What are effective communication skills?

I cam across this article on Grammarly, and I thought it spoke volumes — enough that I’m sharing it in this ‘blog article.  Read and enjoy!

Why design matters

“A user interface is like a joke. If you have to explain it, it’s not that good.”
— unknown

There are two elevators in the building where I work, including one that doubles as a freight elevator — it has front and back doors for access.  This particular elevator has a bank of buttons shown in the photo below.  The buttons for the rear door are denoted by the “R” next to the floor number.

elevator_buttons

Here’s why these buttons frustrate me.  Quickly, tell me which open and close door buttons work for the front and rear doors!  Yeah, I can’t tell, either!  You would think that the upper buttons control the front and the lower ones control the rear, but you can’t discern that from the way it’s laid out (and I’ve found that it isn’t necessarily the case).  I have had multiple occasions where I’ve tried to hold the door open for someone rushing to catch the elevator, and ended up hitting the wrong button.

Had these buttons been properly laid out, the open and close door buttons would both been placed under each respective door button column — i.e. the open and close door buttons that control the rear door should have been placed under the buttons marked “R,” which would clearly indicate that those buttons are used for the rear door.  That would make sense, wouldn’t it?

Raise your hand if you’ve ever been frustrated by a product simply because the user interface was poorly designed.  I would expect every hand in the room to be up.

Don Norman, an academic researcher considered to be an expert in usability design, talks about this phenomenon in his book, The Design of Everyday Things (disclosure: at the time of this article, I have not read this book — yet).  One very common example involves doors.  How many times have you come across a door with a handle, leading you to think you need to pull it to open the door?  Yet when you try it, it turns out that you need to push, not pull it, to open.  It’s extremely frustrating, and it happens more often than you think — so often, in fact, that it even has a name: a Norman door.

If you don’t think good design isn’t a big deal, there have been documented cases where poorly designed interfaces resulted in a significant loss of life.  I did a Google search for “disasters resulting from bad design,” and the results were startling.

This subject is of particular interest to me, speaking as someone whose job revolves extensively around technical communication, technical writing, and front-end development.  In my line of work, design and layout are a big deal.  I have seen many examples on the job of horrible documentation and bad interfaces — and poor design was a major factor.  I mentioned in an earlier article that I came across illustrations in a company document that were completely useless.  Pictures may be worth a thousand words, but if they’re not properly used — and yes, there is a wrong way to use them — they can be worth exactly zero words.  Likewise, one of my current projects is working on how to make an internal corporate social network work for my department.  I’ve discovered that I have a love/hate relationship with it; while I have no problem with the concept, the execution leaves a lot to be desired.  One of the most basic questions I have with this system which it fails to answer — and which should only be answered by the interface design without having to look up instructions — is, “where am I supposed to begin?!?”

Interfaces exist in just about every facet of our lives, including, but not limited to, application front-ends.  Good sensible design must be involved in creating them.  More often than not, they’re just “thrown together” without any thought as to how they should be laid out and how they are to be used.  The consequences of poor design abound.  In the best of cases, such as with Norman doors, they are just annoying.  But in the worst cases, they can have disastrous and fatal results.

Writing blind

“Life is like a sewer.  What you get out of it depends on what you put into it.”
— unknown

As a technical writer, one thing I often request is access to the product — whether it’s a web site, application, device, tool, etc. — that I’m writing about.  In order for me to write something about a product, I need to know what the product is, how it works, and how to use it.

Unlike, say, a novelist or a creative writer, technical writing topics usually do not originate from the writer, but from something or someone else, such as a process, procedure, or product.  In order for the writer to produce a good, quality document, he or she must know about it — what it is, why it’s significant, what it looks like, how to use it, potential issues, and so on.

What happens, however, when the only resource you have is someone else’s description?  Moreso, what happens when that person is (by his or her own admission) not a writer?  (There’s a reason why this person gave you this project in the first place.)  I recently worked on a small side project that reminded me just how important this is.  Granted, it was only a small and minor project, but it did remind me about just how critical it is for a writer to understand the subject.

Imagine the following situation: you need to add more windshield washer fluid to your car.  You open the hood and see different caps.  You know there are caps for washer fluid, engine coolant, oil, and so on.  However, they are not clearly marked (as far as you can see), and you don’t know which one is which.  Opening the wrong cap and filling it with the wrong fluid will damage your car.  You call a friend who tells you to look for a plastic reservoir filled with blue liquid.  Trouble is, there are two of them (one is washer fluid, the other is coolant).  Your friend tells you to look for something that looks like a windshield on the cap.  Okay, you see something that looks like it might be a window with a wiper going across it.  That’s it.

Sound frustrating?  These are the kinds of situations that technical writers and communicators deal with regularly and on a much larger scale.  In order to write a technical document, the writer must have a source of good data — whether it’s hands-on experience, pictures, data graphs, good descriptions, etc. — in order to write a quality document.  A bad or inaccurate source of data will often result in a bad document.

Developers, coders, and data professionals have a name for this kind of situation: garbage in, garbage out.  In order for data to be processed into information (I won’t get into it now, but there is a difference between data and information — that’s another topic for another time), you need to have good data to start.  Bad data results in bad and inaccurate information.

Writers cannot read minds.  Unless a subject matter expert (SME) can properly convey his or her idea (and it almost never happens on the first go-around), it might take several iterations and lots of SME-writer interaction before the draft is correct.

Professional chefs have a term for ensuring everything is set up and in place before cooking: mise en place (pronounced “MEES-in-plahs”).  While the technology sector does not use the same terminology, the principle still applies: make sure things are in place and ideas are properly conveyed before information processing (including documentation) can occur.  Otherwise, trash at the beginning of the process will likely result in trash at the end.

Upcoming speaking engagements

I have two speaking engagements coming up within the next few weeks:

Hope to see people there.  I can always use a good audience!