I'd Rather Be Writing » STC Summit

15 Tips for a Successful Conference Experience

Tom Johnson — Fri, 18 May 2012 14:56:11 +0000

Tips for a successful conference experience

The STC Summit takes place in a few days. If you monitor the #stc12 twitter stream, you can feel the excitement of the conference attendees. I’ve been to at least a dozen conferences over the last seven years or so, and I’ve accumulated a few tips that have helped make my conference experience better. Here are my top 15 tips for a successful conference experience.

1. If you want to sightsee, arrive early.

Usually once the conference begins, you won’t have time to see all the noteworthy places in the city, so if you do want to sightsee, arrive a day early. Conference sessions take place during the day, and in the evenings most of the tourist sites are closed.

2. Get lost in the city, since you have GPS on your phone.

When you do venture into the city, feel free to get lost, always knowing that you have GPS on your phone and can navigate yourself anywhere you need to — at least until your battery runs out. Yelp and other “what’s nearby” apps will help you find stores and places wherever you are.

3. Wear running shoes.

People do a lot of walking at conferences, and it always surprises me to see women wearing high-heel shoes, or men wearing dress shoes. Take along your favorite pair of running shoes or some other comfortable shoes. Not only will you walk all over a conference center, you’ll also walk around the city. Feeling comfortable can put your weary traveler’s body at ease.

4. Put a QR code on your business card or badge.

I’ve never done this, but I would like to. A QR code (like the one on my About page), can provide contact details and other information on someone’s phone when they scan it with a QR reader. Business cards shuffled around typically get lost. If you make it into someone’s mobile phone, however, you have a chance of being remembered.

5. Go with a problem you’re trying to solve.

Write down several problems you’re trying to solve before you get to the conference. This will give you purpose. If you do nothing else, follow this tip. When you browse the vendors, interact with other attendees, and listen to the sessions, keep your problems/questions in mind. They will ground your conference experience with a purpose. This purpose will help your interactions with others be much more meaningful.

6. Pick sessions based on speaker profiles.

Popular, well-known speakers are popular for a reason — they’re usually pretty entertaining. Even if the subject doesn’t entirely align with your interests, a good speaker can make any topic interesting. Unless a session has a specific appeal to you based on the topic, attend the sessions with the most well-known speakers. This rarely leads to a disappointing experience.

7. When it doubt, pick the session in the biggest room.

If all sessions seem equally dull, pick the session taking place in the biggest room. Conference organizers know which sessions will be the most popular, and they allocate room sizes accordingly.

8. Listen for the non-session insights.

Although you may think the sessions themselves will provide the learning during the conference, the more significant learning takes places in more subtle ways. Listen for the non-session insights, the ideas that randomly pop into your head. These insights may arrive during a session (even when the session is about a different topic), during session breaks, at lunch, in your hotel, etc. Be on the lookout for them and recognize that these non-session insights are probably your greatest learning value.

9. Monitor and use the conference hashtag.

If you’re new to Twitter, make sure you know the hashtag others are using during the conference (for example, #stc12). Use Twitterific or some other app to monitor tweets. You can also add a keyword to the hashtag, such as “#stc12 dinner” and filter tweets that way. In your tweets, rather than parroting speakers or always expressing praise, try to communicate insights, comments, or opinions.

10. Publish your notes as blog posts.

When you return to your office, your colleagues will want to know what you’ve learned. The notes you took during sessions will quickly fade. Try publishing your notes as blog posts. Taking notes will keep you more alert during sessions, and you can refer to your posts when others ask questions. Although most people take notes during sessions, few publish them as blog posts. When you do publish your notes as posts, no doubt you will reflect and evaluate what you’re learning in a more critical way. This reflective element is yet another aspect of learning.

11. Ask questions even if you feel uncomfortable asking them.

Undoubtedly you’ll be in one or more bad sessions during the conference, kicking yourself that you decided to attend that session. The speaker drones on, teaching the PowerPoint more than the audience, going in directions that bore you, and generally giving a poor presentation. When this happens, it’s likely that 75% of the other attendees are feeling the same way.

You can change the flow of a bad presentation by asking a question, even if it goes in a slightly different direction than the speaker’s slides. Remember my recommendation above — to go to conferences with a problem to solve? Now is the time to unpack that question and salvage your session time.

12. Learn the art of starting a conversation.

Meeting other people is part of the conference experience, but many of us are shy introverts. Here are a few simple questions you can use to immediately start any conversation:

What did you think of that session?
Where are you from?
What do you think of the conference so far?
What session are you planning to attend next?
What do you do at your company? (Refer to their nametag.)

These ice-breaker questions get somewhat trite after a while, but they begin any conversation. After breaking the ice, move into the questions you really want answers about (as explained in the “Go with a problem you’re trying to solve” section).

13. Learn the art of ending a conversation.

When you’re trapped in a conversation that you can’t escape (for example, at a tweetup or other networking activity), there are several ways to get out of the conversation. Try these escape clauses. Begin, “Well, it was nice meeting you,” followed by –

I think I’m going to mingle around to the rest of the place.
Do you have a business card?
I’m going to get some more food.
I think I recognize someone over there that I want to say hello to.

If none of these work, just stop talking. The other person will probably terminate the conversation for you.

14. Learn euphemisms to describe less-than-satisfying sessions.

When you attend a session that sucks, rather than saying it sucks, or coming across as a sour grape, try describing the session in a more euphemistic way:

The speaker seemed really nice, but the session wasn’t my favorite.
I’m interested in the topic, but I didn’t take many notes in the session.
I think the speaker was a little tired.
The session wasn’t what I was expecting.

15. Bring back toys for your kids.

While you’ve been at the conference, your patient spouse and kids have been feeling what it’s like to live without you. It’s nice to bring back some presents to show you thought of them while you were gone. If you have little children, stop into a toy store and pick up some simple gifts, such as toy cars, bracelets, books, dolls, or other items. The gifts don’t need to reflect the city of the conference. Simply bringing something back is usually enough to get the message across, which is Hey, I thought of you while I was gone.

Those are my tips for a successful conference. If you have any tips to add, or feedback about the above, please let me know in the comments.

Blog Sponsors

Conferences I’m Attending This Year

Tom Johnson — Tue, 28 Feb 2012 14:55:52 +0000

I’m attending three conferences this year: Confab, the STC Summit, and Lavacon. Why did I pick these conferences, over others?

Ben Minson and me at a previous STC Summit

I attended Confab’s inaugural conference last year and felt it was a good fit for my web publishing role at work. Although my job title is “senior technical writer,” I spend about 60% of my time being a web editor for LDSTech. LDSTech has a blog, wiki, and forum, and in many ways, it’s the communication/awareness arm for our IT group.

Confab is a perfect conference for anyone involved in web publishing. I’m still wrapping my head around content strategy. Last year I learned that it means a lot of different things to different people. Mainly, whatever techniques you employ to give your content an edge is a content strategy. More than anything, Confab seemed like a web publishing / marketing / content strategy conference. Only a few technical writers were there last year, and you probably know them all (Scott Abel, Rahel Bailie, Ann Rockley, and a couple of others). Yes, only about five technical writers out of hundreds of attendees). Just like 2011, the Confab conference sold out early again this year. (I don’t pretend to understand conference dynamics, but their staff seems to openly defy the law of supply and demand.)

