From the Doc Side

Using Team Foundation Server to Create a Customer Contact Database: What’s Next? Queries, Reports, and Future Goals (part 5 of 5)

2010-03-16T17:00:00Z

Completing a series of five posts on a project, began in 2008, by the Blackbaud Documentation team.

By: Georgeanne Cheng, Ellyn Hassell, and Lindsey Robbins

We’ve been working with the live version of the customer contact work item for just about a year now. It’s become quite a powerful tool for housing and tracking all our usability efforts and has proved to be more user-friendly than our Access database from the past.

I’ve been particularly pleased with the ease of use – TFS is a tool we use each day to track work items and bugs related to our products as well as our documentation. We also use TFS as source control for our Framemaker files and graphics. During this project’s planning stage, we anticipated that ease of use and a level of comfort with the tool would be a big factor in whether or not our team would be receptive to using TFS tracking usability efforts. Based on feedback we’ve received so far, our team is able to create a work item, add pertinent information, link specific documents or other items, and query on the work item when needed. We wanted this to be a quick and easy tool for our team to capture information and so far it seems to be working!

Queries
So now that we have a good start on entering data, how do we retrieve the information and what do we do with it? With TFS, you can query any field by itself or search using a combination of fields. We spent a great deal of time reviewing ways our team would likely query their own work items. We came up with ideas and also asked the team and our manager for their input (again, pre-planning proved beneficial here!). In the end, we made sure to include popular query fields on the work item form to make data retrieval easier. We also created “canned” team queries under our Documentation team project (see Lindsey’s best practices blog post for details - add hyperlink here). Here are a few examples of data we knew we wanted to retrieve later:

Which type of customer contact (i.e. – customer visit, phone call, etc.) did we implement the most this year?
How many work items did we enter this year and how many of them were wrapped around the same organization/contact?
In a given quarter, what did our usability efforts look like?
Have our usability efforts varied from year to year? If so, in what way?
We wanted the ability to run a query based on product, owner, title, iteration, date, and organization name.

Reports
Querying the system is a great tool and is serving its purpose but we wanted to take it a step further and create usable, measurable reports. Initially, we thought the only way to do this was to create a TFS report under our Documentation team project. We began researching and asking questions. Our QA team proved helpful yet again (thanks Scott!) by talking us through some of the TFS reports they were using. As a reminder, at this time, the folks in Product Development across the board were still new to TFS and there were only a few people who knew enough about reports to offer advice.

We learned you can export data by print, Acrobat (PDF) file, excel file, or XML file (to name a few). This would suffice but we wanted more – something visually appealing should we decide to pass our results to upper management. QA offered additional support by giving us an overview of creating pivot reports in Microsoft Excel. We’d could extract our data from TFS and create Excel charts and tables in basically any format and color we wanted. Within Excel, we were able to connect to SQL Analysis Services, enter the appropriate credentials (such as our TFS server name, user name, and password), and select the correct cube. Once connected, we could select our report filters (such as work item type and team project) and create our report by selecting the desired fields. Once you choose your fields, you can present your data in different chart formats with specific colors and labels.

From the Add-Ins tab in Excel, you can also create a new list and select an existing TFS query which allows you to import data from the query. We can actually import the History and Details tabs of our work item if we want.

TIP – As far as we know, you cannot email an Excel link to your colleague containing pivot report results (results rely on an established connection with the server). To save your results in a share-friendly file, use this Microsoft plug-in to add “Save as PDF” to your Save menu in Microsoft Office programs.

What’s Next?
While these reporting options meet our needs, we have more research to take on and goals to accomplish. Here are just a few items on our agenda:

Learn more about TFS reports – is a report necessary for our Documentation team project? What has changed since we last researched this area?
Learn more about pivot reports in Excel. How can we improve our output? Are there other ways to leverage Excel in creating additional output?
Are there other programs that integrate with TFS to provide better output/results?

