ISV Kaizen

[Editor’s Note: This post comes from Craig Prichard, a Technical Communicator. He has provided beta and usability testing for Dr.Explain, wrote the sample project (GUI) that is distributed with the latest version, and is the “voice” of this video.]

Dennis has generously provided me enough rope to hang myself. I hope to make a hammock and just hang out a little instead. We’ll see.

This post comes from the perspective of a Technical Communicator. 25+ years of software development, business analysis, beta and usability testing, and technical communication in its many forms have confirmed to me that these principles are universal to anyone faced with creative problem solving.

Technical Communication (TC) has many facets but at the core of every effort, deliverable, meeting or other task is the challenge to solve a problem. Whether the task is to write or otherwise communicate an explanation of how to do or use something, convince a client to use your services, resolve an interpersonal conflict between yourself and someone else or between others, or determine the best content delivery medium for a specific scenario, you will always have two challenges: clearly identifying the problem and producing a satisfactory solution to it. Sometimes the problem is cognitive, e.g. learning and explaining. Sometimes the problem is emotional, e.g. conflict resolution. Sometimes the problem is spiritual, e.g. conflict of interest. Sometimes the problem is physical, e.g. constrained by available resources. And most of the time the problem is a lovely blending of components that taxes body, soul, and spirit. The remainder of this article will be based on two (1) assumptions (I know what they say about “assume”, thank you):

1. You have identified the problem. This would make a good topic for another post.
2. You believe a satisfactory solution can be achieved. I believe there is an achievable satisfactory solution to every problem, which would make good topic for another post.

How do I get from point #1 to the end of point #2? I don’t have any idea how to solve the problem. Or, more likely, I have some idea of how to solve the problem but there are pieces missing that need to be filled in.

First, let’s modify our taxonomy. Do not refer to this as a “problem” any longer. It may seem trite or contrived to call it a “challenge” or “opportunity” when the terms are synonymous. But actually they are not. Would you refer to training for a 10 KM run as a “problem” or a “challenge”? It’s a matter of choice. You choose to participate in a 10 KM run and know that without training first, your results will likely be less than satisfactory. You refer to the effort with a term that, in your mind, is less negative than “problem”. For motivation sake you choose a term that encourages rather than discourages. For motivation sake you need to think of the TC effort now facing you in terms that do not discourage. One reason you might be having difficulty crafting a solution to the challenge is that your mindset regarding it is unnecessarily negative. Turning the corner from “Woe is me” to “I shall overcome” (thank you Martin Luther King Jr.) can help the creative juices to flow again.

Challenge Types and Suggestions:

• Cognitive: I have the problem of learning a new program and writing a Getting Started Guide for it. No, I have the opportunity to expand my repertoire of computer programs AND demonstrate my excellent communication skills in producing a quality Getting Started Guide.
• Emotional: For the next project I’m paired with the most obnoxious team member in the group. No, I have the opportunity to combine my expertise with another team member who, while challenging to work with, still have valuable contributions to make. That which does not kill me makes me stronger.
• Spiritual: The changes to this policy manual are going to make people around here upset and might cost some their jobs if they don’t change before it goes into effect. The problem is I can’t talk about it. No, the challenge is I need to honor my professional commitment to non-disclosure and confidentiality, remember that I don’t make the policies, and hope the example I set will help others by exemplifying corporate policy.
• Physical: The problem is the video is too large for web-based distribution. No, the challenge is to either reduce the video file size or modify the distribution mechanism in some way.
• Blended: The boss wants another chapter in the Training Manual ready for review Monday and I promised my wife we would take the kids camping this weekend. No, the challenge is to manage my time and resources as efficiently as possible and insure my boss understands what reasonable expectations are.

My first point is about perspective; having a perspective about the challenge that doesn’t drain you of confidence to overcome it. The next point is also about perspective; looking at the opportunity to see what it is and what it isn’t. When I need to produce a deliverable that similar to numerous deliverables I have produced in the past, there is little need for creativity beyond the content itself. It’s when the deliverable is different in some way that the need for creativity arises. Understanding what is different is key to focusing your creativity productively. This is “thinking outside the box” and critically important in sparking creativity:

