ISV Kaizen

If you have ever released an update of your software product then you likely faced the problem of notifying your existing customers about the update. In this post I’d like to give a simple yet very important advice how to notify your customers properly.

Releasing the upgrade is a very important task. After several months of development and testing you may get tired and miss some important details on the final stage - distribution and official announcement.

Here is a list of the most common issues that may happen during the release and reduce the effectiveness of your announcement:

There is a bug in your software
There is a bug in your setup utility
The download link is broken
Your server is unexpectedly down
There are typos and mistakes in your announcement text
… or else

You must detect the possible unexpected problems and fix them before all your customers have received the announcement message. The trick is easy - send your announcement by portions.

The first pilot portion of your mailing must be sent just to a few customers, about of 100-150 contacts. Those users must be as different as possible: from different countries, with different operating systems, corporate and home users, old clients and newbies, etc… Usually the first mailing to such small yet contrasting group of users allows detecting the possible issues in your release or notification. In the same time you won’t be overwhelmed with support request from thousands of disappointed people.

Wait for about a day for possible problem reports and initial feedback. If everything is OK then you may send another portion of mailings to about 5-10% of your customers. Wait for another day. If everything is OK this time then continue sending your announcement by portions of 15-20% with pauses of several hours between each session.

This simple approach will allow you to:

quickly detect the possible problems in your release;
keep the majority of your customers happy and properly informed;
save your support team from the sudden hurricane of the bug reports;
keep your mail server work load stable.

If you are serious about writing a good documentation for your software either with our help authoring tool - Dr.Explain, or with another one, then you definitely should subscribe to the following blogs on technical writing, software help and documentation authoring. To be honest I even included links to blogs of our direct competitors.

I say “Thank you!” to our fellow customer and partner Craig Prichard, a technical communicator, who gave me many new links for this list.

Cherryleaf Technical Authors’ Blog
A blog site from Cherryleaf, a technical communication UK company by Ellis Pratt. Ellis regularly gives comprehensive review of the industry news as well as practical articles on technical writing.

Harry Miller’s Technical Writing Blog
Harry’s blog contains not only written content about documentation, technical writing, and technical editing, but many podcasts as well.

HelpStuff Blog
A famous blog by Char James-Tanny (JTF Associates) about all aspects of helping software end-users.

I Came, I Saw, I Learned…
A blog by Kevin A. Siegel who has written more than 100 step-by-step computer training books and has been a software trainer for more than 15 years.

E-Learning, Moodle, Technical Writing, and Training
William Rice is an educator, trainer, and writer. Most of his posts are either articles or tutorials about his professional pursuits: e-learning, Moodle, technical writing, and training.

I’d Rather Be Writing
A blog about technical communication by Tom Johnson. Tom covers many topics from any kind of user guides and design documentation, to audiovisual tutorials and drawings, or other explanatory content that is of a technical nature.

Gryphon Mountain Journals
Ben Minson is a technical communicator. He creates documentation and training on applications that are produced in-house. Writing is what Ben does. He thinks that when he die, the mortician will have to pry the keyboard loose from his cold, dead clutches.

OneManWrites
That OneMan is Gordon McLean, a technical author with a passion for good communicative information products. Another Gordon’s passion is web design. In his posts Gordon keeps balance between practical issues and theory of technical writing.

Charles Jeter Blog
Charles writes mainly about technical communication aspects in Web 2.0 world, e.g. work-flow collaboration and e-learning.

User Assistance
An exploration of issues pertaining to online help by Michael Hughes, PhD. As you can see from the blog’s title Michael focuses mainly on embedded user assistance, usability issues and user behaviour.

Just Write Click
A blog by Anne Gentle, a senior technical writer who is blogging about technical writing, information architecture, topic authoring, social media, and other communication technologies.

Mike’s Web Log
In this blog Mike Pope, a technical writer, covers various topics from writing and editing, to teaching and movies, and to politics and musics.

monkeyPi
An interesting point of view on usability, visual & technical communication, and software design.

