With that out of the way, the conference gave me a number of things to think about. The gears are a-turnin’. (Note, this is not one of those posts that recaps the sessions I attended.)

I’m focusing in this post on one of the things I’m thinking about: using HTML5.

I’ve heard that the W3C has said not to use HTML5 because the spec won’t be ready until the end of the century (or some other seemingly extensive timeframe), but people are excited about it, and a number of browsers support its features. So why not start taking advantage?

I’ve gotten much more interested in MadCap Flare for authoring once I learned that version 8 includes a new HTML5 output that’s FRAMELESS. Heck yes. I’ve been waiting for a HATter to provide frameless Web output for years, and one that doesn’t require the side pane at all because search results appear in the topic area.

I haven’t confirmed this, but I suspect that the output isn’t strictly HTML5; I bet it still uses HTML4-compatible markup. It’s the framelessness that I care about.

But since an HTML5 page has to declare that it’s HTML5, then by having the Flare output do so, you open the door to take advantage of HTML5 features in your output.

I attended a session by Scott DeLoach on HTML5 and CSS3, and he showed how he uses styles only to create a slide-out from the side of the page. That got a gear turning.

I went to Dave Gash’s session on using HTML5′s localStorage feature to allow users to create annotations on help topics. We have already been talking about adding feedback and user rating capabilities to our WebHelp topics. So Scott’s idea for a CSS-driven slide-out widget would work great for adding all three of these to each help topic without cluttering up the topic.

I’m sure this is just the beginning of uses for HTML5 features in online help. And these slide-outs would be available only for users with browsers that support them. But according to Dave Gash, a simple JavaScript function can verify whether the browser supports HTML5, so we could base the availability of the slide-outs on the results. And if we wanted to make them available anyway, then we use JavaScript as a backup for the feedback and rating controls.

If these little things are possible with HTML5 and CSS3, how can online help really become awesome?

Bookmark It

Hide Sites

Related posts (auto-generated):

1. User Assistance Embedded in the Interface
2. A Built-in Method of Delivering User Assistance
3. Empathetic User Assistance
4. Styles in Inches and Points Improve RH-to-Word Output
5. The Technical Communicator Getting Involved in User Forums

First, I’ve devoted a lot of my attention in 2011 to fiction. I’m most of the way through my second draft of a novel. During my two-week Christmas vacation a year ago, I wrote over 27,000 words of the first draft. This last vacation, I edited and revised my way through almost the entire second half of it in my second-draft effort. I’m trying to perfect my storytelling skills. Once I complete the second draft, I’ll be reading through it in as few days as possible, just making notes as I go as to what needs fixing. Then I’ll go back and make changes accordingly.

Those who have followed the Gryphon Mountain Tales may think this strange, seeing as I haven’t posted a new tale in months. I did promise an experiment, and the experiment proved that I’m not good at serial fiction. I don’t do well when I have defined only a vague overarching storyline. I’m not saying that the Tales have died; they’ve just taken a big break.

Focusing on a novel, not to mention trying to spend time with my daughter, has left much less time for blogging here than I’ve had before.

Second, I haven’t had as much to say about tech comm this year, or at least during the last several months. As I said, I think this is related to the first cause. My mind hasn’t been on tech comm as much as before, so I haven’t had as many ideas for blog posts.

I used to have this “blog lens” through which I would view much of my professional experience. Multiple times throughout the week, I would think, “That topic would make a good blog post,” and I’d make a note. However, in much of 2011, my subconscious has been working out kinks in my novel instead.

With all of that said, however, I do have something to blog about today.

Part of the User Education team’s goals in 2011 was to have a team style guide finalized. I became the driver behind that effort. Mainly because of that, and probably because I’ve been doing a lot of writing and revising, the topic of concise writing has been on my mind.

A lot of the problem with common English usage these days is the padding. People insert words that don’t need to be there. Our wording isn’t precise. People feel like they have to add modifiers to their words to add importance or clarity when they don’t need to, resulting in redundancy and the weakening of the core idea.

Writers know that putting together a concise, clear message takes time. But I believe the first try would be closer to the mark—not to mention the final version—if we truly understand the language and use words precisely.

I’m sure you’d like an example. I’ll give you a couple.