When I’m not being a web editor, I write help material. Most of the applications I document are small in scope. I never document anything that has 1,000 topics or more. I remember once talking to Joe Gollner at a conference. He works on projects that have hundreds of thousands, perhaps even millions, of topics. I can’t imagine documenting anything so vast. I guess this means I’ve become more of a technical writer involved in lightweight projects. That suits me fine, though.

I initially wasn’t going to attend the STC Summit this year. I submitted a proposal, but then changed my mind about the conference and withdrew my proposal. Because I helped review proposals for one of the tracks, I received a discount on registration. Despite canceling, I still had a nagging desire to attend the summit. Not so much for the education sessions, but because it’s a conference that all my professional friends attend. It’s the epitome of #techcomm. Some training budget funds opened up last week, and I managed to squeeze it in.

I’m not staying at the $200-a-night conference hotel, though, especially when that price doesn’t even include Internet. The point in attending a conference or visiting any city isn’t to abscond oneself in the hotel watching cable and lying on luxury pillows. The point is to get out and interact. I love walking around the city, exploring new places. I enjoy getting out of the hotel perimeter, past the point where every store caters to out-of-towners at hotel prices. Also, my travel budget isn’t so vast that I can afford to stay in fancy hotels and attend multiple conferences a year.

The trouble with attending Confab and the STC Summit is that they take place two weekends in a row. This only goes to show that the Confab conference planners aren’t targeting technical communicators, or that too many competing disciplines have conferences in the same short period of time.

The final conference I’m attending this year is Lavacon. I’ve never been to Lavacon, though I’ve helped out with the website for it. Jack Molisani asked if I’d like to present, and I got to thinking how nice it is to get out of the office in the fall, outside of the regular conference season. And yes, I do have a topic percolating that I’d like to present about: crowdsourcing writing tasks. The Portland venue makes the conference even more appealing, since I’m a northwesterner myself, born in Washington State.

Apart from these random details about conferences, have you ever wondered about the deeper reasons why we go to conferences? What draws us to attend? Perhaps it’s because conferences hold the promise of an idea. Put together hundreds of professionals from the same discipline in a room, and all kinds of innovation should take place. Why doesn’t more innovative thinking happen? Are we stifled by hearing the same voices again and again in presentations? Are we distracted more by the schedule than by the point of the gathering? Do we not attend with enough questions and problems to solve?

Last year my former colleague Derek came back from WritersUA and said the conference consisted of many excellent presentations and information. Like what, we asked? Tell us what you learned. Unfortunately the details of that conversation never materialized in much depth, which makes me think that the takeaways from conferences might not be any notes you write down from presentations, nor the people you meet during all the “networking opportunities,” but rather an igniting of thought about your discipline and how to move forward in your professional endeavors. Derek returned more determined than ever to implement an enterprise-wide authoring strategy.

Although I’m not presenting much this year, I do lean towards a preparation model that may not be entirely sound. Whereas most conferences invite speakers who are recognized experts on topics they’re familiar with, I think you should submit a proposal based on a topic you want to explore for the year. Then present your findings about your exploration at the conference. The conference acts as the culmination of months of research, experimentation, and thought about the topic.

