There is a decision doc managers need to make all the time: balance savings today against expenses tomorrow; balance constantly patching a doc with tearing the whole thing down and starting anew. My solution to fixing my fence was the exact same I would have taken to patching a doc.
Yesterday we launched a new version of our developer community website. It doesn’t have many ‘community’ features as yet but that’s all to come. One thing it does now have is an HTML version of all of our product documentation, in an easily searchable format. This new format of the product documentation is largely to move us away from PDF only documentation. At present we still have a set of PDFs but they aren’t particularly usable.
What happens when the software firm you work for decides it will not deliver large printed manuals any more? Then the request comes to put everything online. Six months later, user profiles shift to the World Wide Web and you're asked to deliver HTML. In the future, a database of SGML information chunks may let us deliver anything, any which way. Today, we must devise a system that allows us to 'author once, publish many'. Such as system is crucial for software and hardware documentation. The method I chose was to go from FrameMaker to Acrobat .pdf files to HTML. I wrote in Adobe FrameMaker, then converted to .pdf files with Adobe Acrobat, and converted FrameMaker to HTML files with Quadralay WebWorks Publisher. But while we're waiting for the future, just learning SGML and diving deep into DTDs alone could be a mistake. SGML is a language which sets out structure, and most of us are concerned with content. Enter Information Mapping, or information types of your own devising. Identifying chunks of information such as a procedure for changing the default printer is extremely important. If we then mark each chunk for an index and record its type and title, we've also got the keywords for a future database.
Developing in the .NET environment requires internal documentation changes. Learn how to adjust your documentation plan so that it encompasses additional elements, such as the needs of mobile users.
Scrum, the new development methodology in the Agile development family, is fast gaining acceptance in software development. But how can writers, who have little or no experience in any of the incremental development models, adjust to this methodology? And, how does the Documentation Development Life Cycle (DDLC) change in Scrum?
Documentation departments are often faced with the challenge of quickly distributing high-quality versions of printed documentation via the company Intranet, the World Wide Web, or CD-ROM. Adobe Acrobat is a simple, cost-effective way to publish documentation for a variety of media and requires little time or technical expertise to produce professional-looking results. Technical writers and web developers can easily use Adobe Acrobat to create portable document format (PDF) files from printed documentation. They can then add links and bookmarks, create an index, produce simple interactive forms, and add multimedia components to their documents.
As simple as the concept of backing up your work might be, I am constantly surprised when I hear from even veteran Captivate developers that a project has become corrupt (the project, which was fine yesterday, won't open today). The fix? If the project won't open, there's a good chance that the only thing anyone can do is copy a backup project to the local disk and then open the backup. Oh, you don't have a backup? Ouch!
I’ve used Adobe Community Help when trying to get answers regarding Creative Suite products. I like the emphasis on searching and the integration of results that aren’t within Adobe’s domain. I think Adobe Community Help is a great example of what help can be: pulling answers and information together from various sources and formats and then showing context in search results.
Here is an example of how Search could fail. Your company Help System, a Policies guide, includes a topic concerned with contraband substances in the office. The word contraband is contained within the topic so the word will be found if users search for that specific term. However, a user who is curious about contraband substances might elect to search the Help System using another word, such as illicit. Because the word illicit isn't in the Help System, the Search will fail. There are a couple of ways to fix the problem. One way would be to add Search terms to the properties of individual topics. Another way, which I'll cover here, is to use RoboHelp's Advanced Settings for Localization to create a synonym (illicit) for contraband.
Usability is the combination of effectiveness, efficiency, and satisfaction with which the users accomplish defined goals in a given environment. User-centered documentation matches the users' mental model, thereby helping the users find information they want quickly and easily in their hour of need. The list of documentation usability criteria is fairly subjective at this time, and various opinionated discussion groups have contributed to this. Usable documentation is based on a deep understanding of the users' tasks, and this understanding can only be gained through interviewing representative users. Applying information architecture techniques, the content within documentation should be properly chunked so that the users can assimilate the information properly. Procedural guides should have a well-defined and searchable index that enables users to connect key application terms to their correct context. User-friendly documentation is always succinct, but never at the expense of omitting critical/useful information. It should be developed using a structured process so that it starts with the big picture and gradually adds lower level of details, addressing the needs of every unique group of users. Finally, the documentation must be tested among a representative group of users, and their feedback should be incorporated to make sure that it has met all of the major usability criteria.
Cognitive friction results in a digital divide between the software development community and software users. The digital divide, in turn, has a direct correlation with the usability of the application: how well can the software users learn and use the application or the product to perform their tasks and accomplish their goals. Today's Technical Communicators can help bridge this divide and reduce cognitive friction by applying industry-acclaimed usability techniques to the documentation they produce toward accelerating user acceptance of the product. Less cognitive friction means better user adoption that results in fewer calls to tech support, higher customer satisfaction, and in the long run, better brand loyalty.
Microsoft’s Visual SourceSafe was not created with technical communicators in mind. It was created for engineers writing software source code. But it is successfully used by technical writers in offices around the world to control documentation.
Let’s say that the most driven and driving developer on your team, who also happens to be a popular blogger, comes to you and asks why your end-user documentation doesn’t allow comments or ratings. Rather than stammering something about Wikipedia’s latest scandal, or reaching for imperfect responses that sound like lame excuses, do your homework and learn best practices from others who are implementing social web content that is conversational or based on community goals.
The contribution deals with the transposition of projects on the basis of the AECMA-1000D-specification. The author explains problems which exist outside aeronautics with the application of this specification.
uScrum (uncertainty Scrum) is an agile process developed by a small team at Altitude Software to manage the process of writing user documentation. uScrum manages uncertainty and the unknown, allowing writers to quickly react to changing conditions. uScrum uses orders of ignorance to understand the difficulty of tasks, allowing the team to effectively prioritize regular work together with difficult creative work.
When I initially started work on Agile Modeling (AM) I wanted to focus solely on principles and practices for effective modeling but quickly discovered that this scope was not sufficient, that I also needed to consider the issue of how to be effective at the creation and maintenance of documentation too. Some agile models will 'evolve' into official system documentation, although the vast majority will not, and therefore it is relevant to discuss how to be agile doing so.
Madcap Flare is one of the most powerful online help authoring tools on the market today. In this podcast, Paul Pehrson, MVP in the Madcap Software forums, talks about Madcap Flare in depth.
Why do we bother with models or documentation? They don't execute, and our customers pay us for working code, not pretty pictures. We bother with models to communicate. The idea is that a graphical object model can show how objects fit together more clearly than looking at the source, an interaction diagram can show a collaboration better than figuring out the call path from several class definitions. But so often the design documentation fails in this, and leaves me puzzled on my sofa.
Software documentation such as Help systems and user guides may be the best method of helping your customers to use your software effectively. However, one or more of these alternatives may be a better solution.
Writing, compiling, and maintaining documentation is a necessary evil. While moving to DITA might not improve the quality of your documentation, it can streamline the process of creating and managing those documents.
Creating an XML-based Content Management System to single-source technical publications is as simple as 1 - 2 - 3. OK, maybe it isn't quite that easy, but this article discusses how it can be done.
This paper describes how user assistance can streamline deliverables and improve product design by analyzing usage patterns from server-based content. We can then base decisions about how to improve deliverables on a thorough understanding of how customers use help content to find information and solve problems. This approach enables user assistance to add more value to both our companies and our customers by creating a three-way dialog between user assistance, the customer, and the product team. It also broadens the definition of assistance to include helping to design products that people can use without the need for instructions.
In this podcast, Nicky Bleiel says we should talk to as many users as we can — conducting on-site visits, sending surveys, gathering information from Marketing, Support, and other departments — so we can have a better understanding of our users’ needs and the formats and mediums that will work best for them. After completing this audience and needs analysis, we can then go out and create the deliverables that will best serve our users.