• Do I have all the facts and understand the scope? If I don’t think so I should gather the information I need from wherever or whomever I can?
• Have I discussed the challenge with stakeholders, knowledge experts, subject matter experts, or any key personnel involved in providing input to my efforts? Have they offered suggestions, no matter how ridiculous, to include in my pool of possibilities?
• Have I done some brainstorming, alone or with others (preferable) to fill my pool of possibilities? Did we step far enough back to allow the ideas to fly well beyond reasonable and practical? If one (1) in a hundred ideas is good, then I should accumulate several hundred ideas so I have a couple of good ones to evaluate and pursue. Ask any of the companies I do regular beta and usability testing for and they will report that my enhancement suggestions list is usually massive and often borderline unachievable in the extreme. Why do I continue to pour in suggestions when most are ignored? Two (2) reasons: first, I leave it to them to decide what is good and what is stupid, and, second, sometimes even stupid can lead to good. A stupid suggestion might spark a discussion leading to something valuable.

Challenge Types and Suggestions:

• Cognitive: The Getting Started Guide needs to fit on a single sheet of paper. Has the content been edited to be clear, concise, and complete? Could sentences be turned into bullet points, paragraphs combined, smaller headings employed? Does it have to be 8.5×11? Could it be 17×11 folded? Could it be rendered in a smaller font size, with fewer images and smaller margins?
• Emotional: The team member will not listen to any of my suggestions. Can I learn to communicate my suggestions in a way that doesn’t cause a defensive reaction? Can I accept the team member taking credit for my suggestions?
• Spiritual: The boss wants to include a paragraph from an uncited source. Does my boss understand what plagiarism is and how strongly I oppose it? Do I understand why he does not want to cite the source?
• Physical: The video resolution must remain high, stream, and start playing within five (5) seconds. Do I know what the latest compression technologies are and how to utilize them? Could the videos be split into shorter segments?
• Blended: The deliverable must be produced using a product I am unfamiliar with. Am I constrained to create the deliverable using this product or am I constrained to generate a specific target output that this product produces? Possibly your tool-of-choice will be acceptable if it produces the required output type. Or maybe, for archive purposes, the content can be imported into the required product at the end of the development cycle.

Next, at a more practical level, am I as prepared as I can be to be creative right now?

• Am I getting enough regular rest?
• Am I eating healthy regularly?
• Am I distracted by challenges outside the professional context that are demanding attention?
• Would a brisk walk, some other exercise, or just some calisthenics around desk help get my heart rate up and blood flowing?
• How about snack to quiet my stomach and boost my energy?
• Does standing up, pacing around, squeezing a stress ball, chewing gum, playing ping pong or some other physical activity help my focus?
• Is there someone I can talk to right now to get a fresh perspective, brainstorm with, or engage for a few minutes?
• Is there some other creative activity I can do for a while to take my mind off this challenge, e.g. cooking, musical activity, other hobby activities? Often when you engage a different part of your brain it will be easier to return to the challenge with a fresh perspective.

Here is a recap of ways to help the creative juices flow:

• Power: Don’t give the challenge power over you by thinking of it in defeatist terms. Keep a positive perspective. A solution will be forthcoming.
• Perspective: Turn the challenge over, inside out, upside down, and sideways. Changing your perspective might reveal something previous hidden from view.
• Practical: Is this machine; my body, soul, and spirit, ready to face this challenge?
• Ask for help. Discussion sparks inspiration. You can quote me. And you can contact me if you want too. I love a challenge, an opportunity to kick a problem so hard its mother will cry out.

There is no new research or startling information here. You know all this. But I hope that by putting it together as I have done, you will have greater ease in diving into, uh-oh, what’s about to walk into your office…

As always, your feedback is appreciated.

Craig Prichard
Technical Communicator
craig dot prichard AT gmail dot com
http://members.shaw.ca/craig.prichard

This post is a short list of basic rules for those who has recently signed up for Google AdWords account and doesn’t want to waste much money for learning curve.

Please consider the advice below with “for the first time” remark.