I did that last year with the topic of findability at the Summit. Knowing I would be presenting on the topic motivated me to keep it foremost on my radar, and I explored the heck out of it, writing more than 40 posts on findability. But because of the difficulty of the topic, I never reached the triumphant conclusion that would lead to a knockout presentation. And not having that triumph in hand led to enormous stress as the date of the conference approached. Good stress, but perhaps more than I care to repeat.

This year, with just one topic on the agenda — crowdsourcing writing — I am taking it a bit easier. I’m not a total expert on this topic, but I’ve been wrestling with it for the past 8 months now. I’ve made more progress than many, and I know how to do it, just not how to pull it off on a grander scale.

I look forward to interacting with you at some upcoming conferences. Is there a conference I’m missing out on? I’d love to hear about it. More than interacting, though, I’d love to learn what unspoken takeaways you get from attending conferences.

Blog Sponsors

Presentations Versus Conversations

Tom Johnson — Fri, 17 Jun 2011 14:34:40 +0000

Recently I listened to Moira Gunn interview Steve Rosenbaum about content curation in her podcast, Tech Nation. I heard Steve present on a similar topic at Confab. Interestingly, I found the podcast, which was a conversation between Moira and Steve, more interesting, fluid, and natural than Steve’s Confab presentation.

Steve’s presentation at Confab was great. But all presentations, by nature, have a different rhythm and organization than conversations. In a presentation, you usually have a deck of slides that you move through sequentially, following a predefined structure to your ideas.

In contrast, conversations are more spontaneous. At times you may pursue tangents, or skip around to topics that you might have originally thought to delay until later. Order is decided at the moment, based on the interviewer’s questions, his or her responses, and the level of perceived interest. Overall, I think conversations allow for more discovery and excitement based on the unplanned direction of the conversation.

In addition to presentation and conversation formats, other formats blend the two. Last Friday I participated in a MindTouch webinar that was a hybrid between a presentation and a conversation. Scott Abel is the host of a series of webinars by MindTouch. Before the webinar, he asked me to send him a slidedeck of my presentation. He then selected out the slides he wanted to discuss, and modified them a bit. He also inserted some of his own slides. About 15 minutes before the webinar, he sent me a PDF of the slides, but I hardly glanced at half of them before the webinar began.

During the webinar, we moved through the topic in a conversational way. Scott used the slides to move the conversation forward when it lagged. Sometimes this worked well, as the next slide provided a great segue to explore a new angle on the topic. Other times I realized that I already discussed the information on the next slide, or the slide took us backwards instead of forwards in the conversation. Regardless, the slides gave a sense of structure to what might otherwise be a loosely focused conversation touching a lot of different points somewhat randomly.

Regardless, I admit I prefer conversations more than presentations. Many presentations, particularly at conferences, can often lack engagement. In contrast, the conversation format puts the listener as a player in the topic game. You have some control about the direction and momentum, rather than just being a spectator.

At South by Southwest Interactive (SXSW), a lot of times the formats are panel discussions. A presenter may give a 20 minute presentation followed by 30 minutes of question and answers. I haven’t been to SXSW, but in listening to the recordings, these sessions are appealing hybrids of conversation presentations.

Preparing for a conversation to take place during a presentation is a somewhat risky move for a presenter. At the STC Summit, I presented for 30 minutes, and then opened up a question and answer session. It went all right, but the Q&A component was multi-directional, since it’s a conversation with a crowd rather than an individual.

The crowd conversation doesn’t work as well as a one-on-one conversation because the crowd’s questions are much more random. The questions don’t have the same focus and flow as the questions that a skilled interviewer might follow. A skilled interviewer will pick up with your response and build on that response with a new question. The conversation has a direction it’s heading, even if neither person knows exactly where it will end up. In contrast, the crowd Q&A is a start and stop motion, with no sense of forward momentum or progress building on the responses.

Having a conversation in front of an audience is another approach, somewhat like listening to a live podcast. The limitation here is that the interviewer’s questions may not represent the crowd’s questions.

Overall, what’s the best format for delivering information to a group? A conversation, a presentation, or a hybrid of the two? I’m not sure. Conference season has ended, so I don’t have any upcoming presentations I’m planning. But when I need to give another presentation, I think I’ll move toward a short presentation followed by a conversation. The job of the presentation should set up the fuel and momentum of the conversation. The presentation should naturally start the conversation.

I doubt this format will catch on for most conferences, though. It requires too much on-the-spot performance and risk. It’s much easier to bank on your own presentation content, load up your PowerPoint with 50+ slides, and sail your way across the harbor — even if your audience remains on the shore.

Blog Sponsors

Diverging Directions for Tech Comm: Social Media or Structured Authoring

Tom Johnson — Thu, 09 Jun 2011 06:35:14 +0000

Two powerful trends in tech comm seem to be moving in different directions: social media and structured authoring.

I have used a wiki as my primary format for documentation for the past year and a half. I tried to corral a group of volunteer technical writers to edit and update the wiki, because I embraced the idea that collective intelligence beats the individual thinker in the long run. But even the most advanced wikis don’t have a structured authoring backend. With wikis, you compromise single sourcing, content re-use, and multi-channel publishing. So you really can’t move in both directions well. I feel like I’ve had to choose whether I’ll pursue structured authoring or social media formats for my help content.