Going forward, we welcome suggestions to improve the organization and layout of the work item as well as input on our best practices. When working with a “living” tool – the more you use it, the more you find what works, what doesn’t, and what can be tweaked for improvement. The great thing about the work item is that we can easily export it, makes changes, and import it back in to the Documentation team project. We recommend doing plenty of research and testing before you go live with something like this. The last thing you want is to find yourself entering months of data only to find that a complete overhaul of your work item is necessary. How would this affect data stored on your current work items? How would this affect reporting? As Lindsey mentioned in an earlier post, if you’re able to test in a safe environment before going live, that’s your best bet.

Using Team Foundation Server to Create a Client Contact Database: Best Practices (part 4 of 5)

2010-03-09T18:00:00Z

Continuing a series of five posts on a project, began in 2008, by the Blackbaud Documentation team.

By: Georgeanne Cheng, Ellyn Hassell, and Lindsey Robbins

Wow! We learned a lot in this project. It's been over a year since we began and we still have more we want to do. For example, we want to streamline our process for taking survey data and entering it into our TFS customer contact database. But, before we move forward, we wanted to share what we learned along the way. Without further ado, here are our top 10 recommendations/best practices...

Document everything you learned through the research and implementation phase.
Post the best practices in a place that's easy to edit and improve over time.

We posted ours on an internal wiki. Easy to update whenever we get feedback.
We also provided a table of the TFS work item fields. Each field has an entry on the table. Easy to look up when one is not sure about what to enter on a field.
Provide as many great examples as you can. We spent a lot of time on examples to make sure they reflected the type of content we hoped for in the work item fields.

Practice entering customer contact information in the form before you begin using it as a team. We discovered fields we didn't need or could improve upon when we were practicing the form ourselves. Workflow recommendations can be ironed out at this time as well.
What fields need to be required? When you think about this, you can determine which fields you absolutely need for form entry and which are nice to have. Having only the bare minimum required fields ensures it's a quick painless process. If you get more data, awesome but if not, at least it's better than nothing at all, which is what you'll get if you create a form with lots of required fields
Make note of known issues or hiccups you discover with the work item. For example, we discovered the following issues:

When you link and work item and save it, your reciprocated links may not initially appear (on the Details tab). You may have to close the work items and reopen them to see the links. On rare occasions, you may have to restart TFS in order for the links to appear. This is a known issue with TFS.
You cannot delete a saved work item. You can make it obsolete.

Create flyover text for fields. Okay, so we know not everyone is going to stop what they are entering in a work item to open up an internet browser and review the help documentation. So, we created short flyover text to help users enter content in the fields.
Create queries ahead of time for your team to use. Saved queries prevent frustrations and headaches trying to find work items. We provided instructions on how to access the customer queries and how to choose what displays in the query results. We created the following queries ahead of time.

All Contacts - Customer contact work items not tagged as obsolete.
Contact by Source - Customer contact work items with an iteration path of Documentation/Customer Contact/Source. Sorted alphabetically by source type.
Deleted Contacts - Obsolete customer contact work items.
Do Not Contact - All customer contact work items with "Do not contact" selected in the Communication field.
My Customer Contact - All customer contact work items assigned to you.

Provide a short tutorial to your team before implementation. Walk them through the work item and explain why you are making the change. But, you almost must expect to help people the first few times they need to use the form. Provide reminders throughout the year to use the work item if people forget to use the database.
Practice, play, and learn. Ideally, find an image of Microsoft Visual Studio Team System 2008 which includes Team Foundation Server to use. We then used Microsoft Virtual PC (allowed us to "play" the image) and Visual Studio power tools, which gave us the Process Editor to make changes. This completely changed our project for the good. When Ellyn, found the image, she was able to practice creating and modifying our work item in a safe environment. We didn't import our work item into our live environment until we were really, really ready. And by then, we had completed a lot of testing so we knew the work item was close to where we wanted it to be.
Ask questions. We asked many questions - questions about TFS, about work items, about customized reports, about security permissions, and about what we wanted from our work item. We even asked many a questions of Google. Lots of people use TFS and provide answers on the interwebs. All you have to do is ask. We even had meetings where we had more questions than answers. It also never hurt just to ask another person in our department if they knew anything about an issue we were having. If we ran into a roadblock, we were directed to another person and to another person until the issue resolved. You'd be amazed what you can learn and accomplish when you ask questions.