“Return again.” What’s wrong with this phrase? Nothing, if it’s used correctly. Return means to come or go to a place you’ve been before. If you’re talking about returning the first time, the word already includes the idea of “being there again.” If you then leave a second time and come back, you are then in fact returning again. But most of the time, when I hear or read the phrase “return again,” the speaker or writer isn’t talking about a second time coming back, but rather the first.

“Each one.” This phrase is redundant. Merriam-Webster’s even shows one of the definitions of “each” to be “each one,” drawing on one of the other meanings of “each.” But when people say or write “each one,” they’re generally using “each” in the sense where it can stand alone meaning “each one,” making that “one” unnecessary.

I’m getting dizzy going in circles like this.

Anyway, my point with this example is that I don’t know if there’s ever a reason to say “each one” in speaking or writing. “Each” suffices.

These examples illustrate how easy and common it is in English, and perhaps other languages, to tack unneeded words on to other words.

To be precise in our writing, we should understand these nuances and then write, and edit, for them.

For technical communicators, precise language isn’t about persnickety grammarians with yardsticks ready to rap knuckles. Precise language means clear communication, less content for our audiences to sift through, and lower translation costs (where every word is an expense to the organization).

Precision is concision.

Note: If you find any unnecessary words in my post, let me know.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Making Learners the Teachers in E-Learning
2. The Importance of Communication Skills over Technical Skills
3. Technical Documentation for Zero-Attention Audiences
4. The English Language: Keep the Old Town Charm Alive
5. Various Languages in a Quick-Start Guide

This theme comes up time and again among our User Education team members. Yesterday, one of us gave a presentation to our community of practice about usable design, what makes something usable, and how tech writers can contribute. She suggested we come up with some metrics that help us demonstrate how our contribution to usable design increases user productivity and lowers cost.

As part of her illustration, she showed a chart about the more and more expensive it gets to fix a bug from the requirements stage through to the maintenance stage.

An idea came to mind, and I shared it with the team, that one of the things that we can use some hard numbers with is determining how many steps it takes to complete a task. The presenter had used an example to show how a process that she would have expected to take four steps instead took twelve. If we can analyze designs and determine how many steps it takes to complete associated tasks, we can tell the project team, “That’s going to be hard to explain. That process will take ten steps (or fourteen, or twenty). And when a user sees a procedure with that many steps, the first thought is ‘This is going to be hard,’ probably followed up with ‘I hope I do it right.’ Confidence goes into a nosedive.”

The second part of the idea is that to give ourselves more clout, we ought to get the project manager’s support at the beginning. We can explain how expensive it gets to fix usability problems later and how we can help catch those problems early on because we think in terms of “how do I do this?” By virtue of our job, we quickly learn how complicated a task is going to be. Once we get the manager’s buy-in, he or she can back us up if the team hedges when we point out that a design involves overly complicated steps.

Metrics are a tech writer holy grail. How do we show return on investment? How do we show that we reduce support costs that would otherwise outweigh the money our services cost—especially when we’re working on a new project that has no support history? In the case of usability, how do we numerically increase the usability of the product?

So procedure length is one way to quantify the usability of a feature or product. What other ways can we quantify our contribution to usability?

Image credit: Image: Master isolated images / FreeDigitalPhotos.net

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Why a Transition from Tech Comm to Usability Makes Sense
2. Where Usability and Documentation Meet
3. Documentation Needs Usability Testing, Too
4. Usability and Maintainability: Instructions They Can Follow
5. Why Writers Should Be Involved Throughout the Project Lifecycle

Over the last few months, the User Education Team has developed a content model and a supporting style guide. Our evaluation of various documentation authoring tools a few months ago resulted in our choosing Author-it—a tool none of us was familiar with.

In our discussions about our content model, or how our information is structured, sometimes we kept drifting into talking about what Author-it would allow us to do. It was an easy line to cross. The way you approach reuse and other considerations can change based on what tool you use.

But overall, the optimal way to structure information isn’t dependent on a tool. That’s probably why our team lead kept steering us away from thinking about whether aspects of our authoring approach and information architecture would be supported in Author-it. There were parts of our discussions that blurred the lines—we would sound like we were talking about the tool, but we really weren’t.

Such discussions highlight what I’ll refer to as the core component of technical communication.