While at the STC Summit, I kept thinking about metadata and the idea of sorting content semantically by queries that leverage the metadata. I asked more than a dozen of the smartest people in tech comm about this, and I came to the conclusion that if I ever wanted to do it, I’d need to embrace an XML format and develop custom semantic tags.

One evening I had a dinner conversation with Sarah O’Keefe about moving to XML. Sarah explained different ways to write XML and how to query the XML even when it’s not structured as it should be. She grabbed a napkin and drew the following:

The code Sarah drew for me on a napkin.

Yes, I kept this napkin! It was the best souvenir from the STC Summit. It’s funny because when she asked for an example of one of the metadata values and properties I wanted to use, I said role as the value, with editor as the property. But I must have mumbled it, because she wrote “elder” as the property instead.

After the conference ended and I returned to work, I decided to abandon my wiki and move all my content into our Mark Logic database, which stores content in XML. This is LDS.org’s backend anyway. To do this, I would need to convert all my wiki topics into XML and add the appropriate metadata to run all the custom queries and provide the faceted filtering I wanted.

I spent several weeks coming up with the right metadata and applying it to all my topics. I was basically saying goodbye to Mediawiki and the idea of collaboration. I would structure my content in XML, and I would be the sole author. Not that many community volunteers edited the wiki anyway, but there was always the possibility that some day it might take off. Still, I had given the wiki almost 2 years without seeing fruit. It was time to try something else.

When it finally came down to the time when I needed to convert my content, I learned that the web development team had created special help templates for me. These templates included a WYSIWYG editor where I would basically create pages. Further, I wouldn’t even be the one converting the content. A special web development team would handle it all, populating the templates and creating pages, and even if I wanted to touch the content I could not. They planned to pull it directly from the wiki.

What about all of those metadata fields that I had labored over? I had to pitch the whole idea about semantic structure and findability again. In the end, they penciled in a future task in a later sprint to expose certain metadata fields in the templates for the web publishing team to use. The custom queries will be a future request, once my content is in XML.

I thought I would be swimming in XML and coding until my eyes turned blue, but it turns out that this approach is even less techie than the wiki. For the time being, I relinquished my publishing control.

I’m eager to see if the new format yields higher visibility and findability for the help. It probably won’t be until the end of summer when I can evaluate whether the migration from wiki to XML was a good idea.

In the meantime, I have not altogether abandoned the idea of collaboration. I’m a project lead for a community LDSTech project that is more community-sourced than my wiki ever was. I have more than a handful of writers creating and submitting articles.

But hoping someone will land on a help page, realize its a wiki, log in and make intelligent updates is a dream that only few groups have ever achieved (most visibly, Wikipedia). The promises and potential of structured authoring, with faceted filtering, semantic structures, and intelligent queries, seems to outweigh the attempt to collaborate efforts across large groups using wikis.

Blog Sponsors

Podcast: Organizing Help Content: Breaking Out of Topic-based Hierarchies

Tom Johnson — Wed, 18 May 2011 22:59:33 +0000

The recording is available in a variety of formats:

I recently gave a presentation at the STC Summit in Sacramento titled “Organizing Help Content: Breaking Out of Topic-based Hierarchies.” I would have recorded my presentation, but recording is not allowed. I did, however, record a practice run-through in my hotel room the morning before.

I included a variety of links here. If you want to view slides while listening, click the Audio with Slides option.

Comparing the practice presentation to the real presentation, the practice presentation ended up being about 15 minutes longer. This means I had more time for questions and discussion during the real presentation. Some participants gave me great feedback in the discussion and follow-up afterwards. This presentation is only one part of an ongoing journey in my effort to solve the findability problem with help content.

Blog Sponsors

WordPress Workshop Outline for the STC Summit

Tom Johnson — Sun, 15 May 2011 06:55:22 +0000

Tomorrow I’m giving a four hour workshop on blogging and WordPress at the STC Summit in Sacramento. I thought I’d post my outline in case anyone is interested in how I approach these workshops.

In preparing this outline, I realized that my focus on WordPress and blogging has shifted more towards producing content rather than manipulating the technology. Several years ago, you had to be more techie to make adjustments to your theme and get plugins to work. Now, the technology has matured to the point where you really don’t have to dive into code. You can just focus on content. However, it has now become more difficult to create content that stands out from other blogs, since new blog posts saturate the world on a daily basis.

WordPress Workshop Outline

1: The Intrigue – Should I start a blog?

Reasons for starting a blog
What you can expect in return
Realistic time commitments
Why blogging is a perfect opportunity for writers

Practice: Share your intrigue with blogging and evaluate your expectations.

2: Setting up the Scene – How do I get set up?

Choosing a web host
Installing WordPress
Configuring basic settings
Adding sidebar widgets

Practice: Set up several WordPress sites. Add various widgets to your sidebar.

3: The Initial Euphoria of Posting – You mean I can post anything about anyone at anytime?

Selecting a focus
Branding the focus on the blog
Publishing a post
Editing the post

Practice: Find the About page on a popular blog and evaluate it. Publish a test post.

4: Getting Trendy with Design – How do I make my blog look cool/professional?

