Information exclusion is fairly common. Just last week I learned about an application that had a new version nearing release in a week, but the developers hadn’t told me about it. I documented the previous version, and although the developers made the help button more visible, they never told me they were releasing a new version. They never mentioned to me what they had updated.

In their minds, they hadn’t updated much. A few enhancements here and there, but did any of it affect the help? They didn’t know because frankly, they probably never read the help. In their minds, help had been checked off the list weeks ago. There was no need to revisit it. Besides, they were mostly working on bugs and fixes, not new use cases.

When I learned, through a general department meeting, that a new version of the application was being released in a week, I scrambled back into the application to find out what had changed. As I moved from topic to topic through my help and the interface, I spent the next 30 hours making updates to the help content. I had to scrap all of my videos, as they were no longer accurate. I added some new topics, removed others. Fundamental terminology changed, and new functionality had been added.

As I sat there updating the documentation against the clock, I could hardly believe I hadn’t been notified. C’mon, were they really going to release this without telling me what needed to be updated in the help?

I was a bit upset for a few days, but under too much pressure to really think through the why of the situation. Instead, I was heads-down, hands on the keyboard, frantically making updates and logging bugs and trying to fix things before they shipped it out the door.

Though I tried not to think this way, I started to resent the project manager a bit. I had rarely been invited to a project meeting or scrum. I had to persuade the project manager that their app needed comprehensive help in the first place. Wasn’t the project manager savvy enough to know that with each update to the interface and functionality, the help needed to also be updated?

This is a situation you’ve probably run through dozens of times. Once early in my career something like this happened — the interface kept changing on me, and no one ever informed me about the changes. One of my senior colleagues looked at me and said, with a smug look on her face, “Welcome to our world.”

In those early days as well as the other week, when I experienced developer neglect and suffered a lack of information, I felt marginalized. I tasted the second-class citizenship status that so often takes place in IT organizations with technical writers. The tech writer is the last to know about interface updates, if anyone even bothers to let him or her know.

The perception of information exclusion, whether real or not, is so common among technical writers that it might even be classified as a complex. If you suffer from an information exclusion complex, you’re disgruntled at project teams for not telling you the information you need to do your job correctly. The project’s information door has been shut on you, and you must kick your foot under the door to wedge it open.

Well, I have started to figure out how developers tick, and I recently discovered something that has helped me break free from my information exclusion complex.

How Developers Tick

I didn’t piece this together all at once, and it is still a picture that is forming in my mind, but it’s compelling. At the heart of how developers, quality assurance (QA) engineers, and project managers interact is through a bug/enhancement tracking system called JIRA. In your organization it may be something else, but the concept will likely be the same.

In my organization, every time QA engineers find a bug, they log it in JIRA. Every time project managers have an enhancement to the existing functionality, they log it in JIRA. Every time developers fix something, they log it in JIRA. Every change to the application gets logged and tracked in JIRA.

The project manager and QA lead assign the items in JIRA to developers. Developers and QA comment on each of the JIRA items, noting challenges or obstacles to the JIRA item. Project managers give each JIRA item a priority level, so that P1s get the most critical attention, while P3s are usually not worked on at all. In short, JIRA stores all of the necessary information for the project.

I have simplified things here, because even though all important and changing project information is stored in JIRA, the JIRA system itself is like a maize to navigate. In one of my projects, we have nearly 2,000 items in JIRA, all with various priority levels, version release assignments, sources, dates, comments, and other details. Navigating JIRA can be like looking at a street map of Mexico City and trying to decide where or how to go.

Despite the challenges, keeping up with JIRA, I’ve learned, is the key to staying on top of a project. It’s how the developer mind works. Once you understand this, it will help cure all symptoms of the information exclusion complex. If a developer logs something in JIRA, whether it’s a bug, a fix, an enhancement, a user story, or even an update the server the application runs on, he or she expects that everyone else on the project who has access to JIRA will see the update. The developer assumes everyone is as JIRA-savvy and JIRA-driven as he or she is.

As technical writers, we often scorn users who are too slow/lazy to read the manual (RTFM). The corollary for developers is to scorn technical writers who are too slow/lazy to read JIRA (RTFJIRA). See how the tables are turned?

Leveraging JIRA to Influence Changes