That component is the heart of the term technical communication—that is, communication.

The secondary part of that term, technical, refers to the subject matter we are communicating about. But it could also refer to the method we choose to author, organize, and deliver the content, which these days rests in technology.

Technology changes. Communication channels and content delivery mechanisms change. We have Author-it today, but something more fitting for our organization and our needs may come along in a few years. DITA has spread through much of the tech comm space, but who’s to say something more effective won’t come along in the future, or that DITA won’t evolve (see what I did there) into something better?

Yes, the technology changes, but the core principles of communication don’t.

Varying definitions of communication exist. Some say that a message has to only be released from its source to be communication. Others say it has to be understood. I’m more in the second camp, and I would add that the message needs to be understood the way the originator intends. Otherwise, have you really gotten the message across? Has communication really occurred?

That’s why I’m not talking about “good communication.” It’s communication, period. Or it’s gobbledygook that doesn’t do the job.

I admit that the recipient of the message has to put at least a little effort into understanding the message. Those mental gears have to turn a notch. But communicators can make that effort as small as possible by doing what we do best: communicating.

What makes communication happen?

• Clarity. The message is free—or as free as possible—from interference caused by indirectness and jargon. It’s phrased in simple terms.
• Timeliness. The message comes when it’s appropriate. The recipient can make use of the information right then.
• Relatability. I could also call this “connectability.” The recipient can connect the information to what’s already in his head. He can relate it with his prior experience.

It doesn’t matter what tool you get excited about; in the end, it’s just that. A tool. It’s a means by which to get a job done. My audience probably doesn’t care about my tool. In the end, what they care about is the clarity, timeliness, and relatability of my message. They care about accomplishing their goals.

Image credit: renjith krishnan | FreeDigitalPhotos.net

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Test Cases: More Like Technical Communication Than You Thought
2. The Importance of Communication Skills over Technical Skills
3. Could Technical Communication Be Entertaining?
4. Technical Communication: The QA of Product Design
5. Technical Communication Can Require Heavy Duty Hardware

Many times when I think of surveys, I think of the Animaniacs cartoon with the ladies who asked the three Warner siblings, “Would you like to take a survey?” There followed many questions with every imaginable permutation based around George Wendt, movies, and bean-eating.

Recently I conducted an online survey on the training and help materials for System X, a Web-based app for office staff. I didn’t ask a single question about George Wendt or beans. My two main goals were:

1. Find out how good the training was that the respondents received in person
2. Learn how much the respondents use the training and help materials in the application and how effective the materials are

Basic Results

I ended up with sixteen questions, some of which were demographic. According to Qualtrics (the software I used), 497 people accessed the survey, and 420 people completed it. However, I found as I analyzed the results that some respondents skipped questions and didn’t really fill it out completely. Still, about 230 out of 340 worldwide offices were represented in the result set, and I’m happy with the relatively high response rate.

As a bit of background, we have an online help system and a training page for this app. The training page has links to role-based quick reference guides in PDF and video demos in Flash. The help is your typical old-school tripane WebHelp with index, search, and so on.

Here are some key findings (numbers taken from those who responded, not the overall 497 or 420):

• 42.7% were not aware of the quick reference guides
• 28.3% were aware of QRGs but never use them
• About 25% have used QRGs at least once
• Average effectiveness rating out of 1 to 7 is 4.11 (so just above moderate)
• About 85% print QRGs when they use them

• 48.7% weren’t aware of the video demos
• 29% were aware of the videos but never use them
• 21.6% have used at least one video at least once
• Average effectiveness rating of 4.61

• 20.6% were not aware of help
• 39.2% were aware of it but never use it
• 39% have used the help at least once
• Average effectiveness rating of 4.01

In trying to avoid a long survey, I didn’t ask reasons of those who were aware of the materials but didn’t use them, though that would have been informative.

One of the demographic questions was whether the respondent was age 30 and up or under 30. This was to help us see generational patterns. I may post some of those differences later.

The Awareness Deficiency

A glaring problem is the “awareness deficiency,” as I like to call it. It was a bit shocking. A number of free-form comments confirmed the fact that people would have been more likely to use the materials if they knew about them. We have the classic Help link in the application header, but the link to the training page is on a different part of the home page. Its placement with links to external sites and apps is probably the cause of this downfall, since people may have overlooked the training page link thinking it led to something outside the app.