Introduction to themes
Finding good themes
Themes with elaborate backend interfaces
Making manual adjustments to themes

Practice: Install a new theme. Adjust some aspects of the theme.

5: Writing for the web – Why aren’t people reading my long posts?

Structuring content for online reading
Creating links
Linking to other posts
Search-engine-optimizing your content

Practice: Create a link to another post with specific anchor text.

6: Comments! – Why am I getting spam?

What to do when no one comments
Dealing with spam
Activating Spam filters
Responding to comments
Implementing threaded comments
Responding to mean comments

Practice: Install and activate antispambee. Evaluate comments to identify spam.

7: Making it easy to subscribe – How can I get a thousands of readers/followers?

Measuring and track your readership through Feedburner
Making subscription buttons prominent
Pushing content to Twitter and Facebook
Adding the right hashtags to Twitter
Offering email subscription on your content

Practice: Burn your feed and add the Feedburner RSS and email links to your site.

8: Experimenting with Multimedia – What else can I create besides text?

Creating a videocast
Creating a podcast
Embedding a video
Creating a screencast
Inserting images
Working with image galleries

Practice: Embed an image with a caption. Create a gallery. Embed a Youtube video.

9: Blogging for your company – Should I be my company’s blogger too?

Not as fun as you might think
Content curation strategies
Time commitments among other responsibilities
Platform compromises

Practice: Read your airlines’ blog and assess why it is or is not appealing.

10: Making money – This is taking a lot of time. How do I make money to justify it?

Amazon Affiliate links
Google Adsense
Sidebar advertising
Promotion of a product or service
Career leverage
e-books

Practice: Add an ad to your sidebar. List 3 companies who might be willing to place ads on your site.

11: Writing compelling content – What can I do to create posts that make an impact?

Telling stories
Danger zones with personal and corporate sensitivities
Having an opinion
Being insightful
Resting and rereading before posting

Practice: Decide on a story you can tell for a post. Share it with others.

12: Running out of ideas – I’ve run out of ideas to blog about. Now what?

Read –use Instapaper
Write about what you’re doing
Content curation
Collaborative posts
Guest posts

Practice: Mine Twitter for hashtags to identify a good post related to your blog’s niche.

13: Running out of time – Where do I find the time to post to my blog?

Staying up late, losing sleep
Speeding up posting with Press It.
Combining your current goals into your blogging efforts.
Recognizing everyone has content overload already anyway
Maintaining motivation despite crickets

Practice: Use Press It to post a link and excerpt from another blog.

Blog Sponsors

Organizing Help Content: Breaking Out of Topic-Based Hierarchies

Tom Johnson — Mon, 21 Mar 2011 14:20:45 +0000

At the upcoming STC Summit in Sacramento, I’m presenting a session titled Organizing Help Content: Breaking Out of Topic-Based Hierarchies. The title is a bit wordy. It’s basically information architecture applied to help content. Or even simpler, making help content findable. In this post, I’ll give you a sneak peak at what this presentation is all about.

One of the biggest challenges technical writers face is enabling users to find the right help topic amid hundreds of topics in a help system. Although the default approach in an online help file is to group the topics by task or topic in a table of contents (TOC), this method has its shortcomings. The traditional TOC only works well if each topic neatly fits into its own group, and if users are familiar with all the terminology.

In reality, topics frequently overlap with each other and can be grouped in myriad ways depending on the perspective. The terms used to describe the topics are also often unfamiliar to users. As a result, when users open the help to find information, they see an intimidating array of topics to look through, with names that don’t mean much.

In many cases, the problem isn’t a lack of information, but that users can’t find the information. How many times has a technical writer grumbled “read the manual” when a user asks a seemingly simple question. How do you make your help content more findable for users? How do you enable the user to find the exact topic he or she is looking for with little effort? That’s the main question I address in this presentation.

Alternative Organization Schemes

Of course you want to implement an organization scheme that will be most familiar to your users. But any group of users will have a wide variety of perspectives, backgrounds, experiences, needs, schemas, skill levels, locations, and learning preferences. How do you help all these different users find a specific topic in a sea of help content?

There are a variety of ways to organize help content. The traditional topic-based organization may not always be the best method.

Fortunately this problem isn’t unique or new. An entire discipline, information architecture, is focused on solving the problem of findability. Information architecture’s goal is to improve the user’s ability to find information in a complex system, whether that system is a website, blog, library, grocery store, or something else with a lot of items.

The organization scheme you choose should be one that makes sense not only for your users, but also for your product. Some products, such as shoes, naturally give rise to certain facets that you could use to organize the information (for example, mens/womens, sports, dress, kids, running, basketball, tennis, color, size, and so on).

With help systems, because the product is information, the facets aren’t always so apparent. But there are still plenty of organization schemes to draw upon. The following are fifteen organization schemes you could use as alternatives or supplements to the topic-based TOC.

Organizing by audience. Audience may be identified by their role, discipline, or department. The idea is the same: by identifying the audience, you can present the topics most relevant to that audience.

Organizing by skill level. Skill level can be divided into beginning and advanced tasks. Users new to the system can see a list of topics appropriate to beginners, while advanced users can see the more difficult topics.

Organizing by format. Format can be grouped by videos, quick references, manuals, online help, diagrams, tables, or other formats. This helps users looking for help material based on their learning preferences.