Don’t be intimidated by JIRA, or whatever bug tracking software you use. JIRA is your best friend, because now that you know the secret — that JIRA controls all information about a project — you can start to leverage this information source to influence updates and changes to the application as you see fit.

You know that capitalization error on the home page of your app that is driving you nuts? Stop complaining about it in project meetings. Just log it in JIRA and it will probably get done. How about the error message box that says, “Object reference not set to an instance of an object.” You’ve been telling developers for months that no one will understand it. But they aren’t waiting for an email from you to specify how to fix it. No, they’re waiting for the item to appear in JIRA. Like a cook waiting for an order, developers will simply see the request on their screen and get to work.

Not every thing you slip into JIRA will get implemented. The tough fixes will be procrastinated, just like you have procrastinated the toughest help topics in your help. When developers feel weary and tired, and when they’re winded from playing too much ping pong, they’ll cherrypick the easy JIRA items that require nothing but simple text updates — your capitalization pet peeves, the label misspellings, those inane on-screen messages that developers typed while they were half-asleep. As long as you stick your requests in JIRA, they will eventually get done.

Still a Few Surprises

Although I’m following JIRA more carefully now, I still get surprised by project release dates I wasn’t anticipating. But this is only because I fail to check the project items and statuses. Lately, however, I have subscribed to the RSS feeds of the comments and issues in JIRA I want to track. (By the way, RSS Bandit is one of the few RSS readers that can pull authenticated RSS feeds behind your corporate firewall and send you updates when additions are made.)

Even if I’m surprised every now and then by unanticipated changes, I’ve completely shed the information exclusion complex. I’m not frustrated if developers don’t tell me about interface and functionality changes. In an agile environment, there’s no way they can keep me updated on an individual level about everything that changes. And I wouldn’t want them tapping on my shoulder all day anyway. I can learn most of what I need to know just sitting in my chair, looking at my screen, submitting new items to JIRA or looking at those JIRA items that have been submitted. Every once in a while I drop by the developers’ desks, but more to say hello than to ask what’s new.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Adding more sidebar sections

Adding more sidebars is useful if you’re using WordPress more as a content management system than a blog.

Someone asked me how I did this. The process isn’t hard. I’ve broken it down into three steps. (Before you continue with the instructions, you may want to back up the information in your existing sidebar.)

Step 1

Add this code to your functions.php file under Appearance > Editor.

if ( function_exists('register_sidebars') )
        register_sidebar(array('name'=>'Sidebar Home','before_title'=>'<h4>','after_title'=>'</h4>'));
        register_sidebar(array('name'=>'Sidebar Jobs','before_title'=>'<h4>','after_title'=>'</h4>'));
        register_sidebar(array('name'=>'Sidebar Meetings','before_title'=>'<h4>','after_title'=>'</h4>'));

In this example, the sidebars that will be added will be called Sidebar Home, Sidebar Jobs, and Sidebar Meetings. Change the names to whatever you want. You can add many more sections here, not just three.

You can also add more arguments than simply name, before_title, and after-title. See the full function reference and arguments with registering sidebars.

You’ll also need to delete the previous register_sidebars function so that the two don’t conflict.

Step 2

Add a reference to the sidebar section where you want the sidebar to appear in your theme. For example, type the following to insert the Jobs sidebar:

<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('Sidebar Jobs') ) : ?>

To insert the Meetings sidebar, you would type Sidebar Meetings rather than Sidebar Jobs.

Step 3

In a text editor, duplicate your existing sidebar code, rename the file (for example, sidebar_jobs.php), and FTP the file into the folder with your other theme files.

Where you want the file to appear (probably in a specific page template), add this reference to the file:

<?php include (TEMPLATEPATH . '/sidebar_jobs.php'); ?>

Remove the other code that calls the sidebar (probably get_sidebar). Now that page template will show your Jobs sidebar. And you can configure your Jobs sidebar under Appearance > Widgets.

Although I’ve mainly been calling these sections a sidebar, you can create sections and insert them anywhere in your site, such as the footer, an ad space in the header, or elsewhere.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Further, in WordPress 3.0, WordPress MU and regular WordPress will be merged. This is huge, because it means you’ll be able to create child blogs with a regular WordPress install. Essentially we could have one site like stcchapter.org with dozens of child blogs, containing subdomains such as intermountain.stcchapter.org, wyoming.stcchapter.org, and so forth.