Great Documents
In this blog Keith Johnson, a technical writing & software documentation specialist, gives many useful tips not only about documentation writing but on successful blogging, SEO, and social networking.

Scott on Writing
Scott Mitchell is a freelance writer, trainer, and consultant. In his technology-related blog Scott talks about technical writing, technology, and ASP.NET

Sharon’s MadCap Blog and Mike’s MadCap Blog
The two blogs by Sharon Burton and Mike Hamilton from MadCap Software. It’s always interesting to know what your competitors do

Technically Speaking
Paul Pehrson is another technical writer who blogs about various aspects of his job: writing tools, software, grammar, technologies and other important topics.

The Content Wrangler
A great resource for everyone who deals with technical content writing, editing, publishing and delivering. There is a lot of practical articles and industry news.

Communications from DMN
Aaron Davis and Scott Nesbitt, two experienced technical communicators, post their ideas and opinions, as well as links to information that they find interesting and hope that you will too. As you will see from their posts, Aaron and Scott have a wide range of interests when it comes to technical communications.

HelpScribe
A pretty young but very interesting blog by Craig Haiss, a technical writer. Craig started his blog to share his professional knowledge with colleagues. That’s great!

Usable Help
A blog of Gordon Meyer, an interaction and instructional designer. Gordon is a professional author and speaker on the topics of help system design. His posts on software help, usability and testing are always very practical and focused.

Of course there are many other blogs on help authoring, technical writing, e-learning and technical communication. I listed only the most popular and active, i.e. with new posts in 2008. If you know other good blogs on these topics, please add them through comments. Thank you!

This post is a brief digest of most important events in our company for the past several weeks. In order to keep this blog mostly self-hype free I summarized all our news in a single short post.

Dr.Explain 3.1 release

We’ve recently released the new version of our software help-authoring tool, Dr.Explain 3.1.

This update is a great step in the product history. Until the version 3.1, many software developers and vendors have been using the Dr.Explain to document their Windows software, HTML pages, or Flash (SWF) applications.
Now, the Dr.Explain 3.1 enters the Java world. Java developers can benefit from the same technology, and automatically generate professional documentation for their Java applications made with Swing components.

Besides the support of Java applications, Dr.Explain 3.1 brings more new functions that will help software vendors produce astonishing documentation even faster. The customizable capturing scenarios allow to precisely specify which window element or HTML tag to analyze or to skip, how to handle its child elements, and how to name and to annotate it. Other gems of the new version are new graphical effects and image rendering technology. All screenshot images, callout lines, text label fonts, shadow and blending effects are drawn with high precision which leaves no chance for fuzzy edges, making documentation illustrations look clean, realistic and nice (beautifully clear).

More info: www.drexplain.com

New Dr.Explain forum

If you have questions, concerns or ideas regarding the Dr.Explain software and if you want to discuss it with other users or with Dr.Explain team publicly then I invite you to join our forum at: http://www.drexplain.com/forum

ISDEF 2008

This week I, Dennis Zhuravlev (a.k.a. Dennis Crane), the CEO of Indigo Byte Systems, will attend the ISDEF 2008 conference in Moscow, Russia. If you attend this event also then I will be happy to meet you there.
There are lots of possible reasons to meet me there:

To ask questions about our products (Dr.Explain and TBS Cover Editor (on behalf of TrueBox Shot software)), our company, or me.
To receive a discount coupon
To know what new projects we’re going to launch shortly
To tell about your products or services
To discuss a possible venture or partnership
To offer a topic for this blog
To trade something
To give or to take an interview
To chat about software, business, sport, politics, or large hadron collider
To take a shot of beer, brandy, vodka, rum, whiskey, tequila, juice, tea or coffee
… or just to say: ‘Hello, Dennis!’

If you’re going to ISDEF, please let me know via e-mail or comment. I’m looking forward to meet you on ISDEF 2008.

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.

[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.

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.

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.

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.

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.

Organize your answer templates. Put the general phrases in one category, registration questions in another category, problem solutions in still another one …

Store your answer templates in a special program developed for this purpose that can paste the template text into the any application practically easily.

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.