The numbers of those who have used the materials were higher than I expected, but they were somewhat encouraging. It illustrates that by providing multiple types of help and training, you may be reaching a large portion of your audience. If those who skipped the usage questions had answered them, and if those who were unaware had been aware, the usage numbers likely would have come out higher.

Wrap-Up

The respondents’ comments left me with a long list of things to improve. We have a reskin of the app planned, as well as a move to a different platform for help and training, which I’m looking forward to. But I have a lot of work to do to make the training and help more than just above mediocre.

If you think you can get a lot of responses and target your questions well, such a survey is a highly beneficial tool to identifying your audience and learning what you can improve about your documentation.

Image credit: 89studio, FreeDigitalPhotos.net

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Quick Reference, Videos, and FAQ in Front; Help in the Back
2. Follow-up: A Skill for the Extroverted Technical Communicator

The objective for our style guide is to highlight the most important considerations so they’re together in the same place. That way, when we have a new member of our team or another contributor, it’s not a huge chore to review the team style guide and get up to speed.

It was with this in the back of my mind that I went to the Society for Technical Communication’s (STC) yearly conference a couple of weeks ago. I attended some sessions that had to do with writing for localization and for accessibility. In her presentation, “DUH: Diverse. Understandable. Human,” Char James-Tanny talked about inclusion being a better word than accessibility. Her presentation came close to what I had begun thinking about.

I was thinking that we often compartmentalize our writing. One person tells us we have to write to be accessible. Someone else says to write for easy translation. A third says to write for search-engine optimization. There are probably others.

Can’t we do all of them at the same time?

Of course, the answer is yes.

In attending these sessions and thinking further on it, I realized that a writer can meet these various needs through following certain guidelines and styles. I’m compiling a list that will inform the style guide, and I’m thinking about proposing a presentation at next year’s STC conference on the subject.

What are your thoughts? What other audiences or types of writing get compartmentalized like accessibility and easy localization do?

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Anyone Can Write?
2. Is Better Translation on the Horizon?
3. 56th STC Summit Gets Some Concrete Results
4. Write Self-Contained Titles to Preserve Context
5. Clear, Common Language Leads to User Success

Sometimes I get ideas about a problem I’m trying to solve once I’ve stopped actively thinking about it and have let it drift into the back of my mind. With Project Pinnacle, something escaped my attention until a few weeks after my visit to the pilot site.

Well, it didn’t entirely escape my notice, but its implications for documentation and training didn’t hit me immediately.

The thing I noticed while watching users try out my quick reference guides was that they tended to follow only the first few steps of the procedure. They would look at it long enough to get to the screen where they performed the task, and then they would try to do the rest without the guides.

One of the reasons for this is that they had to keep glancing between the monitor and the paper, which made it easy to lose their place. Trying to use a finger didn’t help much either because at some point they had to start typing.

A few weeks after my visit, I got an idea of maybe a true quick reference guide that would fit what they needed. Since they relied on the printed procedures only for navigation, why not just provide the navigation steps?

I put together a version of each guide that listed the steps with double angle brackets between each step. This condensed the existing material from about four pages for each guide down to under one page. I haven’t tried these versions out yet. The project manager wasn’t in favor of the version of the guides that have the screenshots with callouts because of the cost of keeping the screenshots current for all languages.

When I first reported to the project leadership about my visit to the pilot site, I pointed out that a way to improve our training of our audience and at the same time reduce documentation costs would be to provide more prompts in the application. I’m not trying to reduce my workload, but I believe that the more help you provide in the interface, the less help you have to maintain elsewhere. I know, not real profound, but it’s not something very many product designers think about.

Since then, I’ve provided prompts and descriptions for a number of application screens and features. We’ve seen a direct impact of this as we’ve worked on the training video scripts. We want to keep the verbal explanations simple and let the features be demonstrated so that we don’t have to rerecord the audio if features change. The fact that we’re including help in the interface helps us do this because we can leave much of the explanation to the application itself.

Image credit: Salvatore Vuono, freedigitalphotos.net

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Project Pinnacle, Episode 3: The Pilot
2. Project Pinnacle, Episode 2: Drafting Quick Reference Guides
3. Project Pinnacle, Episode 1: Conversation with the Project Manager
4. Spending Time with Users to Learn How They Want Assistance
5. Your Users Don't Do What You Expect