For those chapters that just wanted a simple web solution, they could create a child blog from this site. They could also point their regular domain to the site. The themes and plugins available in child blogs are dependent on what the parent blog chooses to provide.

I think the idea of providing a site template from WordPress is ingenious. It made me think about exactly what a chapter WordPress template would look like. I wish I could say our Intermountain-STC site is a perfect example, but it’s not (not yet anyway). I spent a good chunk of time this weekend tweaking a few things. Here are several elements that I think a chapter WordPress template would have.

Subpage Lists

One aspect of websites that appeals to me is an apparent simplicity up front. A single navigation bar at the top of the site showing about seven or eight buttons is all I want. Home | About | Blog | Meetings | Jobs | Resources | Events. Something simple.

To accommodate this simplicity, the sidebars for each of the pages should show all the subpages for the current page. And here the amount of content in the sidebar can be as abundant as you want, from three page links to thirty or more. The submenu page list hides the complexity. (Fortunately, showing a list of subpages for the current page is simple with the LJ Subpages Widget plugin.)

Subpages appear on right for the selected page, allowing you to hide the complexity of information up front and only show the information when a user is on the relevant page

Custom Sidebars

Implementing custom sidebars feature takes the concept of the subpage lists to another level. Each main page should not only show the subpage list for the current page but also have an entirely unique sidebar showing content specific to that page.

Why? Two reasons. If you have the same sidebar content for each page, the reader’s eye becomes blind to it. So even if you have the changing subpage list at the top, the reader may not notice the changing links if the rest of the sidebar remains the same. But if the entire sidebar changes for each of the seven or eight main pages, that’s something you notice. The reader can anticipate that the sidebar content will contain unique content for the specific page he or she is viewing.

The sidebars are unique for each page the user is on. For example, with the Jobs page, the user can see information on subscribing to job email alerts and a jobs RSS feed.

Second, having a custom sidebar for your page gives you more room to present information for that page in an attractive format. You can give more information to the reader above the fold, without having to scroll.

Author Pages

Above all else, a chapter site should be collaborative. Multiple chapter members should be able to access it, author content, and publish. You want to highlight and promote the collaborative nature of the site. Posts usually contain a byline, and the byline is a hyperlink to the author’s name that shows the author’s bio and posts. The default author template called is the author.php page, so you can customize this page to show the author’s picture and bio information at the top, like this:

Author pages show contact information, profile text, and posts published by the author

You can also show a list of authors in your sidebar (see the lower-right section of the image above).

Special Widget Sections

One of the cool things about WordPress is the drag-and-drop widget feature. You drag the widgets you want into the sections on the right. Most people don’t realize that you can create additional sections for your widgets that map to different areas of your templates. For example, you can create 10 or more special sections that correspond with the different pages. This way the people who maintain the site can configure the sidebars without even touching the code.

In the following screenshot, you can see that I’ve created a new sidebar section for each of my main pages. You can now drag whatever widgets you want into each of those sections, depending on what you want in the sidebar for that page. This is one way you transform WordPress into a CMS.

You can create new sections for your widgets

Custom Homepage

Rather than showing About information or a list of the latest posts, I think the home page best serves its purpose by showing the next chapter meeting, the latest jobs added to the site, the latest blog posts, and general news. The home page of a chapter site should give you a summary of all the important information you may need to know.

The home page shows a summary of the most important information

These are just my initial thoughts about what a chapter WordPress template might include. I’m currently trying to convert the Intermountain-STC.org site into exactly this template. Any thoughts on what else a chapter or SIG site would need?

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Although I spent three years in a creative writing program holding exactly these types of writing workshops, in which a group of people provide feedback on the story or essay someone submits, it never crossed my mind that designers probably sit around tables doing the exact same thing with websites.

Design Reviews

Regardless of the topic, the methodology of the workshop is mostly the same. In a tactful way, you explain what works well and what could be improved. Others either agree or disagree with your analysis, and hopefully they explain why. The only difference between critiquing creative stories and websites is in the questions you ask. Rather than ask, what’s the story here? Are the characters believable? Does it have arc? You ask questions about findability, simplicity, readability, and so forth.