Organizing by popularity. Popularity can be established by most emailed, most blogged, most viewed, or most searched content. Users know that if a topic is popular for others, it’s probably relevant to their needs too.

Organizing by story. Stories might include persona-driven workflows described for various roles. In the stories, as you describe the actions the users take throughout the workflow or process, you can link to the tasks or topics that describe those actions. This story-driven structure can give users the big picture while providing navigation to each of the specific topics for more detail.

Organizing by chronology. A chronological organization might present topics linearly based on the workflow sequence users step through as they use the application. Alternatively, chronology-based organization could include information based on release date, or it could show the latest topics added to the help.

Organizing by problems/issues. Problems/issues could include frequent support requests or knowledge base articles. This problem/issue-based organization might contain titles highlighting broken functionality, bugs, or non-existent-but-frequently-asked-for features. Highlighting problems is the reverse of traditional documentation: rather than explaining the features, you’re calling out areas of broken/non-existent functionality.

Organizing by alphabetical order. Alphabetical ordering is usually an index, which is more commonly omitted in online help in favor of search. However, indexes can also provide users with a way of learning the official terms used in the help. Once they know the right terms, users can quickly move to the place in the help that provides those terms. Users are usually familiar with referring to indexes as a way to find content.

Organizing by screen. Screen-based organization schemes are usually not a best practice as the default, but depending on the application, this organization might help users stuck on a particular screen. In this system of organization, you list out all the tasks and topics that relate to each main screen. If you already have context-sensitive help, you probably already have screen-based topics.

Organizing by geographic location. Location refers to the geographical context of where the user is located. If some information might be specific to users in, for example, Africa, Japan, or South America (such as time zone notes, terminology, translated material, etc.), this organization scheme can help them locate what they need. Remember that usage of an application often varies based on one’s location. For example, the European Union has specific data privacy laws that might affect what information you can show in your application.

Organizing information in-context. In-context organization groups the help topic in the location where the user needs it. This is often referred to as context-sensitive help or on-screen help. Help icons in the interface, pop-up modals when a user opens a new screen, or embedded on-screen text can help users find information when they need it.

Organizing by related information. Related information contains a series of logically related links placed at the end or along the side of each topic. This method provides navigation directly within the topic, where users often spend the most time. To reduce cross-reference errors, related links might be grouped in relationship tables.

Organizing by next steps. Next steps is similar to related information, except that the next steps are more sequential and appear directly below the last paragraph of the topic. In a modular authoring, because each task is chunked from other tasks, many individual tasks may build on each other but be discrete topics. If each task is chunked as a discrete topic, search results may spread them out in a disconnected way. The next-steps link below each topic gives coherence to these discrete-but-connected topics.

Organizing by business goal. Many times users have general business goals in using an application. These goals don’t often translate into task or topic titles. For example, a user may want to do work in less time, or increase focus in meetings, or encourage communication among employees. Understanding your user’s goals is key to writing help in the first place, but we often forget these larger goals and get mired in more technical specifics. When you organize by goal, you can connect the larger business goals of the user to specific how-to tasks.

Organizing by level. Content can be divided into a series of learning levels, similar to the way video games or karate lessons move users from one level to the next, providing more advanced information as the levels increase. This organization scheme is more of a course-based organization pattern.

Many of these organization schemes can be leveraged by perhaps tagging the topic or assigning it to a specific category, and then calling all of those tags or categories. Additionally, these techniques can be layered on top of each other or used in various combinations.

Search

Invariably in discussing findability, many writers believe search will bail out the user when the TOC fails. Search does work well for known items – meaning, when the user knows the exact term he or she is looking for. But we often make erroneous assumptions about how search works in help systems simply because of our familiarity with Google.

Search algorithms. Google’s search works primarily through a system called Pagerank, where backlinks pointing to a site act as a vote of confidence for that site. The more votes, the higher the Pagerank. The pages with the highest Pagerank rise to the top of the search results.

Your help system probably doesn’t use Pagerank at all to determine search engine results and visibility. Every help authoring tool has its own search algorithm. For example, Flare ranks exact keyword matches highest, then keyword frequency, and then keyword location. WordPress gives more weight to more recently authored content. SharePoint has another system of rank for showing content.

You need to understand the search algorithm that is driving your search results. Once you understand your search algorithm, you can take appropriate steps to increase visibility of help topics in searches.

Terminology challenges. One major problem in optimizing for the right keywords is figuring out which keywords to use in the first place. Users may employ a variety of terms to refer to the same thing. Do you go with the official term the project team uses, or the term more familiar among users?

Some help authoring tools provide synonym features, in which you can equate the same term to provide similar results. Still, helping users locate topics when they don’t know the right terms is a major limitation of search. This is why organization schemes (which allow browsing) are still important.

Multiple algorithms. Another consideration is how to optimize your content when it is searchable within a larger infrastructure than just your help system. You may use a help authoring tool to create your content, but then store this content on a SharePoint infrastructure, or push it out to a website indexed by Google. In that case, users may use another search tool to find your help material. As a result, you have to optimize your site for two different search algorithms – the help’s search and the host’s search.

