Support : Guides
Mastering Technical Manuals
- Confidence
- Competence
- Confidence And Competence
- Enough Psychology
- Documentation - Cost and Quality
- The Magic Recipe
- Required Elements
- By The Numbers
Introduction
Whether you are a novice or expert computer user the need to get up to speed and be productive rapidly using new computer technologies are the same. Be it mastering the use of a word processor, spreadsheet, database, drawing, game, communications or sophisticated software development suite, the objectives are identical. How can you "get up to speed" as quickly as possible? This discussion is intended to help you learn how to do precisely that.
During my career I've had many occasions when I've encountered new technology where I have had to get up to "expert" level of proficiency immediately. I've led and managed technical teams that have also had to "get up to speed" and in a jiffy in order to tackle a critical task. To a large extent, I credit my academic background for having learned the basics of mastering large amounts of technical data rapidly. It required more than merely an academic atmosphere to develop a sure fired method of digesting large amounts of new technical data, it requires experience, trial and error.
What I've developed is a method that I've found to work exceptionally well, both for myself and members of the teams that I've had the privilege to work with. I've developed a modification of the technique for developing presentation materials, for use during technical skill transfers for support teams, clients, customers, and customers of clients. The process is quite simple.
Most folks need only to understand the process cycle of achieving "confidence" to achieve "competence". This is something that candidates in master's in business must work with on a continuing basis when developing personnel. And, the process applies to us all. Putting it to work in the area of computer technologies can be of tremendous benefit to anyone. The key is, determine the level of confidence that must be attained, then address the level of competence that must be achieved. Sound simple enough? Well, there's a little more to it. Let's see if I can make it just that simple.
Confidence
As human beings we tend to short circuit ourselves on a regular basis. There are many things that we would like to do, but choose not to because we maintain a belief that we cannot succeed. And that's the rub. When it comes to confidence we generally either lack self-confidence in a particular area or we have too much false-confidence in the area. So, in the area of confidence it's critical to be 100% honest with ourselves. Be 100% certain of the things you ARE confident in and equally 100% certain of those things you ARE NOT. If you operate from any level of false-confidence, you're are doomed to a near and immediate failure. The prospects of achieving "competence" are dashed, if not entirely out of grasp altogether.
To summarize up to this point, "Confidence" is a critical aspect in being able to ingest new materials that one is not already familiar with. Simply put, if you lack the confidence of being able to achieve, any level of expertise in a technical area, you've doomed your chances of success before starting.
Competence
What really is "Competence" and how do we achieve it?
Being competent means being capable of successfully achieving a task. Generally something we've done before, and with some degree of success.
A lack of competence, generally means we have more to learn before being able to achieve a level of ability to perform a specific task. Competence also means that one has a firm grasp of what they do and do not know involving a specific area and confidence in that knowledge.
Competence And Confidence
Achieving a level of competence instills an honest level of confidence. I must emphasize "honest", as again we as human beings tend to get carried away when we achieve a little success, and are often tempted to carry our exuberance above and beyond our real level of competence. While working with technology, the sooner one learns that when they begin to feel like they really know what they're doing, watch out mistakes are just around the corner. Keep watch over that feeling of "over confidence". Think "competence" or else a silly mistake may severely diminish that necessary confidence you've worked so hard to attain up to that point.
One of the most important things to remember is that confidence provides us with the necessary energy to address an issue. Without confidence, we most often fail; if we even try at all. Then, as we successfully accomplish a task, we build a degree of competence. This is key to the equation. Competence is something that we build upon; hopefully everyday of our lives. And, confidence is something that we continually challenge and expand the scope of things that we do have self-confidence in.
To summarize again. If we acknowledge that our human processes are continually engaged in a cycle of building confidence, then competence, and continually repeating this cycle, we are a hop, skip and a jump ahead of many who continually struggle lacking in the belief that "an old dog really can learn new tricks!"
Enough Psychology
Sure, we're only human beings. Fundamentally, we are all very much alike, with us all having our very special differences. Okay, then enough said about that. But, keep in mind, when it comes to learning new things, you're confronting your own psyche. Recognizing some of those basis principles just might open your mind to making things a little easier for yourself.
Now onto how to mastering new computer applications programs and systems! That's why you're here, right?
Documentation - Cost and Quality
Computer applications and systems are highly sophisticated complex sets of functions and features. The difference between a computer application and a computer system is merely that a computer application is a "stand-alone" unit, where a computer system is a combination of related and interrelated units. Keep that in mind when you're learning new computer skills. Knowing the difference can help you determine what it is that you're trying to learn about, and help point you in the right direction at the start.
Computer software, which includes both applications and systems, as you've probably already discovered is or can be fairly expensive. Many people wonder just why this is. The answer is actually pretty simple. The cost of designing and developing software is not that expensive. Add to that the cost of packaging, shipping, marketing, and sales of the software and, as with most commodities, the price at the pump is much higher that it started when it left the factory. As far as computer software is concerned, the obvious is not always so obvious. And, belief it or not, technical support is typically a cost killer for computer software manufacturers. And, for that reason...
One of the primary costs of software development is, guess what? The documentation. That's right, user guides and reference materials. And, this also includes the software internal documentation; such as, the online help, user prompts, and instructional text within the software's user interfaces. There's a lot more there than meets the eye.
The more complex the software is, the more comprehensive the documentation must be. A software package can have all the functions and features available, but if no one knows how to use them, what good are they? There is another aspect of documentation that a lot of folks take for granted. That has to do with accuracy. That's right. Accuracy.
The aspects of accuracy in a software package's documentation is crucial to the success of the software. Sure, we think of a software package performing accurately. We know and have encountered software bugs or "glitches", but how about the documentation. Billions of dollars each year are spent on software quality assurance, but generally the computer user doesn't even begin to think about what goes into the development of those manuals that are collecting dust on a shelf over there in the corner. It is not uncommon at all for the actual development cost of a software package's documentation, to far exceed that of developing the software that it documents. That's right! And, surprisingly it's generally the case.
So, why is that you might ask? Imagine having your software's user manual being riddled with errors. The manual says to accomplish this task, do such and such. And, you do as it states, but the expected results as described in the manual simply don't occur. Is that a software problem or a documentation problem? The answer to that question, it's a product problem. It's up to the manufacturer to determine where the actual problem is, and what kind of a problem it is. The documentation is a crucial part of the product.
Software manufacturers deal with legalities that most folks do not even begin to consider. The more powerful a software package is, the more dangerously destructive it can potentially be. If a software manufacturer's product is found responsible for having resulted in the destruction of valuable information, or worse destruction of property, or even worse loss or injury to life, then that manufacturer has a serious legal issue. Even if the software is not destructive, the software manufacturer is at risk of liability under a false advertising law suit.
Software manufacturers must be very diligent about not only quality assurance with respect to their software, but also their product's documentation. And the good ones are. Personally, I judge software packages by not only by their functions, features, ease of use, and performance, but also on their documentation. If you compare, you will quickly be able to separate good software packages from bad, almost exclusively on the quality of their documentation.
So, why all this discussion about documentation, its cost and accuracy? Well, need you ask? Documentation is essential if you really want to get up to speed and develop your level expertise with a new software package; at least if you want to achieve that expertise rapidly. If you're not in a hurry to get up to speed, you very possibly never will, but most likely if that's the situation, you didn't have the need to establish a level of expertise with it anyway. Just use the functions that are easy to use and press on to other things.
The Magic Recipe
We've emphasized the importance of a software package's documentation. That's because to learn all of the aspects of a software package, you must become familiar with it. You can try out the software and get a feeling of how it performs, but you MUST read in order to learn all about the functions and features, and how to use them.
Most all user guides, references and manuals are structured the same. There are three absolutely required elements. If any of these elements are missing from a software's documentation package, they flunk. These required elements are:
Required Elements
- Table Of Contents
- Body
- Index
And a fourth element not absolutely required, but it is preferable to be present is a Glossary.
Don't allow me to loose you here. You probably already know about the structure and format of any good reference material. Computer software documentation is no exception. The key is knowing how to use them and how to become familiar with them quickly, so when you need them you can put them to work without a lot of wasted time flipping pages and missing exactly what it was you were looking for in the first place. You need to be able to get back right where you left off without hesitation or interruption.
Here's what to do. When you obtain a new software package, open it up and take inventory of everything included. Fill out your registration forms. Read any last minute notes they might have been inserted during final packaging. Check the packing list; and there should be one. Make sure you have everything you are supposed to and paid your hard earned money for.
Next, go ahead and begin installation. Be certain that you read any last minute information that is contained on the software's media, such as READ ME files. Often that information will contain important last minute information having to do with the installation of the software that was discovered after the original documentation package was prepared. You can save yourself a lot of wasted time by spending just a few minutes quickly scanning through those files to be certain there is nothing essential you need to know before installing your software package.
Oh, I didn't mention performing a back-up each and every time you install new software. I didn't mention it, because you already do that as a matter of regular practice. Right? If not, you should. Really, you should. Think of it as a small investment of time to protect your much larger investment in time and resources.
Next, take a look at the documentation. Most folks look at it once, put it on a shelf and maybe pull it down to look something up when they need to. Generally, they fly by the seat of their pants using whatever intuitive functions and features they're probably already accustomed to from working with other applications. They may learn the few features that caused them to purchase the particular package, and that's that. Oh, but you miss so much when that's how its done. Here's how to invest just a little bit of time and get the most out of your investment, and establish a level of expertise all at the same time and do it quickly! It's so simple, it's ridiculous.
By The Numbers
-
Read the Table of Contents carefully like you're reading a chapter. Don't jump ahead. Read it a line at a time.
-
Read the Index. That's right, the Index. I'll discuss this in a minute. Do this the same way as the Table of Contents.
-
If there is a Glossary, read it too.
-
Read the Chapter Titles, Subtitles and Section Heading. Skip the actual body of the Chapters.
- Finally, read the Chapters. Breeze through them, do not hesitate or pause with items that may not be immediately understood. The objective is to become familiar with the manual, its content and its format.
Okay. At this point what you've done is two things. One, you've become familiar with the structure of the manual. Two, you've been exposed to any new terms and hopefully a possible understanding of those terms. What you have yet to accomplish is an actual understanding of what is being conveyed in the manual itself.
The single most important element of any manual is its Index. When the time comes to reach for an answer in the manual, you should be able to go straight to the Index and find the page, or pages, where the issue is discussed in detail. That's the reason for reading the Index. The Index provides you a snapshot of how the documentation authors set up the manual, and how they have use the vernacular to describe the various technical aspects. One manufacture may refer to something as a "widget" and another manufacturer may describe the same item or concept as a "thingamajig". It's important to learn right away how the authors are conveying the material and reading the Index serves a dual purpose of doing precisely that. It provides a introduction to how to use it when the time comes to look up that particular term or concept. At least you'll have a better chance of recalling that thing is a "widget" or a "thingamajig".
Having read the Table of Contents provides you with the lay of the land inside the manual. Its important to understand the primary topics the manual discusses and how the information pertaining to the software package is organized and arranged. This is important when preparing to read through the material in detail. The Table Of Contents is a generalized grouping of the subject material. It's not usually specific. Often the Tables of Contents include chapter sections and subsections. This can be useful in looking up issues by topic, but to find the specifics use the Indices. If the manual doesn't have an Index, the likelihood is you should seriously consider exchanging the entire software package for a manufacturer that does include an Index. Of course, this is based on my experience. You'll learn from you own.
Before more than a week or two passes read through the entire manual; cover to cover. Start at chapter one and continue through to the end. I recommend reading through it briskly, without stopping to study new issues or concepts you do not understand. Very often, authors of technical manuals have considerable insight to their reading audience and repeat important conceptual information more than once as it pertains more specifically. More often than not aspects are introduced, then expanded upon a few pages later; at least the good technical references do. So, use that "confidence" in both yourself and the authors to turn the page and continue reading uninterrupted. Consider marking pages. I use yellow stickies for pages containing information that has particular interest, or requires further study. The objective at this point is still, becoming familiar with the manual itself in its entirety. After having done this, you can then revisit the areas that deal with your particular interests.
After having done the above you should have a comprehensive understanding of the capabilities, functions and features of your software. You may not have the immediate knowledge to exploit all its functions, but you should have a very good idea of what the software can and can not do. Knowing a software package's limitations and restrictions can often be as valuable as knowing its functions and capabilities. And, best of all, you'll know where to get answers when you need them. Now, when your manual sits on the shelf collecting dust it's not merely taking up space, but instead its sitting there as an old trusted friend just waiting for you to visit when a time of need arises. And, you know what they say, "A friend in need..."