I found that in looking at websites, my feedback could be grouped into about seven categories:

Purpose

• What are you trying to achieve with the site?
• What do you want the audience to do on the site?
• What do you want feedback about?

Findability

• What are some things your users might be looking for? Is it easy to find them?
• If you search for something, are the results accurate?

Simplicity

• Is the site navigation simple to understand?
• How does the site handle submenus to provide additional information?
• Is the site busy?
• Is there enough white space in the site?

Readability

• How easy is it to read the content?
• Is the font size, column width, leading, and typography working together in a readable way?
• Can I subscribe to the content with Facebook, Twitter, RSS, or e-mail to read it in the format I want?
• Are the paragraphs small, broken up with lists, blockquotes, and other formatting varieties?

Interactivity

• Can I add comments on things I read?
• Can I read other people’s comments and reply to their comments in a threaded way?
• Can I contact someone through an email address or contact form? If a contact form, do I know where it goes or if it sent correctly?
• If I have a job to post, can I submit the details myself? Can I even post it myself?

Content Appeal

• Is the content interesting to read?
• Is the content current?
• Can multiple people author and maintain content, so that all the burden isn’t placed on one person?
• Do you integrate your news into real-time articles/posts on the site?

Design Appeal

• Where do my eyes focus naturally focus on the site?
• Are there any design element repeated?
• Is the site attractive to look at? Why or why not?

For more on running a design review, see Scott Oberkun’s How to Run a Design Critique and Makiko Itho’s The Delicate Art of (Web) Design Critique.

Trends from the Analysis

If you go through each of these categories, you usually find something worthwhile to say. We analyzed six different sites: Quality Process SIG, Twin Cities, Heartland, Tech Editing SIG, Orlando, and the Contracting and Independent Consulting SIG.

The webinar description suggested that we would explore ways to build attractive online sites where members could interact and find value, because fewer and fewer people are physically gathering for meetings.

As we moved through the sites, it was clear that a lot of people were trying to move in exactly this direction — towards collaboration and participation. The Quality Process SIG adopted SharePoint to make it easy for numerous people to author content. Twin Cites integrated a social networking component in a custom CMS where members could friend each other, add personal details, and even write blog posts. Orlando was in the process of moving their content to WordPress because their old site was a “dinosaur.” The Tech Editing SIG built their content on a wiki platform containing a section that showed posts from their email list discussions in an automated way.

What’s Missing

To enable participation and collaboration, many of the platforms allowed you to comment, subscribe, interact, log in, and manage the content. This makes sense.

But the platform is only the first step. Whether you’re using WordPress, Drupal, Joomla, SharePoint, Ning, or any other Web 2.0-capable technology, a larger ingredient is missing from the recipe for a thriving online site where members naturally gravitate to for interaction. Your site can be as interactive as anything can be, and yet still remain dormant, unused, unexplored, rarely visited, and rarely even noticed unless you provide a reason for people to come together as a community.

For example, although the Twin Cities site offers the ability to friend others, blog, and add personal details about your location, interests, and other details, it isn’t generating the activity you see on Facebook.

What’s interesting about Facebook isn’t that it allows you to write on other people’s walls, provide status updates, or add other people as friends. What’s interesting is that so many people are on Facebook, checking it and posting to it daily or even hourly.

Is it possible to create an online platform that technical communicators would use with as much popularity as Facebook or Twitter or even Stack Overflow?

The problem, I think, is in gathering a critical mass of community. Chapters are so small, it’s hard to see much activity from members on a site. For example, our chapter now has about 20 members (as opposed to about 75 from last year). To think we’ll convert the site into a thriving hub of online interaction is an illusion. You need thousands of people to build up the exchanges that take place in a popular community. When you have the thousands of people coming to your site every day, they begin to interact, and the interactions fuel more comments and replies and posts. At some point, you have a thriving community. But you don’t build a community without a critical mass of participation.

Without a critical mass of people to form a community, you end up with a dormant-looking site — for example, what most chapter sites look like.

The Ning Community Scott Abel created comes closest to the thriving online site where members can interact, but even that site seems underused. I just logged into the other day for the first time in months.

Again, the main problem is in the critical mass. There just aren’t enough people in chapters to form a presence on a site. Chapters and SIGs fragment the already small online technical communicator audience.