This can be tricky, because if you stacked a keyword with a lot of frequency in your help topic, optimizing for Flare, Google may penalize you for trying to game the system with overuse of this keyword. Google prefers that you repeat the keyword only about once every 100 words. Flare, on the other hand, won’t penalize you at all for repeating the same word 50 times.

Video and images. If you have video and image content, you need to take extra steps to ensure they appear in the search engine results. With video, about the only technique for ensuring search engine visibility (beyond the title) is to include a transcript below the video. You can also create video XML sitemaps to increase visibility on Google. With images, a lengthy caption can provide the text search engines need to read the content.

Intelligent search results. Ideally, you want the most popular help topics to gravitate higher in the search results, given that more people are looking for them. If you can weight your help topics with metadata other than keywords within the topic, this can improve your search results considerably.

Conclusion

Both browsing and searching are two fundamental ways users can locate the help topics they need. In this presentation, we’ll dive deeply into these two subjects with examples, challenging scenarios, and practical advice.

Blog Sponsors

100 Rejected Summit Proposals

Tom Johnson — Tue, 24 Aug 2010 14:25:34 +0000

100 Rejected Summit Proposals

The call for STC Summit proposals is now open. Below are 100 Summit ridiculous proposals that were rejected in the past. They may be helpful as you prepare your own submission.