The office staff tended to want to ask me how to do things and be walked through it, but I took those times to ask them to test out the instructions for me. However, on one occasion, I had to guide a brand-new user through a somewhat complicated scheduling procedure while she was on the phone with the person setting up the appointment. I figured it would be better to help her through that one because she’d feel enough pressure from trying to do it right and in a timely manner.

In addition to notes on improvements to make to the guides, I kept other notes. The rundown:

• 5 tasks to add to the guides
• 14 other changes needed to the guides
• 20 feature or change requests
• 10 bugs
• 14 miscellaneous items that were questions, observations, or usability problems

Changes I found I needed to make to the guides:

• Add sidebar for table of contents
• Add several tasks, some applicable across guides
• Change how I give an orientation to system navigation
• Add tips on effective searching
• Change heading styles to stand out more
• Make guide for each role visually different somehow
• Reference material for how different scheduling works for different types of activities

One problem I saw is that users would lose their places when going from a guide to the screen and back because they need both hands to type, so they couldn’t keep their place with a finger on the page. They’d go back to the guide and resume at a random step.

I asked my colleague Tom if he has any techniques for mitigating this problem. We talked about having a two-column layout for the guides with the text on one side and images on the other that have annotations or callouts that tie back to the instructions.

That sounded like a good idea and implementation of the quick reference concept. I had gone pretty minimalistic with the guides, having some orientation material on general application usage, and then the tasks with few images.

Today I tried restructuring one of the guides, and it turned out basically like the image here—instructions, a sidebar with ancillary information, and a screenshot. I have few actual callouts so far. At this point, I’ve mostly indicated only what part of the page each step applies to.

One benefit of this approach is that the steps are quick, and the image also illustrates the steps in a brief way. So a new person could use both, but a more experienced person could choose one or the other. The tricky part will be making it all lay out well and accommodate translations. It will be interesting to test out this approach if I get the chance.

A great result from having participated in the pilot is that the project manager invited me to a brainstorming meeting next week that I believe has to do with design decisions. The product manager called me earlier this week to talk about my visit to the pilot site, and he asked me to prepare any design suggestions regarding the usability problems I saw. It makes the project more interesting for me to participate and contribute beyond just writing end user instructions.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Project Pinnacle, Episode 2: Drafting Quick Reference Guides
2. Project Pinnacle, Episode 1: Conversation with the Project Manager
3. Try a Quick Reference Guide for Short-Term Documentation Needs
4. Quick Reference Guide Q&A
5. Spending Time with Users to Learn How They Want Assistance

In light of our team’s search for the tool that best meets a set of specific requirements, I’ve decided that Redish’s book has everything to do with what I do—or what I should be doing.

My Beef with Tri-pane Help

If you’ve been reading this blog for a while, it’s no secret to you that I’m not a big fan of tri-pane help. I think it’s dated and is associated in people’s minds with unhelpfulness.

But in our search for a tool that will give us a more robust Web output, I’ve discovered the main reason I don’t like tri-pane help.

Tri-pane help appears to have been invented as a way to provide booklike documentation—that is to say, linear documentation. The table of contents, index, glossary are all carry-overs from when all documentation was in hard-copy manuals. While a book’s material isn’t necessarily linear, it still reflects linear thinking.

The Web Offers More

Ginny Redish’s book argues that because the Web is a different medium and holds different possibilities, we shouldn’t hold ourselves to organizing Web content in the same way we organize book content.

Tri-pane help is a pseudo-website; it has a header or toolbar of some kind and a left pane for left-hand navigation. Help authoring tools make it easy to assemble tables of contents, indexes, and glossaries, but they’re only making it easy to perpetuate the linear thinking of books and to not take advantage of what current Web technology has to offer.

Letting Go of the Words talks about performing audience research and then setting up the home page, pathway pages, and information pages in a targeted way. Navigation deliberately and clearly guides users from start to finish, each page and link letting them know they’re on the right track.

You don’t have to set up a help system’s TOC just like you would a book’s. You could organize it in some other way than introduction, chapters, appendix, and so on. But how often do we take the time to do the kind of research we need to in order to make a table of contents even partially effective?