Up Next... Ellyn closes the series of blog posts with a discussion of what's next. Where do we go from here?

Using Team Foundation Server to Create a Customer Contact Database: the Testing Phase (part 3 of 5)

2010-03-02T18:00:00Z

Continuing a series of five posts on a project, began in 2008, by the Blackbaud Documentation team.

By: Georgeanne Cheng, Ellyn Hassell, and Lindsey Robbins

In our previous post, we discussed the ins and outs of creating a work item form in Team Foundation Server. We now had a working form and a sandbox project in TFS, which was basically a place where we could play around before we imported our form into the real TFS environment. It was time to move to the testing phase.

Before we began, Ellyn created a test plan so that we could easily compare our results. According to the plan, we would create new contact work items; link items to related work items; search for items based on information in the fields; export multiple items to Microsoft Excel for editing, then import the updated items back into TFS; and, finally, test the team queries we created. Ellyn will discuss the queries in a future blog post.

We tested each item in the plan and jotted down issues, best practice ideas, and any thoughts we had while completing each task. Then, we compared notes and tweaked the form based on our testing results. For example, we moved certain sections and tabs around and provided defaults for specific fields to make data entry consistent, as well as faster and easier for our team members.

During the testing phase, we finalized a workflow for creating work items, determined best practices for working with the form, and decided what information to include in our pre-defined queries and reports. It was interesting to see that, even with all the planning and preparation, there were still things we had not accounted for or that just didn't seem to work well when we actually started entering data. After a few more rounds of polishing, it was time to import our work item into a real TFS project and start adding records.

The form was now in place, but we still had to create instructions about how to use it before unveiling our new work item to the team. This is where all the documentation we had created along and along came in handy. We put together a series of wiki pages to explain the concept and workflow and to provide detailed instructions. We also documented exactly how we went about creating the form in Visual Studio's Process Editor so other team members could create new forms in the future. We were now ready for Ellyn to present the work item form to our team.

Up Next... Lindsey shares our top ten best practices and discusses some of the lessons we learned.

Using Team Foundation Server to Create a Customer Contact Database: the Nuts and Bolts of a Work Item Form (part 2 of 5)

2010-02-23T18:00:00Z

Continuing a series of five posts on a project, began in 2008, by the Blackbaud Documentation team.

By: Georgeanne Cheng, Ellyn Hassell, and Lindsey Robbins

Once Ellyn and Lindsey decided that TFS was the best tool to use for the job, the next step was to determine how we should get started. TFS is an incredibly robust product. Here at Blackbaud, we use it for source control, project tracking, reporting and other tasks related to software development. For our customer contact project, we were interested in the Team Explorer view—or, more specifically, the Work Item node in this view. From Team Explorer, you can access different projects and manage tasks, or work items, related to each project.

For example, when testing a new feature, a Quality Assurance analyst finds a misspelled word in a help topic I created. The analyst creates a work item and assigns it to me. I now know there is an issue that I need to address. After I make the correction, I explain in the work item that I updated the help topic and assign it back to the analyst, who can test again to make sure I fixed the problem. We now have an audit trail for my spelling error.

We wanted to use the same idea for documenting our interactions with customers. By creating a special work item, we could document that an interaction occurred and provide details about the meeting, phone call, or other method of contact. Then, if the interaction required a response on our part (like my spelling error required a response), we could document the steps we took to meet the customer's needs. In my spelling error example, I assigned the work item back to the analyst to show that I had corrected the problem. For our customer contact work item, I would follow-up with the customer and close the work item.

