eLearning and screencasts in particular seem to be all the rage to the point they are even replacing online documentation for some vendors. This development raises my Irish a bit, because I never think buzzwords and fads should substitute for real support documentation.
While screen casts are great to augment online documentation and customer support sites
Here are 5 reasons screencasts annoy me.
While maintaining technical documents can be the most boring part of the technical writer’s job in some organizations, it’s a necessary part of the business especially in the federal government and other policies and procedure driven environments.
However, updating documents often falls down the list of priorities and becomes a reactionary task versus a natural element of business operations. This leads to such a simple task being flubbed and lapping up more resources and operational budget than first thought.
I am seeing more smaller contracts now for writers to come in an update technical documents especially policies and procedures guides and got to thinking how I like to update documents:
Do organizations really need technical documentation style guides? It’s a question that rises on online forums every so often and today’s ever tightening workplace budgets should also put the role of the technical documentation style guide under the spotlight as well as organizations try to squeeze even more productivity out of their technical documentation dollars.
My answer to the style guide question is “Yes, organizations do need a style guide but it shouldn’t dominate the documentation development life cycle.” With the prevalence of online documentation and the web to deliver information plus more iterative development and launch cycles, the style guide should foster productivity and consistency not stand as a roadblock in the way of technical writers and training developers making deadlines.
When I was in college, I took an on campus job in my college’s computer lab that I still consider to this day to be a very formative experience. The director of the computer lab helped me discover my technology chops that still carry me to this day. He had a penchant for scouting student employees from non-technical and liberal arts areas of study like English, Education, and Psychology. He is one of the only people in my academic and professional past I call a mentor. When I found a home working with technology, I gave up my goal of becoming a journalist for becoming a technical writer. College was tough because of my dyslexia but my job in the computer lab charted a new course for me that I am still following today.
Some people don’t have the knack for learning new software in an expedient manner even in today’s wired age which is a shame since trial versions are often just a download away from your computer if you have a broadband connection. Here are some things I learned in that job about how to learn new technologies:
I’ve been using the time since my surgery to get my health in order but my thoughts are now turning to some of the next professional moves I need to make to stay viable in the market and keep moving forward. While I like to say that I keep my wins ahead of my losses, I had some real professional disappointments leading up to my surgery and looking to rebuild professionally in the upcoming months.
Saying No to Projects was always a big problem of mine but I think I have that licked now. Here are some other things I have learned from failed projects:
On the road to refreshing my RoboHelp skills, I picked up a copy of Essentials of Adobe RoboHelp 8 HTML by Kevin Siegel from IconLogic. It’s like the substantive courseware of old so I’ve been able to use it as a reference on my own while getting back up to speed.
eLearning is increasingly seen as a way to deploy training economically. Just like other training methods, it has its place but in the flurry of cutting budgets, it can be thrust into roles where it has no real place being. Additionally, with its low barrier of entry there is a lot of crap coming out calling itself “eLearning” slapped together by people with dubious skill sets.
I am a book learner. Despite having spent chapters of my professional career in the training industry and working with trainers, I remain a book learner. Sitting in a classroom is painful for me. Unfortunately, eLearning is a fate worse than classroom training for me.
It’s rare when I don’t hear complaints about the technical editing and reviewing of documents and the QA cycle in general. This is usually unfortunate because building a document QA process that an organization can support and replicate is an integral element to releasing quality technical documentation to internal and external customers.
Here are some considerations to keep in mind when building a technical editing and QA cycle for your documents:
Microsoft Word templates can be an incredible productivity tool because they ensure a consistent look and feel across your documents freeing you up to focus on other things regarding the document you are writing.
However, Microsoft Word templates can also be a productivity sinkhole especially if you don’t put some thought into how you manage and use the template.
As Microsoft Word and the other Office applications grow in complexity, working smarter becomes a necessity because as Kelly’s Law of desktop applications says, “The application works for me, I don’t work for the application.”
It is safe to say that while Microsoft Word and Word documents (*.doc) have the crown as the most used business word processor and document format in today’s business world there are usage problems that still linger.
However, despite the wide spread use of Microsoft Word there is a whole lot of document butchering going on that can make it painful to inherit a Word document from a previous author.
© 2012-2013 Will Kelly All Rights Reserved -- Copyright notice by Blog Copyright
About Will Kelly