One of the limitations of a TOC is that you can display only topic titles. If you set up pathway pages like Redish describes, you can give the reader more guidance. A risk you take with TOCs is that as the user doesn’t find what he wants, he expands more and more books or folders, and he ends up with an overwhelming list of topics. Instead of holding his hand and leading him along, you’ve paralyzed and frustrated him.

In my experience, help authoring tools don’t lend themselves to dynamic Web outputs that allow you set up this kind of guided experience. You could do it, but it’s not supported well out of the box.

What about Search?

I was talking with my team lead a few days ago about this. He brought up search. Tri-pane help offers search, so how is a website like I’m describing any better?

I’ve got a few responses to this.

• Not everyone searches. Many people do follow links in menus.
• Multiple pathways increase the likelihood that people will find what they want.
• The search function in tri-pane help usually stinks.

I’m a fan of search. If search is well done, it can quickly take users to what they want. If that’s the route they choose. But it shouldn’t be the only way to look, or else we run the risk of the answer to the user’s question being too far down the results list to be found.

Wrap-Up

I think creating tri-pane help tends to lull technical writers into going through the motions. “Okay, I’ve got search, a table of contents with all my topics listed and organized, and as many index keywords as I could come up with. My help is helpful.” We sometimes fool ourselves into thinking that because these boxes are checked, we’ve done a good job at providing quality content and structure.

It would be better for help authoring tools to provide more flexibility so we’re forced to put in the research and thought required for useful content and architecture.

My hope is that in our search for the optimal tool, we find one that doesn’t force into creating tri-pane help and instead allows more flexibility and visual appeal.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. RoboHelp Packager for AIR Critique, Part 2
2. Help Authoring Woes: Index As You Go
3. Time for Online Help to Get a New Wardrobe
4. Could Technical Communication Be Entertaining?
5. Anticipatory Search in Context-Sensitive Help

I ended up with about five weeks to complete these guides in the midst of other projects. After a demo of the application given by the lead tester, I sent the manager an outline of each guide. He didn’t get back to me right away, so I started writing the guides while using a test version of the application.

The guides’ structure was pretty simple. On the first page, I included a screenshot with callouts that explain the navigation structure of the application: header, subheader, tabs, links, buttons, and so on. The hope is that this would reduce the amount of instructions needed by covering the basics together. After basic navigation, I covered the main tasks for the role in question.

Three weeks ago, I attended a video conference with the project manager, interaction designer, and product manager. I gave a status report on the documentation, and the project manager gave approval on the outlines I had provided. We talked about the product pilot, to which the project manager had invited me when we first talked. The others decided that the best approach would be for me to attend on two different days than the product manager and interaction designer, part of the reason being that three of us being there at the same time could cause a disruption to the office work.

The product manager and project manager thought that it would be sufficient to have drafts of the documentation ready for the pilot rather than something that we expected to be polished. I liked that idea because it meant less pressure to get it right on the first try—before I really had a chance to talk to any users. Since the users during the pilot will understand that we’re gathering feedback on the product, it won’t be a big jump in logic for them to remember that the documentation is also being tried out.

One of the other benefits of including draft documentation in the pilot is that you leave room for frequently asked questions. It’s pretty obvious to me when a product’s FAQ looks canned and not representative of people’s real questions. Going onsite and listening to users’ questions, keeping a list, and then choosing the most asked ones is one way to get real frequently asked questions. (Another is to tally the questions that come through some other feedback mechanisms.)

In this video conference, the product manager asked to review the guides. So with about a week to spare, I sent the drafts to him. I’ve just received his feedback, so it won’t be reflected in what the users see during the pilot. But hey, they’re drafts, and it’s a pilot, right? Overall, he thought the guides were good, so I think I’m on the right track.

It will be interesting to see what the office workers think, though. They may have very different feedback. I’ve found in documentation usability testing before that it’s noticeable when people get stuck while following instructions.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Project Pinnacle, Episode 1: Conversation with the Project Manager
2. Quick-Start Guides Require a Minimalist Mindset
3. Quick Reference Guide Q&A
4. Try a Quick Reference Guide for Short-Term Documentation Needs
5. Quick Reference, Videos, and FAQ in Front; Help in the Back