A Good Desktop Software in Users' Eyes

Introduction

Recently, I was working on improving my software quality. It is a desktop application written in C# purely.

Here, I share my take-away from my reading of books, white papers and have summarized for your reference.

Maybe, you are already facing troubles from these traps.

If users can get their needs/goals served (usuability), your software keeps regular updates, your software keeps good track of errors and warnings, then your software will head to success.

Usability, updating regularly, and good error handling are three pillars to your software success.

Background

There are many ways to keep high quality of software. I shared some experiences related to Windows application written in C#. It is a small utility software.

Poor Usability

In 1974, Jerome Saltzer and Michael Schroeder proposed a handful of important design principles. Principles are still valid after 40 years. The last of these principles is "psychological acceptability", which states:

It is essential that the human interface be designed for ease of use, so that users routinely and
automatically apply the protection mechanisms correctly. Also to the extent that user's mental image
of his protection goals matches the mechanism he must use, mistakes will be minimized.
If he must translate his image of his protection needs into a radically different specification language,
he will make errors.

Possible reasons behind this are as follows:

Software designers often implicitly make the assumption that whatever they find usable, other people will find usable.

So the first principle of building usable, secure system is that "designers are not users".

Another cause may be, designers are often not in tune with the annoyance level of their users.

A good example is Windows Vista. Microsoft did a great job of dramatically improving the security of Windows, but users focused on only one security-related aspect that was annoying to them: User Account Control (UAC) prompts that asked for consent from user before she performed potentially sensitive operations.

Windows 7 addresses this issue nicely by reducing the number of prompts dramatically and allowing users to configure how much prompting must occur.

Not Updating Easily

Most software needs to be updated regularly during the supported lifespan, whether this is for a bug fix, for a service pack, as minor update, or to fix a security bug. Problems arose as to different users: home users, enterprise users or on servers.

Different types of applications have different updating needs. Two extreme examples are anti-malware software and online games.

Potential causes are listed here:

1. Installation of additional software
2. Too much access control
3. Too many prompts to users
4. Ignorance to users. There is a balance on how much you should let users know your update.
5. Updating without notifying
6. Updating one system at a time
7. Forcing a reboot
8. Difficult patching
9. Lack of recovery plan
10. Blindly trusting DNS
11. Blindly trusting the patch server
12. Abusive update signing
13. Abusive update unpacking
14. Wicked user application updating

All these items required designers to think through and implement in an appropriate way.

Failure to Handle Errors Correctly

When programmers fail to handle an error condition correctly, many risks occur. Sometimes, your software can end up in an insecure state, but more often, it results in a denial of service issue, as the application simply dies. Especially in C#, where the failure to handle an exception usually results in program termination by the run-time enviornment or operation system.

The consequence is that any reliability issue of your program leads to the program crashing, aborting, or restarting, which all are named denial of service issue.

This type of error is hard to capture. Common reason is that the code is copied and pasted from other sources. These code lack error return checking to make code more readable.

There are few variants of this type of error:

1. Yielding too much information
2. Ignoring errors
3. Misinterpreting errors
4. Using useless return values
5. Using non-error return values.

A good logging framework needs to be in place to help you track errors and warnings. Therefore, we can keep improving our application. Also it will also bring more revenues coming because users have to pay for software updating plan.

For .NET, NLog is a good framework.

Points of Interest

I am still researching this topic and will keep updating this tip. Any comments and experiences are welcome.

As my research goes on, I will share more heart-felt tips and experiences.

Reference

• http://www.strchr.com/software_interface

History

• 2015-09-26: Initialized this tip