100 Mistakes I Made During My First Hour as a Technical Writer
Technical Writer Versus Technical Communicator Versus Technical Author: Who Are We? Who ARE We?
Robohelp Versus Flare: The Final Showdown, This Time the Matter Will Be Settled Physically
Pronoun Linguistical Analysis of Button Labels on Financial Graphic User Interfaces of Romanian Currency Banking Applications
Is Technical Writing Boring? Yes, No, Yes, No
The Jackson Pollock Inspiration Behind the STC.org Home Page
How to Start Petty Grammar Disputes Without [Deeply] Annoying Those Around You
Ping Pong Techniques So You Can Play Like a Developer
Best off-Line Practices for Tech Comm Influencers, Including Party Etiquette, Techniques for Waving, and Superficial Conversation Starters
Choosing the Right Twitter Picture: Twitter Pictures for All Occasions!
Let Bylaws Be Bylaws: The Fascinating History of New York’s Bylaw Practices, Origins, and Future, Including an Inside Look At the Seedy Underbelly of Bylaw Formation 62.3.5.1
Technical Writing With Your Pet: Incentivizing Animals to Help Out With Usability Testing
Twifficiency, Twindexing, and Twusability: Tweqniques for Twelite Twechnical Twriters
How to Break Out of Technical Writing and into What You Love — Even If It Pays Nothing
Ninja Techniques for Observing [Killing] Users
NINJA!
Tech Writer as Janitor, and Other Depressing Metaphors to Keep in Mind Throughout the Day
Using Sarcasm “Effectively” in the “Work” “Place”
Tomato Throwing Session (for no particular reason)
Un-Leadership Day
Strategies for Solace: Managing All the Alone Time in a Happy Way
Flopping, Bouncing, Cradling: A Study of Hyperbole and Metaphor Used By Application System Engineers (PhD Dissertation)
“Sharepoint Can Do that” — Mantras Technical Writers Need to Master in a Microsoft Shop
Everything I Needed to Know About Tech Writing I Learned in the Hallways of Second Grade (not really)
Fishing and Technical Communication: a History of Nots
Learning to Love Demoralization
An Interface Is Like a Crappy Student Essay: Helps for Teachers Transitioning into Tech Writing
Publishing On the Fly — Literally
Dr. Pepper Versus Root Beer, Let the Forces Rally
Completely-Impossible-But-Fun-to-Explore Hypothetical Ethical Scenarios in the Tech Comm Workplace
The Art of Art, and Other Illustrative Techniques
Technical Writing and Mythological Deities: How Zeus Reclaimed the UI From the Underworld of Hades
Moving Up and Down: Technical Writers Who Are No Longer Technical Writers (Some Are Unemployed and Living in Trailers, Others Are Rich and Living in Soho)
Fulfilling Your Wasted Literary Talent Through Microtweeting
Bringing Back the Use of “Which”: An Anti-Movement Against Restrictive Clauses
Declente, Post-Pluperfect Tenses, and Hyperbolic Supposition: All the Grammar Rules You Should Know But Actually Have No Clue About
If You Give a Technical Writer a Cookie … and Other Slippery Slopes
Technical Writing Horror Stories for Children
The End Is Near: A Manual for the Upcoming Apocalypse, Complete With Notes, Tips, and Cautions
It’s Never too Late to Change Your Name, Join a Motorcycle Gang, Or Learn to Play the Vuvuzela — Special Session By Kathyrn Burton
Three Way Blind Round-Tripping From Robohelp to Twitter to Facebook and Back Again
Sharepointize This!
View Source: An Unexpected Peek Behind the Technology that Powers Airport X-Ray Machines
Restructuring the IT Totem Pole with New Totems
Patience Is a Virtue for the Weak, Aggressive Attitudes Get Results: Tips and Tricks and Really Mean Phrases to Get What You Need/Want
Red Rover, Red Rover: Team Building Techniques for Athletic Technical Communicators
Pedagogical Discourse in Canonical Contexts: A Heuristic Investigation into the Academic Rhetorical Linguistic Meaninglessness to Distract or Impress
If I were a ________________: Tech Writer Spinoffs on Fiddler On the Roof (includes dance and song)
Will It Blend? An Experiment with Thick Manuals (bring yours)
Deep-Fried Quick Reference Guides: Everything Reads Better Deep Fried
Documentation On a Shoestring — the Ultimate Convenience for Walkers and Runners
Name that Persona
Documenting Spumoni: Exploring the Hidden World of Ice Cream’s Most Challenging Flavors
It Was the Worst of Times, It Was the Absolute Worst of Times: Managing Last-Minute Project Manager Requests
Live and Learn, Die and Burn: The End of One Technical Writer’s Career
15 Ways to Get Around Skimpy Billing Codes and Maneuver Out-of-Scope Budget Issues Through Off-Shoring, Laundering, and Defalcation
Predator Versus Alien: Interacting with Project Developers
Incredible Stunts By Technical Writers Mostly on Drugs
Sitting Pretty: Your Looks Alone Won’t Get You By in Tech Writing
Preserving Documents in Sub-Kelvin Temperatures Through the Next Ice Age
Christmas Lists and Stocking Stuffers for Technical Writers
Jeopardy: The Final Hour, Academics and Descartian Philosophers Test their Knowledge of What Is Real
Technical Writing in the Golden Years: The Final Countdown to the Last Manual
Logging into STC.org: Tips, Tricks, and Techniques for Understanding the Sign-in Process and Subsequent Home Page
Deconstructing Tech Comm, for No Reason Other Than We’re Bored
Technical Writing in Hyperbaric Chambers for Those Moments When You Really Need Oxygen
A Panel About Panels: What You Need to Know to Lead a Good Panel Discussion (Panel Format)
Style Guides Across the Ages: From Chaucer to Vonnegut, the Technical Style Guides the Masters Didn’t Use
Of Mice and Pen: A Sad Story About How One Technical Communicator Accidentally Stepped On a Mouse
Let Go, Live in the Moment, and Other Useless Advice for Technical Communicators
Making Sense of ISO 9437395-5.A-12, the New Standard for Federally Regulated Rocket Fuel Cylinder Valves
Paranormal Documentation and Zombie Usability
Project Managers in the Mist: a Mockumentary
Cloning 101 and Time Banishment, or How I Learned to Stop Worrying About Deadlines and Love the Project Plan
The Technical Writing Hypnotist: Subliminal Techniques for Deep Topic Investigation
Forming the Banana Publications Style Guide: A Contrarian Reaction to the Apple Style Guide
Beyond the Bleeding Gut: Innovations that Failed
How to Build a Robust Content Management System Using Common Tools You Probably Have Under Your Sink or in Your Garage
DITA: It’s Magic
The Dirty Little Secrets of Technical Writing Everyone Wants to Know But No One Will Tell You
Disturbing Stories of Seemingly Undisturbed Technical Writers
Little Did I Know … : Reflections on a Career in Technical Writing
Conquering User Hearts, Minds, and Hopes — One Help Topic at a Time
Indexing for Hard-Core Word Nerds: No-Holds-Barred Techniques for Seriously Aggressive Indexers
Country Songs and Anarcho-Punk Music By Technical Writers
Love Affair With Commas: A Guide for the Sick and Twisted (Includes Both Curly and Straight Commas)
Prison UIs for the Criminal Mind: Implementing the Impossible Exit, Infinite Loop, and Other Recursive Workflows
Comma-Lamas: Comma/Lama Breeding Hybrids
Killer Apps for Killers
Don’t Make Me Think Part 2: “Don’t Make Me Move”
Semicolons Are for Sissies, Dashes Are for the Undaring, and Other Useless Punctuation
Adobeization Nation
Exclamation Marks and Humor: The Hot Sauce of Technical Writing
Watch-Learn-Do-Be-Become-Now-Read-Manual-Must: A New Approach to User Education
The Plain Movement: Plain Language, Plain Clothes, Plain Hair, Plain Names — Loving Plain in a Plain Way
The Grammar Thief: Stealing the Best Grammar Out There Everyday
Technical Writers on a Plane: A Thriller with Intrigue, Espionage, and High Speed Documentation Action 30,000 feet in the Air
Documenting the Edges of Outer Space: An Unknown Manual About the Unknown Unknowns (contents still to be determined)
99 Pages of a Manual on the Wall, and other Party Games Technical Writers Love
Documentation Strategies for the Antisocial Web

Photo from myyearofnewthings

Blog Sponsors

Simple Tips for Website Accessibility: Brenda Huettner at the STC Summit in Dallas, #stc10

Tom Johnson — Mon, 10 May 2010 04:12:03 +0000

In this interview, I ask Brenda Huettner, who is writing a book on accessibility called Communicating with Everyone, to provide some practical tips for making my website, which includes audio, video, images, and text, more accessible.

Blog Sponsors

The Do-It-Yourself Philosophy: Saul Carliner at the STC Summit in Dallas, #stc10

Tom Johnson — Mon, 10 May 2010 04:07:55 +0000

In this video, I interview Saul Carliner about a post he wrote on his blog describing the “do-it-yourself” philosophy and whether this philosophy is something technical communicators should embrace or fear.