Additionally, although SIGs have greater potential for online interaction, most of the activity is often better expressed through e-mail listservs and threaded forum discussions. As old-school as email or forums are, they’re fast, immediate, and reach almost everyone.

The Solution?

I’m not really sure what solution is for chapter and SIG sites to move from dormant sites to thriving hubs of interaction. Technical writers are a small niche of overall people on the web, and when you fragment that already small niche into even smaller groups of chapters and SIGs, they never seem to come together in a critical mass of people.

This problem isn’t unique to our group. It’s a problem that stems for many independent publishing locations and sites. Conversations are taking place on blogs here and there, email listservs here and there, forums here and there, and the consequence is a bunch of whispers that you can’t hear (unless you look in each of the individual places).

I believe the solution won’t involve centralizing the information/people into one site and location. Instead, it will involve aggregating the sources through RSS and other technology.

jQuery is the new Javascript. It provides smooth functionality that shows and hides components, slides objects around, and animates graphics in a sexy way. As an example, ProPhotoBlogs’ support section incorporates jQuery functionality. And the drop-down menus on Will Sansbury’s site are also jQuery driven. Here are a few jQuery animation effects. And slide-down effects. And fade effects.

Alistair says he feels satisfied he made the right choice about adopting Flare as a help tool because of this extensibility. Because of the XML and CSS standards that Flare is built on, Alistair can add a reference to the jQuery script in the header, add functions in the page body and toolbar, and hook into other technologies to customize the display.

For detailed step-by-step instructions on inserting functions into Flare’s Webhelp toolbar, see Alistair’s post, Adding function buttons to to the Madcap Flare Web Toolbar.

I like Flare for much of the same reasons as Alistair. I haven’t integrated jQuery scripts into Flare yet. But knowing that I can do it if I wanted to is encouraging.

The next question is what functionality we’re missing from Webhelp. Is jQuery just the latest gee-whiz, bell-and-whistle technology? Or is it functionality that will persuade users that the help is worthwhile?

Alistair says he created a button that shows a direct link to the topic the user is viewing. And he hooked into a custom glossary database. He also integrated his own show/hide functionality and a bookmarks feature. Granted, some of that functionality already exists to some degree in the existing Webhelp buttons, but Alistair’s company had custom needs.

One button I’ve added to Webhelp is a Contact button that allows the user to send feedback to the project team. I would like to incorporate jQuery scripts to make screencasts pop-up in a modal that dims the background. I’d also like to make screenshots expand to full size when the user clicks them (similar to Flare’s new thumbnail feature). The way graphics slide down smoothly with jQuery is more elegant than the built-in drop-down hotspot functionality Flare provides. (I imagine you have to work in the code view to integrate all of this.)

I’m not sure to what extent other tools can hook into the same technologies. But it is important to have this potential — so that help authors can keep pace with the developments and technologies of the web.

To listen to Alistair Christie’s podcast on extending Flare with jQuery, see Unscripted Screencasts and Flare Extensibility.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Will Sansbury and I are giving a webinar on web design and WordPress this Thursday as part of the STC Community Leaders series. In the webinar, we plan to look at about five chapter/SIG sites in depth, examining what they’re doing well and how they could be improved. The sites will merely provide examples to spark discussion about web concepts and techniques (helping us move in a descriptive rather than prescriptive direction).

Here’s the description of the webinar:

Because most communities have far more virtual participants than physical participants, establishing a strong web presence where members can find information, interact with each other, and access resources is critical. In this community webinar, we’ll review a handful of chapter or SIG sites and discuss what’s working well and how they might be improved. We’ll also talk about WordPress — a popular platform many chapters are using for their websites. As a WordPress consultant, I deal with all kinds of WordPress questions, from customizing themes to implementing specific plugins, tweaking the stylesheet, inserting PHP tags, and fixing crashed sites. If you’re currently managing or implementing a WordPress site, bring your questions and I’ll try to answer them. I’ll also go over my top 10 recommended WordPress plugins. [Note: I wrote the description before asking Will to join me in the presentation, so excuse the first person point of view.]

If you’re planning to attend the webinar and you want your site critiqued, let me know. Otherwise, I’m thinking of looking at these five sites:

• STC Montreal
• STC Atlanta
• STC Usability SIG
• STC Twin Cities
• STC Toronto
• STC Technical Editing SIG

The webinar will have a WordPress bent to it, because it’s the platform I’m most familiar with. Technical how-to is always less interesting that concepts, so I only see the discussion veering off into WordPress when we mention ways to implement concepts/techniques in a practical, easy way. I’m also familiar with Joomla and Mediawiki, so if one of those solutions makes more sense, I’ll talk about them.

You can sign up for the webinar here.

Note: In my experience with Genesys, you have to call in via phone. You can’t use your computer speakers. So if you’re calling internationally, you might want to use Skype.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Lyn Worthen presented to the STC Intermountain chapter tonight on running your own business as a technical communications consultant. She covers almost everything you need to know as a consultant, including rates, billing, contracts, marketing, taxes, business structures, hours, salary, tools, locations, niche services, portfolios, client communications, and more.

Here’s her presentation description:

Unlike the consistent schedule, workload, and wages of a 9-5 technical writing job, going it on your own as a consultant or contractor is a lot like riding the tide. Sometimes the tide is “in” and you have plenty of work to keep you happily tapping away on your keyboard; the projects are queuing up, the money is flowing, and all’s right with the world.

Other times, the tide is “out” and you find yourself walking on a desolate beach, staring out at the horizon, waiting for your ship to come in — and, if you’re lucky, picking up the occasional small job still lurking in a hidden tidal pool; money is scarce, and as the siren song of Corporate America tempts you back into the relative stability of captured employment, you question the wisdom of continuing to go it alone.

And then there are the “tsunamis,” those times when you have more work than one person should ever be expected to handle; yet in spite of the fact that you’re barely keeping your head above water, you’re reluctant to say “no” to any of it because you don’t know how high the floodwaters will rise or how long the drought that is sure to follow will last.

About Lyn Worthen

Lyn Worthen’s company is Information Design Co: Technical Communications Consulting, based in Utah and serving local, national, and international clients. Lyn is a member of the STC, the Utah Women Tech Council (WTC), and National Association of Women Business Owners (NAWBO). You can find out more about her through her Linkedin page. To contact Lyn, send her an email at lynw@xmission.com.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Unlike the consistent schedule, workload, and wages of a 9-5 technical writing job, going it on your own as a consultant or contractor is a lot like riding the tide. Sometimes the tide is “in” and you have plenty of work to keep you happily tapping away on your keyboard; the projects are queuing up, the money is flowing, and all’s right with the world.

Other times, the tide is “out” and you find yourself walking on a desolate beach, staring out at the horizon, waiting for your ship to come in — and, if you’re lucky, picking up the occasional small job still lurking in a hidden tidal pool; money is scarce, and as the siren song of Corporate America tempts you back into the relative stability of captured employment, you question the wisdom of continuing to go it alone.

And then there are the “tsunamis,” those times when you have more work than one person should ever be expected to handle; yet in spite of the fact that you’re barely keeping your head above water, you’re reluctant to say “no” to any of it because you don’t know how high the floodwaters will rise or how long the drought that is sure to follow will last.

Everyone is invited, both STC members and non-members. Cost is free (since it’s held in a public library). Read more details here.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

I rarely watch video online. Unless it’s a funny meme I have deliberately searched for, or a show that I missed, or Netflix, I won’t press play. If a blog post is all video, I skip it. I rarely appreciate video instructions, either–they take too long, because I’m pausing, following the step, playing, pausing again. I was having trouble imagining how videos were going to improve our help systems or fit into our schedules.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith

Presented by Sarah O’Keefe, this webcast demonstrates using MadCap Flare to create WebHelp from DITA-based content. Topics covered include:

• Importing DITA content into Flare
• Map file handling
• Cross-references and links
• Relationship tables
• Conrefs
• Conditional processing

By the way, you can keep up with other upcoming webcasts from Scriptorium by subscribing their newsletter, keeping up with their site’s feed, or clicking the Scriptorium graphic in my sidebar.

Blog Sponsors

• Madcap Software, Madpak Suite
• Edit Me
• Webworks
• Dr.Explain
• Scriptorium
• Intelligent Content
• Adobe Technical Communication Suite 2
• Alma Loveland, Designer
• Snagit from TechSmith