So, we knew what we wanted, but we weren't sure how to get there. How do we go from a regular work item and workflow to one designed for customer interactions?

Create a game plan and determine what information we really need. To do this, the three of us had several meetings to decide on the fields to include on the work item form. We also tried to anticipate how we could use this form with other software applications. For example, can we integrate our form with Microsoft Outlook (email, calendar, or tasks)? Can we import survey data we collect with a third-party tool into TFS? TFS integrates with Microsoft Excel, so how do we use this to our advantage?
Talk to the experts. There were already several people at Blackbaud who had either had TFS training or who had worked with it enough to be very proficient. Ellyn and Lindsey set up several meetings, either for our group or one-on-one, so that we could ask questions and find out the best way to go about creating a form. It was through these contacts that we found a number of online resources and tools that helped us get started.
Find something similar to use. We began by looking at the work item forms other Product Development groups had created, thinking we may not have to reinvent the wheel. Unfortunately, no forms met all of our requirements. So, we took our list of fields, reviewed the layout of existing forms, and came up with a basic design.
Learn how to create a form in TFS. This was the tricky part. Luckily, early in the process Ellyn discovered that Microsoft had an image with a three-month trial period that we could download (Go Ellyn!). This image included all the products and tools we needed to create projects and forms. If you are wondering why we couldn't do this with our corporate version of TFS, it's because we did not have the proper security rights to create or edit forms in a "real" environment—which is completely understandable. The image provided a safe and easy way for us to learn how to work with the administrative side of Team Explorer and test our ideas.
Research, research, research. This was probably the most time-consuming part of the project. None of us have a background in programming, so we had to search high and low for information about how to build work item forms. After reading numerous articles, white papers, user guides, forum posts, and blogs, we were able to export an existing work item form from TFS and tweak the fields and layout to meet our needs. To do this, we used Microsoft Visual Studio's Process Editor. Although you can actually edit the XML, this tool was far easier to use because we could do all of our editing on a form, meaning there was a graphical user interface (GUI) rather than a bunch of lines of code.
Practice, practice, practice. It was so exciting when we finally had a new form to import into TFS! After all that work, it was exhilarating to type text in a field, choose an entry from a drop-down list, or select a checkbox and actually save the form as a record.

Now that we had turned Ellyn and Lindsey's idea of a customer contact work item into an actual, working form, we needed to take it for a test drive. Actually, many, many test drives.

Up Next... We put the new work item through its paces.

2009 Documentation Survey Results

2010-02-22T14:00:00Z

The 2009 documentation survey has come to a close. We’ve been tracking the results and providing quarterly reports for nearly three years now. Over that time we’ve received some great feedback from our clients and incorporated numerous suggestions into the way we create and present our documentation. I’m also happy to report that clients consistently gave us high marks in the various categories we track.

Key Findings 2009:

602 total respondents, up from 284 in 2008.
Each quarter our statistical numbers stayed consistent.
Three years in a row, our highest overall category rating was Accuracy with a mean score of 4.27. Our lowest overall category was Easy to Understand with a mean score of 3.92. Our overall category ratings showed us that in each category we were meeting or exceeding client expectations.
70.9% of survey respondents found the answer to their question in the documentation (user guides and help files).
Of the 602 total survey respondents, 10 different products were represented.

Additionally, we began tracking user guide downloads with Google Analytics in April of last year. Downloads include our user guides, video tutorials, and print tutorials.

For Q2 2009 (Late April – June 30) we had 17,015 downloads from our User Guide pages.
For Q3 2009 (July 1 – Sept 30) we had 25,145 downloads from our User Guide pages.
For Q4 2009 (Oct 1 – Dec 31) we had 21,483 downloads from our User Guide pages.

Based on this information, we averaged approximately 8000 user guide downloads per month in 2009. Not bad.

We will certainly continue surveying our clients in 2010. In fact, we are currently in the process of giving our survey a facelift and revamping a few questions. We will re-launch the survey sometime in late March.