Focus on high quality traffic first

• Turn off Content Network advertising
• Allow only English language in targeting settings.
• Allow only USA, Canada, UK, Germany, Australia, New Zealand, and other “potentially profitable” countries (Nothing personal, just cold statistics).

Differentiate your ads

• Divide your keywords into several campaigns and groups by some syntax or semantic attributes. This will allow to create more focused ads for each group.
• In each group create two different ads with equal rotation probability.
• Constantly monitor those pairs of ads and replace the “weakest” one (with low CTR and conversion) with a new ad. I.e. test and look for the most effective ads for each group.
• Test various modifications of ad elements: URL, punctuation, caps, word order, etc. E.g: www.ProductName.com or www.productname.com or productname.com or ProductName.com; website or Web Site or web-site; and so on.
• Include search keywords in the text of your ads. Google will make them bold in search results and therefore your ad will be more visible among your competitors.

Improve your campaigns

• Try to increase bids for a couple of the most “profitable” phrases to improve their positions. But be careful and constantly monitor the effectiveness of this approach.
• Analyze your web logs, look for irrelevant queries and add them to the negative word list not to display your ads for them. Here is another good idea how to build negative word list

Start little and look what happens. Once you feel that you have full control and understanding of how Google AdWords works then you may turn on other countries, languages, campaigns, and ads.

Google AdWords is not a rocket science but it requires your attention and constant control to get maximum ROI out of your budget when you’re getting started.

This is a short and simple plan for quick testing final release of your software application before making it public. Just not to overlook something trivial but very important.

Texts

Spelling: Check all text labels, menu items, hints and messages for typos.

Version: If you don’t increment your version or build number automatically during compilation then don’t forget to change it manually before final compilation.

Copyright: Check if the copyright year is the same as the current year.

User Interface (GUI) appearance

Large fonts: Test your application with Large Fonts (120 DPI) set in Windows display settings. Are all controls properly aligned and visible?

Different screen resolutions: Try your software under different screen resolution. Start with 800×600.

Positions: Check if all controls on your forms are positioned properly.

Icons: Test your application icon in all common sizes and color depths: 16×16, 32×32, … 16 colors, high colors, …. Does it look clear and smooth?

Basic operations

Keyboard support: Many people prefer keyboard to mouse. Is your application keyboard-friendly?

Tab order: Recheck the tab order of your controls. You may break the right sequence during GUI redesign.

Hot-keys: Are all common hot-keys supported?

Hot-keys activity: If some operations in menu or toolbar are disabled, are the corresponding hot-keys disabled also?

Double clicks in lists: In some forms, if you ask users to select a list item then check if double click works like single click+OK.

Data entry and storage

Editable drop downs: If you ask users to select a predefined value from a drop down list (combo box) and you allow only options from that list then you must check if the drop down’s edit box is read only.

Spin box and sliders limits and steps: Recheck all spin controls and sliders for valid minimum, maximum, and increment step values.

Spin box arrows: Verify if Up arrow button in spin box increases the value and Down arrow button decreases it, not vice versa.

Data type mismatch control: Check what happens if you enter unexpected values in data input fields, for example, a character string in a numeric field or a negative number in a field for positive numbers only.

Long strings: Enter very long strings in data fields and test how your software will handle it.

Empty strings: What will happen if user leaves some important fields unfilled? Will your program continue working correctly?

Clipboard operations: Does pasting objects of different media types from clipboard work properly in all fields? What happens if an image or rich formatted text is pasted in edit field?

Weird characters: Test if your software works and data remains valid if there are unexpected characters in input strings or files, e.g. new line character, tab, diacritic symbol, copyright sign, non printable characters, etc…?

Unicode and multi-byte languages support: Will non-English people be able to enter data in national languages and encoding: Arabic, Hebrew, Hieroglyphs, Cyrillic, Greek, …?

Local formats: Check if your software works correctly if user has different date, time, currency or numeric format: e.g. dd-MMM-YYYY instead of mm/dd/yy, or nn,nnn.nn instead of nnnnn.nn.

Debug options

