ISV Kaizen

In this short post I’d like to share a real case of user interface improvement that we implemented in the upcoming release of the Dr.Explain 4.0.

In previous releases of the Dr.Explain we had a problem - much of screen space on the top of the application window was not used effectively.

Before (old versions of the Dr.Explain):

We reworked and united the toolbar and tabs to eliminate the unused space. Here is a solution:

Now (Dr.Explain 4.0):

With the new design users have more space for work, not for application buttons.

Check if your application interface has unused areas that might be used for real work.

Does my application need a colorful bright interface with amazing icons, animated skins and cool sound effects?

First, think about how much time does an average user spend working with your application per session and what does he use it for. If user spends more than 20-30 minutes per session within your application (which is not a game of course) then he might get tired of all these bells and whistles very quickly. The best GUI is the one you don’t even think about. It must be invisible and just lets get on with your job.

Think why Adobe Photoshop is gray like a dirt. Because, it must not divert designer’s attention while he is working with own image documents. Gray is one of the most invisible colors.

For example, we used this principle in our TBS Cover Editor - 3d box shot maker application.

Our first intention was to make a smashing GUI with the coolest effects ever. However, we stopped on a plain almost monochrome interface in order not to bother users with our coolness but let them fully concentrate on their box shots and cover designs.

Think if your GUI is invisible.

A pretty common question on software development forums:

Should I release my new product in July or postpone it for a couple of months?

I recommend to release your new software product as soon as possible to quickly test the product idea and to start communication with users.

July is a good time for pilot release also. Just make it soft and relatively silent. Don’t put much money in promotion and marketing. Your primary goal must be gathering as much feedback from users as possible. Put all your efforts into testing of all aspects of your new project in live environment: application, setup, website, order process, statistics collecting, support, feature request management, etc…

If you start now, you will have enough time to collect and to analyze initial feedback and to polish everything before majority of businesses gets back to work. Then make a second release in August or September. The second version will be more stable and tested, and likely even with several new features. Then, you may put more efforts and money into marketing and promotion of your product: post announcements, send press release to media, buy ad, and so on.

If you decide to split your software product into several editions with different settings then you will likely wonder how to name them. Naming software editions depends upon what do you offer and what do you limit in each edition. There are several common approaches in building editions:

• Functional limitation (F)
• Environmental or purpose usage limitation (U)
• Limitation of number of installations (N)

Here is a list of common edition names. The hints in parenthesis designate which of the approaches each name suits better.

Level 1
Junior (F)
Beginner (F)
Student (U)
Educational (U)
Light (F)
Lite (F)
Bronze (F,U,N)
Empower (F,U,N)
Starter (F)

Level 2
Standard (F,U,N)
Regular (F,U,N)
Intermediate (F,U,N)
Personal (U,N)
Home (U,N)
Silver (F,U,N)

Level 3
Advanced (F,U)
Professional (F,U)
Business (F,U,N)
Commercial (F,U)
SOHO /Small Office or Home Office/ (F,U,N)
Company (F,U,N)
Gold (F,U,N)
Mega (F,U,N)

Level 4
Deluxe (F,U,N)
Architect (F,U,N)
Site (F,U,N)
Enterprise (F,U,N)
Platinum (F,U,N)
Premium (F,U,N)
Exclusive (F,U,N)
Ultimate (F,U,N)

This list gives you an idea how to get started with your own software editions. Combine names from different levels to build your own successful product line.

If you know more naming examples then post them as comments please.

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 »