Using Team Foundation Server to Create a Customer Contact Database: an Overview (part 1 of 5)

2010-02-16T18:00:00Z

Introducing a series of five posts on a project, began in 2008, by the Blackbaud Documentation team.

By: Georgeanne Cheng, Ellyn Hassell, and Lindsey Robbins

Summer of 2008, as part of a team usability group, Ellyn and I (Lindsey) discussed ways to capture information from the many different ways we interact with our customers. We have an ongoing survey, receive email feedback, go on site visits, meet with customers when they come in for training, and more. We wanted to keep track of how often and what we were learning when we talked with our customers. Storing information in emails and Microsoft Word documents is adequate but there isn't any accumulation of data to create reports or analyze trends. We wanted a more complete picture.

We had an old Access database created several years ago to track customer feedback but it was barely used in the time since its creation. Theories why not? Well, for one it was buried on our local network drive in Microsoft Access. People forgot it was there because it wasn't very accessible. And number two, Access just isn't a tool we use on a regular basis. If it's not something you regularly use, it's easy to forget about. Plus, the tool was created to capture information about customer meetings and site visits but we receive a lot more information that needs to be tracked.

I attempted to use Microsoft InfoPath to create a web entry form for the database (more easily accessible) but I couldn't get it to work the way I wanted it to. I thought if I could create the form and post on our Microsoft SharePoint internal website, I could then tweak the database to fit our needs. However, I never got the hang of InfoPath. Perhaps if I had a lot more time to learn the program I could figure it out but discussing it with Ellyn, we still weren't sure the Access database could do all that we need, especially in regards to creating reports.