Debug mode: If you develop in MS Visual Studio, for example, then don’t forget to turn off the Debug mode before final compilation and test your application built in Release mode. Some bugs, like memory buffers overrun, may appear only in Release mode.

Debug logs and dumps: Don’t forget to turn off all debug log or trace files.

Debug messages and alerts: The same here. Turn off all debug message boxes and alerts.

Foo data: Change all “foo”, “John Smith”, “Preved medved”, or “Loren ipsum” data to blank or actual values.

If you have ideas about other important points to check then post them as comments please.

This post is written by our special guest, Nikolay Tyushkov.
Nikolay is an owner of Softvoile. The most known software titles by Softvoile are Flashpaste - an utility for managing and quick pasting text templates, and Clipdiary - a free utility for keeping the clipboard history.

As a veteran of ISV business, Nikolay has great practical experience he would like to share with colleagues. Today he unveils 7 steps to speed up software technical support tasks.

If you develop and sell your products then you are sure to have a lot of users, and … a huge number of questions to your technical support.

It’s an infinite chain of similar questions and standard answers - “Why didn’t I get my registration key?”, “How do I move my data to another computer?”, “What button should I press to get this thing I see in the picture?”, and many others repetitive inquiries.

Regardless you have FAQ section in your help file or on your website you have to answer the same questions every day. Unfortunately, it is impossible to get rid of boring mechanical work, but you can considerably speed it up. Similar questions mean standard answers. Let’s see what can be done about it.

1. Start creating a database of your standard answers. It is the first thing you should do. For example, if you are telling a user how to register a program then enter the answer into the database at once. When you are writing an instruction on some feature in the program, add it to the database as well. Believe me you will have to answer the same things more than once.
2. Write in the most general way. Write not as if you were answering a specific question from this particular user, but as if this answer satisfied everyone who would ask similar questions.
3. Make the description as detailed as possible. If you want to tell a user how to select a checkbox in options, also write how to open the dialog with these options, how to find the necessary checkbox and what it will result in. It will reduce the number of clarification requests and will save you lots of time.
4. If you have several products, try to avoid product names in common phrases. For instance, in a message about resending the registration key, write the answer template so that it can be used for any of your programs. Or you can better use a program that allows you to insert text macros.
5. Organize your answer templates. Put the general phrases in one category, registration questions in another category, problem solutions in still another one …
6. Store your answer templates in a special program developed for this purpose that can paste the template text into the any application practically easily.
7. Use Hot Keys to quickly insert the template text in the answer. Using hot keys rather then clicking through many menus will bring your productivity to a new level. You will be able to easily reply to message with one hand. What can be easier?

All these important points can be easily achieved with a special tool for pasting text snippets, Flashpaste (www.flashpaste.com ).
Flashpaste offers the complete set of features you need to reply your support messages quickly: text categories, hot keys support, plain and formatted text with full Unicode support, macros for inserting timestamps, substitution macros, database sharing among several employees and a lot of other useful functions. Also, Flashpaste will be useful for everyone who works with texts a lot: software developers, web designers, technical writers and translators.

Thanks for sharing this list, Nikolay!

The software improvement advice, techniques and ideas that I post here are taken from our real practice. I try to keep this blog practical and hype free. This post is a rare case (the previous one was about 9 months ago) when I’d like to tell a little about our own products.
During the recent months we have been working actively to make new versions of our existing products and to develop a new product as well. Recently we have released two new products.

Dr.Explain 3.0

