ISV Kaizen

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.

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.

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

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 »

As you may know, before I founded Indigo Byte Systems in 2004 I used to be a senior developer in a mid-size software development company. I dealt with various projects from hardware drivers, to Web applications, to distributed corporate systems. Nowadays, I also teach students the programming methods at the IT department of Samara State Aerospace University. So, I test and evaluate various software applications every day. I see that many programs by different authors have the same problem. That problem is GUI, Graphical User Interface. Designing usable and clear interfaces usually requires significant efforts and experience. Nevertheless, often I see things that authors may improve just in minutes and make their programs looking more professional and attractive.

That is why I decided to write a series of articles devoted to GUI quick improvements. In the first post I will write about how to position the GUI elements properly. As English is my second language I will follow “Less words, more pictures” principle in this post.

Continue Reading »

I have an idea which I would share. It’s a raw concept but I’m sure that you can polish it and use somehow in your business.

Remember the installers that show slides with software features and benefits during the installation process. I’m sure that some of your applications also have such processes when a long operation performs and user simply has to be watching the progress bar for several minutes.
Why not to show a user something else during this period of time? E.g. you may show a tip of the day, news (e.g. RSS feed), link to your site/blog, a marketing slogan, or even a banner.

How it differs from adware:
1. You don’t bother your user while he actually works.
2. You display the a plug only while the user is bored and awaiting for the end of long process.
3. You may display not only ad, but also something interesting and valuable for user.

Installers have been using this technique for a long time and I wonder if other types of applications can use this trick also. I think this technique may be used in applications that deal with huge data processing, conversion routines, model rendering, compilation, etc., i.e. where there are routines taking up to several minutes. Why to waste those minutes?

There are many situations when you have an application but there is no help file with it, and you have no time to write complete documentation yourself. At the same time you have no budget to hire a professional technical writer who can do this tedious work for you. The situations come up fairly often and the cost-effective approach is best.

Read our new white papers: Writing Cost-Effective Documentation for Software Systems

One of the purposes of continuous software improvement is finding and eliminating the barriers that get in the way of users when they’re working with your software. Let’s name the most typical barriers that make your software less user friendly.

Confirmation message boxes
The most annoying things in software programs are message boxes. The message boxes force users to make decisions which they don’t want to make: delete or save, continue or stop, accept or decline, etc. Revamp your program to ask users less questions. As an alternative, it’s better to provide Undo\Rollback\History function in your software.

Status alerts
If you use message boxes for status notifications like ‘Completed’, ‘Done’, ‘Stopped’ or ‘Error’ then you may consider making a log window or a status bar that will display these messages without forcing a user each time to click message box OK button.

Ambiguity in user interface
If user doesn’t know what to do after he has launched your software then it’s another barrier. Check if in your software there are enough prompts, hints and signs that would help a user to understand what he must do to complete his task in your program. A user must simply follow your logical directions to receive the required results. Don’t make him to think much.

Initial settings
Sometimes the software application asks a user to make some initial settings before he can continue working with the program. This is a barrier also. Again, ask less questions. Try to preconfigure your software for most typical situations. Don’t make user to think about if he needs to check this option or not. Assume this yourself and don’t bother him.
For instance, if your software requires another software or third-party libraries to be installed on user PC then don’t claim from user to specify the locations of those libraries. Make your program to silently find the prerequisites on user PC and silently keep the locations in the program settings.

Software restart or computer reboot
Personally, I hate when a program tells that I must reboot my PC before the changes will take effect. I have a dozen of applications running and I don’t want to close and later to restore them all just to try another utility. I usually choose ‘I will reboot my PC later’ and may then even forget about the new installed software. This is a serious barrier between the program and a user like me.

Well, I’ve briefly mentioned just the most common examples of barriers that must be removed from any software or at least their presence must be minimized. I hope I’ll return to this topic in future and will expand this list. You are welcome to post your examples in the comments.

Kaizen is all about continuous improvement. I’d like to acquaint you with a tactics that I use to find out what else may be improved in our Dr.Explain software and other our products. Besides feedback from users, which is very important of course, I use a trick that I call ‘A Saturday Newbie’. The tactics is rather simple but very effective.

Once a week, usually on Saturday, I remove our software, Dr.Explain, from my computer completely, i.e. program files, registry entries, and installed files. Then I go to the product’s website and from this moment I try to act as a surfer who has absolutely no idea what is the Dr.Explain software. I read the software description on the web site, explore samples, online help, and use cases, read reviews and testimonies. I ask myself: “Do I need this?”, “Will it work on my PC or Laptop under my OS?”, “How much does it cost?”, and other important questions. I look for the answers on the site. If I fail to easily find the answers on the website then I tell myself: “Dennis, this must be fixed asap!”

After the initial acquaintance with the product overview on the website I proceed to the download section (if I’ve decided that I need this product ) and try to download and install the demo version. So, I check if the download link is easy to find and if it works.

Now, the most interesting part begins. After the installation, which should be completed smoothly, I run the application and try to figure out how this pile of buttons, menus and controls can make my life better.

What should be my first step? Which button to press first? How to start a new project? Is there a sample? I ask myself a dozen of questions. If the answers aren’t obvious then I say: “Hmm, guys, you must make this more clear if you want my money.” Seriously, I try to forget that I’m a developer of this software and try to find a hint for my first action. Is there such hints in your product? This may be a wizard’s window, a pop-up ‘Click me!’ balloon, or even a simple ‘Start’ button (You know what I mean).
The same rule must work for all my further actions. After each step in the program I look for another clue: “What’s next?”. If I have no idea what to do next after a certain step I make a record in our To-Do list to make the transition from ‘Step M’ to ‘Step N’ more intuitive and transparent.

The main purpose of ‘A Saturday Newbie’ tactics is not finding bugs, but finding barriers that get in the way of a user when he tries to solve a certain problem with our software. Every time a user launches our software, Dr.Explain, he has a different purpose. Same here. Every time I act differently. Sometimes I act as if I need to create a new help file from scratch. Sometimes - as if I want to open an existing project made in the previous version of the program and to export it into CHM or HTML. Sometimes - as if I need to merge several existing projects. I play as many parts as I may realize. BTW, analyzing user feedback helps find out how people use the program.

Just a simple example, the Dr.Explain requires the Microsoft HTML Help Workshop to be installed on user computer for compiling CHM files. In the early versions we forced users to manually specify the path to the Microsoft HTML Help Workshop folder before enabling CHM file creation. That was a true barrier. Currently, Dr.Explain automatically detects the path to the Microsoft HTML Help Workshop on user computer and doesn’t bother users with this question anymore. The barrier was eliminated. During every testing session I find more new barriers that none of the developers or testers has seen before. Forget everything that you know about your application. Forget that you are a developer of this software and, I’m sure, you will also find many barriers in your program.

To reach the maximum effect you must not only play different parts but play them on different stages as well. Change your environment for every testing session. Use different OS versions, screen resolutions, hardware environments, and user privileges. Run your software both in registered and unregistered modes, and with all possible licenses (Free, Regular, Professional, etc.). Each environment modification may cause new barriers for your software users. You must find those barriers and eliminate them to make your software really easy to use and intuitive. I hope that ‘A Saturday Newbie’ approach will help you to do this.