Instead, we discussed other tools we might be able to use. Unbeknownst to us, we were both thinking the same thing. However, it didn't surface until a week or so later during a conversation. We both wondered, why not use Team Foundation Server (TFS)? Our department had recently begun to use it and it seemed like the work item they developed for Quality Assurance wasn't too far from the type of form we would want for our documentation needs. And better yet? We could use the creation of the form to better learn about Team Foundation Server. Why Team Foundation Server? Well (1), it's a tool we knew we would soon use every day (we were in process of moving our documentation to this tool for its source control and versioning abilities). Also, (2) the way TFS works with Visual Studio and SQL Server, meant we could use this tool as a more powerful database than Access. We weren't sure if we would need to learn any XML at this point (because that's what the work item in TFS uses), but if we had to, this (3) would be great to learn. We didn't end up needing to learn much XML but it was a boost not a hindrance to taking on this project.

From Ellyn and I's first TFS conversation, we had no idea what we were getting into or all that we would learn in the process. At this time, we were also lucky enough to convince Georgeanne to join the project. Ellyn knew Georgeanne was perfect for this project. Not only was she interested in these types of things but she also brought a lot of experience and skills to the team. Georgeanne completed our project team trio and we began our work in earnest. As we went along we tried to stay focused and organized, hitting all the critical details and thinking through potential uses and obstacles to the work item before we introduced the tool to the team. In addition, I have to give extra credit to Georgeanne and Ellyn for being the workhorses and tackling the critical details in Team Foundation Server especially around how to create and import our work item. And, over the next few blogs, you'll hear from them and what they learned in researching and developing the custom work item in TFS. And then lastly, we'll blog about our best practices and what's next.

In retrospect though, I am amazed. What started as a speculative hope that we could use this robust tool later became a real possibility. We were fortunate to have some key discussions early on with some very talented people in Quality Assurance (Thanks Jason!). After a few trainings and encouragement, we realized not only would this project be a great learning opportunity, but it would also meet our needs for capturing customer interactions and more.

From start to finish, this project took some time but we met regularly and made steady progress even while juggling our own multiple projects. TFS wasn't the priority of our days but it was always there as something we were excited about. Personally, it's one of the most unique, fun projects I've had the pleasure to work on at Blackbaud. We hope by sharing our experiences and knowledge we can pass on some useful information for those looking to take on similar projects.

Up Next... Georgeanne discusses the creation of the work item form.

Putting the Pieces Together: Own Your Domain

2010-02-09T14:18:00Z

Communication is receiver-oriented, and to realize that is a step toward communicating effectively. As people, we constantly communicate with those around us - verbally and non-verbally - so it's necessary to maintain audience awareness as we interact. As technical writers, we are actually technical communicators, so similarly it's important to determine how best to present our content as we write. To do that, we first must understand the receiver.

Domain knowledge, or knowledge about the content area for which a piece of software is being designed, is a technical writing necessity. Technical skill and knowing how to use tools such as Adobe FrameMaker or SnagIt are just one piece of the puzzle. These technical skills, which we utilize to create our content, must be paired with domain knowledge to provide a complete and effective piece of documentation.

Some argue that industry knowledge can be more important than technical know-how (see myth number four of 14 Widespread Myths about Technical Writing). The basic claim is that if the proficiency isn't already there, a technical writer is sort of expected to be able to pick up on how to use content management tools rather quickly. However, if the domain knowledge isn't already there, to learn an industry (the technical writer's audience) to substantial depth would take much longer (reiterated in a post by Doug Davis). That is to say, it's more difficult to gain knowledge about the subject for which you write than it is to learn how to use the tools for documentation.

To place a personal example on the subject, I became a technical writer - as a novice in the field - about a year and a half ago. The technologies and tools our department uses for content management were new to me, but I was able to learn how to use them fairly quickly. The part I struggled with most, and am still honing every day, was developing the knowledge about the subjects and audience for which I write. I have gathered plenty of helpful advice, tips, and mentoring from my peers, but it was recently that I had one of my most valuable experiences yet.

I was lucky enough to participate in a client visit, in which a group of employees went on-site with real software consumers in our market. We interviewed staff members of different roles and positions, observed employees as they performed daily tasks, paying attention to their needs and how their current software does or does not accommodate those needs, and asked questions to further learn their business processes. Watching users, of every level of the organizational structure, really shed a light on who exactly I was writing for - what kind of person she/he is, what sort of tasks they perform most frequently, and what their end-goal is each time they use a feature in our software. Since being concise in our writing is key, this knowledge is highly valuable when determining what should be included in our documentation.

Through operational knowledge of a given subject or domain, you can more easily identify problem areas, or areas in which more attention should be given. If you know, or even more than that, understand your audience's goals and needs, you can build your content accordingly to add as much value as possible.

Starting from Scratch

2010-01-28T15:00:00Z

It's always an interesting time for those of us in user assistance when we're given a blank slate and told to document something new. You feel like it's a loophole in time. You get to start new and perhaps do things a little differently. It's a time to ask ourselves, how can we make our help better or how can we improve the style of what we write.

Many of us on our team have been doing that recently as we prepare to bring you new software over the coming years. It's a process we continually go through in the software world - improve and add more features. And whenever we improve or add more features, we create new documentation. It's a never-ending fun cycle (for the nerds, like me, who love writing user documentation).

I've been working on some new functionality recently. And in particular, I've been working on creating some visual representations of concepts in the new software using Microsoft Visio. It's interesting to say the least as I try to visually connect ideas that are interrelated in the program. However, drawing a few boxes on a page is not exactly helpful. Quite the opposite, I'm delighting in using skills I learned about in school with my experience documenting software the past four years. I like thinking about how you can take information you want people to learn and think about how best to teach. Some people need to see visually how different areas in the program connect. Some people need screenshots to compare what they see on the screen to our documentation of how it works. Some people just want the written instructions so they can follow 1, 2, 3. There are so many options for user assistance but choosing what works best is the critical part of truly helping users learn what they need to so they can perform the functions of their job and be efficient.

So back to these visios I've been creating. I get kinda goofy excited when I get to work on them because I get to jump back and forth from overview writing to supplementing that text with a visual concept. That's probably my favorite thing about software documentation - the interrelation between text and images. Or as we called it in school - information design. Everyone has his or her niche, but this is mine. I've always been a geek about learning and now I get to help others learn for a living.

Time will only tell if my work will help users. I'm realistic, it may not help all users, but if it helps some, then I'm a happy camper. When we officially publish the documentation, I'll be sure to do a new post and show you what I eventually came up with.

In the meantime, do you use visual concepts or diagrams in your documentation? Or, if you're a user, do you like seeing them and does it help you?

Envisioning the Future of Help

2010-01-21T14:44:00Z

I received an email yesterday about the changes coming to Microsoft Office 2010 and specifically a big kudos to their introduction of some new help techniques. Along the way, I have always felt Microsoft products introduced new ways of helping users. From that annoying paper clip guy (who we don't like to admit really did help us from time to time) to the right pane which allowed us to view a multitude of help information, to tooltips, and to the myriad of ways Microsoft embeds help in the program and doesn't just point you to the help file. Naturally, these have been cool ideas we've tried to emulate but we always wish we had their resources to pull off some of the more technical ideas. I'm not saying we aren't awesome, just that a company the size of Microsoft has infinitely more people, time, and money. However, envy aside, it's always important to have at least one company in your field introducing new ideas. And in the last five years, many new players to the user assistance field have given us plenty of ideas to pursue.

However, Microsoft's latest change in embedded help has me wondering how it will or will not change the game of helping users get the most out of the software. Game= key word. You see, in Office 2010 as I learned from ZDNet's Christopher Dawson, Microsoft is using their ribbon in the program as a training tool. With the ribbon, they are turning it into a game (Ribbon Hero) where you try to compete for achievements in the program. You can even connect your Ribbon Hero to facebook to brag to all your friends about how well you are doing. You earn achievements by learning how to use the program and all its features - an often critical point of Microsoft software (and software in general) is you don't use enough of the features to warrant the cost or upgrade.

The Office 2010 team leaned on the Xbox group to learn the motivational strategies and factors in console gaming. If people are so addicted to WoW, D&D, FF, PS3, Wii, Xbox, and Facebook games (mafia wars or farmville anyone?) would those same gaming strategies translate to productivity software?

It's an interesting idea and I'm on the fence. I like the concept of making learning more fun. Hence, the Fun Theory (an initiative from Volkswagen). See this great video on YouTube as an example.

However, while making learning more fun is good, I don't see people wanting to turn productivity software into a video game like experience. When I want to have fun I pop in Little Big Planet on my PS3, I don't open Microsoft Word to learn more features. After all, how you can you get the escape from life experience when you're opening up a program to do... work <<ugh>> .

Technical Writer is Lucky Number 13!

2010-01-13T12:59:00Z

CareerCast.com conducted a study on the top 20 and worst 20 jobs of 2010. Technical writer landed the no. 13 spot for top jobs of 2010. Other tech related jobs include Software engineer, Computer systems analyst, and Web developer.

For the full list of top 20 and worst 20 jobs of 2010 check out Reuters.

Technical Documentation Know-How

2010-01-04T15:40:00Z

Are you new to documentation and need somewhere to learn about where to start? Check out http://www.indoition.com/. They have checklists, links to various software and websites, and assist you on how to select your authoring, screen capturing, and screencasting tools. Overrall, this is a good place to get started (or freshen up) on your venture as a Technical Writer.

Policies and Procedures Gone Digital

2010-01-04T14:37:00Z

Do you remember when you first got your job and signed paperwork regarding policies and procedures? Some of you may have even had to sit through the sexual harassment video or re-enactment of sexual harassment situations. But did you ever have to watch a video about what your companies policies are?

Well, Telstra, an Australian Telecom company, created a video about their policies regarding the use of social media sites, for the world and their 40,000+ employees to view. You can view the video here.

I am all for moving forward and using new technologies to deliver information, on sites like YouTube and eHow, you can find tutorials on just about anything. Even here at Blackbaud, there are video tutorials available for our software, but there are just some things that I feel is better fitted on paper. What do you think?

source: http://mashable.com/2009/12/16/telstra-social-media/

Q3 Documentation Survey Results

2009-11-03T20:25:00Z

The Q3 documentation survey results have been compiled. Here are some of the key stats:

We received 183 responses.
For our five overall rating categories - Accuracy, Completeness, Easy to Understand, Accessibility, and Usefulness - the two most frequent ratings were a 4 and 5 (out of 5).
Our highest overall rating category was ‘Accuracy’ (mean 4.30).
Our lowest overall rating category was ‘Easy to Understand’ (mean 3.98).
86.3% of survey respondents access documentation often or sometimes.
47.5% of survey respondents prefer to access documentation as user guide PDFs online.

Additionally, we have begun tracking user guide downloads with Google Analytics. This quarter we had 25,145 downloads from our User Guide pages. That number includes our user guides, video tutorials, and print tutorials. The number does not include hits on our hosted BBNC help files, which we track separately by topic.

And last but not least, each quarter we enter the respondents of our survey in a drawing for a $25 Amazon.com gift certificate. The Q3 winner for 2009 was Heather Flynn of Olive Crest Homes and Services for Abused Children. Congratulations, Heather!

To take the survey (and be entered in our 2009 fourth quarter drawing), click here. It takes only a few minutes. To send us feedback about our user guides or help file documentation at any time, email documentationcomments@blackbaud.com.

Forget Best-Selling Audio Books, Listen to Our User Guides for Free!

2009-10-20T14:08:00Z

Did you know you could listen to our user guides read out loud for free? Well, if you have the free Adobe Acrobat Reader or even the full Adobe Acrobat installed on your Windows computer you have the ability to not only read our guides but listen to them as well. It's a little known feature that may be of use to you.

In Adobe Acrobat Reader, on the menu go to View, Read Out Loud. You can select to listen to the entire document or just the page you are on. Adobe uses the basic Windows voice settings so if you aren't able to hear anything, go to your Control Panel, Sound and Audio Devices, Audio tab. On the Audio tab, ensure you have a device selected for the sound playback.

If you want to adjust the voice or playback speed for the read out loud capability, go to Control Panel, Speech, Text to Speech tab. I personally went with Microsoft Sam on my computer, I like his deep monochromatic voice. If only they made a CP-30 voice.

User Guide Downloads and Survey Numbers

2009-07-15T15:06:00Z

In April of this year we started tracking the number of user guide downloads from our website. Using Google Analytics, we then filter the information by date range and/or product, depending on our reporting needs. I should point out that in addition to user guides, a ‘download’ could be a tutorial, quick reference sheet or video. Any type of help content we create and post on the User Guide pages can be included in the download count.

So how many downloads you ask? From April 28 to June 30 we had 22,862 downloads from our User Guide pages. That sounds reasonable to me. In fact, it sounds like a lot of traffic pulling down information from our User Guides pages, but we really don’t have any recent, reliable data to compare it to. I think we’ll just have to keep our eye on those numbers over the next few months before we begin to evaluate and gauge overall usage.

Survey Numbers
We received 182 responses to our Documentation survey last quarter, once again setting a new record in total responses. Last year at this time we were averaging between 50 and 75 responses each quarter. We thought the number would go up a little when we added the survey link to our AES help files, but we’ve seen a substantial increase. This is the third consecutive quarter that we’ve received over 100 responses. And even though it requires more time reviewing those responses, it’s a great trend, and one we would like to continue.

Before I forget, the 2nd quarter winner for 2009 is Kim Abel of the Desert Botanical Garden. Congratulations Kim.

To be entered in our 2009 third quarter drawing, complete our online survey. It takes only a few minutes. To send us feedback about our user guides or help file documentation at any time, email documentationcomments@blackbaud.com.