Dr.Explain v.3.0 ( http://www.drexplain.com ) is an innovative software documentation tool. Thanks to unique technology, with Dr.Explain you can produce attractive and professional looking help files just in a few hours, not in days.

The Dr.Explain captures windows, dialogs, and forms from live application and web pages, makes screenshots, and automatically adds interactive references to all controls. You have not to spend hours annotating your software GUI. Focus on your content - Dr.Explain will do all the tedious work for you. The program can produce CHM, RTF and HTML help files with annotated screenshots, live menus, cross-references, and navigation from a single source file.

What’s new in v.3.0

• The new capturing engine captures and automatically documents windows, menus, GUI elements, web pages, and even flash applications
• Revamped text editor allows pictures, tables, lists, fonts, multibyte encoding, RTL mode, etc…
• Enhanced topic management supports topic statuses, marking and locking\unlocking
• Lots of other improvements including optimized export routines, Google sitemap generator, predefined macro variables, and many more improvements and tweaks.

The new version download: http://www.drexplain.com/download

TBS Cover Editor

TBS Cover Editor ( http://www.trueboxshot.com ) is a full featured software box cover creator with 3D rendering and template library. We accomplished the project in partnership with True BoxShot Software.

With the TBS Cover Editor you can create your 3D box shot design in a single flat worksheet. Say goodbye to separate designs for each side; no more design slices in many image files. The single-sheet concept of the TBS Cover Editor allows you editing of all box sides on a single screen. The real time 3D preview immediately shows how your 3D box shot output image looks like without switching between different windows or applications.

With the TBS Cover Editor no additional expensive third party tools are required. The program supports all the steps of box shot creation: from drafting and design, to 3D scene setting and image rendering. You can create professional-quality 3D box shots with no extra expense in a single program. The TBS Cover Editor comes with a brilliant collection of software cover design templates for various types of software. You can make a box cover in less than two minutes.

The TBS Cover Editor has a powerful rendering engine that produces realistic 3D box shots by applying original 3D rendering and ray casting algorithms. Your every box shot will look as if it is made by a studio.

More details: http://www.trueboxshot.com

Both these products will automate the most tedious and time consuming routines of your software business – software help and documentation writing, and graphical design. The Dr.Explain and TBS Cover Editor will help you present your software product in a professional manner with minimal efforts. As a software vendor you may focus on your business growth and leave the dull operations to the specialized systems.

How to stuff your software product website with content attractive for search engines? What to write about besides the product features, download and order pages, and contacts? Here is a brief list of ideas to get started.

1. Press release archive
2. Product news
3. Blog
4. FAQ & How-To
5. Knowledge base
6. On-line forum
7. Product live tour or demo
8. User testimonials
9. On-line manual
10. Trouble shooting articles
11. Product use cases
12. Sample project list
13. Freebie add-ons
14. Industry statistics and news overview
15. Periodical research reports
16. White papers
17. On-topic articles
18. Press kit
19. Specials and discounts
20. Awards and in-press reviews
21. Review of complementary products and services
22. Product comparison charts and tables
23. Your interview to somebody well known
24. Your bio or your company profile and history
25. Site map

Recently, we’ve published Dr.Explain v.3.0 beta for open beta testing. This is a major version update and we added a lot of really cool but complicated (for programming, not for users) features. So, we have to run comprehensive tests before releasing this update officially.

In this post I’d like to tell briefly how we run the testing process for the new version. Currently, we have not an army of QA specialists and dedicated testers so we use our team internal resources and the kind help of external beta testers.

Building a database of beta candidates

Every time I receive an e-mail with a support request, issue report or even uninstall feedback I wonder if this person could help us with testing of further versions. I use the following criterion for including him in our beta tester database:

• A user directly mentions that he wants to participate in beta testing of new versions
• A user actively suggests new features and improvements
• A user asks for a feature which is under development in the upcoming release
• A user has a rare hardware\OS\localization environment

If the user meets one of this criterion then I include him in the database. I try to keep the database up to date and relatively short - about 50 beta testers. I use Group Mail for managing the database and for bulk sending e-mails to testers.

Alpha version testing

Once the alpha version of the program is ready we send it to several most active users (addicts and evangelists) personally. At the alpha stage the program is usually quite rough and has bugs or “foo code”. Those selected testers tell if the new features are useful and well designed from their point of view. After this step we still can significantly modify some functions and parts of the program.

Beta candidate in-house testing

Once the beta candidate version is ready we spend several days for active testing inside the company. The best practice is involving people from other project teams. They have a fresh view and usually find lots of issues that were overlooked by developers. At this stage almost no new serious functionality is added into the version.

External close beta testing

After the internal testing and fixing, we build a first beta version for external testing. We upload it into the password protected section of the web site and create there a page with release notes and link to the file. That’s the time to use our beta candidate database. We send out invitations to participate in close testing of the product. We provide testers with login\password to enter the protected section of the site and to download the beta version of the product.

On the beta testing page of the website we write the following information:

• “As is” and “limitation of responsibility” disclaimers
• “What’s new in the new version”
• Contact information for sending test reports
• Download link to the latest build
• Release notes (changes log) for every beta build that we have published

Now we can update our tester database as well. After the bulk e-mailing, I remove records with bounced e-mails and with opt out responses.

Since that moment we start gathering feedback form beta testers. We upload new builds with fixes every a couple of days. About once a week I send invitations to beta testers to re-download the latest beta build. During the whole testing period I analyze web logs. Because all testers have unique logins I can see what latest build was downloaded by a certain tester. I record this information in the beta tester database as well. In the end of the beta testing I remove the records of testers who has never downloaded a file or, for example, has downloaded it only once and sent no feedback.

During the the close beta testing almost no new serious functionality is added into the version, only fixing and polishing.

Open beta testing

After we’ve almost stopped receiving the bug reports (the flow of feature requests will last forever ) we create the final beta build and publish it on our web site along with current version release. On this step, it’s possible to announce the availability of beta version among other users, on appropriate forums and blogs to attract as many people to beta testing process as possible.

It’s better to make a special section devoted to beta version on your web site to publish new build announcements, release notes and testing progress status.

During the open beta testing no significant changes should be done and all changes must be done very, very carefully.

Once you feel that everything seems OK with a new build - publish it as official release and start developing the next version.

Another interesting article on beta testing process:
How To Run A Beta Test… Or Not?

BTW, I invite you to participate in our public beta testing and to try the new Dr.Explain v.3.0 beta

There are problems in your software!

Otherwise your “demo installations / orders” ratio must be 100%, is it? If it’s 100% don’t read this post and write your own one about how you achieved this.

People are lazy and they will hardly write you by e-mail about problems they have with your program. They likely will remove your software from computer and will start evaluate a competitor’s product. The only chance to receive feedback from such users is to grab their attention during uninstall process.

There are many posts and discussions about how to properly implement the uninstall feedback. I’d like to write about our own experience. This is how the uninstall feedback is made in Dr.Explain - a rapid help authoring software.

Our setup program is made with Inno Setup.

We simply added the following code in the [code] section of .iss file:

[Code]
…
procedure DeinitializeUninstall();
var
ErrorCode: Integer;
begin
if MsgBox(’Why are you removing ProductName software? ‘ #13#13 ‘Would you like to answer, please?’, mbConfirmation, MB_YESNO) = idYes then
ShellExec(’open’, ‘http://www.yourdomain.com/unistallform.php’, ”, ”, SW_SHOWNORMAL, ewNoWait, ErrorCode);
end;

As you see, this hook opens a web form on the product website in browser. Many users don’t like when applications run browsers without their confirmation. So, we have to ask first if a user wants to open the uninstall feedback form.

This simple trick helped us gather valuable feedback from people and even to close several sales with those initially “unhappy” users.

Below there is a couple of related links about other ways of implementing uninstall feedback in Inno Setup:
More proactive way to force the user to write the feedback
Uninstall Survey plug-in for Inno Setup

Happy New Year to everyone!

It’s 2008! Have you updated copyrights?

In this post I continue writing about some simple practices that will help you quickly improve your software GUI. In the first post I wrote how to position your GUI elements properly. Before I started to write this post I had been thinking how to name it. I’m not writing a comprehensive guide on usability and user interface design. I’m simply writing my observations and thoughts about some practical aspects of GUI design. It’s hard to divide my advice into exact categories with distinct names. I named this post “Assistance”, because I will write about some tricks that will assist users to feel comfortable with your software.

When user works with your software he needs just a limited set of essential functions and, in the same time, he wishes all important functions to be easily accessible. Therefore, as a designer you must keep minimal both the number of visible functional elements and the number of mouse clicks or key pressings to perform an action. Let’s look at the examples.

Continue Reading »