What features should an application have even your client hasn't ask?

Question

Hi all,

After serveral years developement, I believe that there is no SIMPLE application in the world, though Clients often say "I have a simple requirement". There are too many things to think and to do in a software development. So I start thinking the following question:

What features should an application natually have, or at least you must think of, even your client hasn't ask?

For example, when I'm going to develop a desktop app, I often think about the versioning problems: are two different versions of an application allowed to co-exist in one computer, like .NET2.0 and .NET3.5 ? How to list all versions? How to upgrade the existing version to a newer one? ...

There are some common problems. The clients may not start thinking of them yet. But as a devloper, I think we must consider the problems before they do.

Here I just want to make a list of those things we should not forget. I'll start the list first.

1. Version. Even before start developing the application, we should think about how to upgrade.
2. Auto update. Like FireFox, when the application starts, it checks for new version and auto updates.
3. Logging. I think all applications must have a logging mechanism. A good idea I think is that log the OS name, version, SP, third party components' names, paramters,..., when the application starts. So when a bug occurs, the developer can find the environment and the parameters quickly without bothering the end users.
4. Globalization. This is very common in these days. If your client forgot this, you need to remind him/her.

Please feel free to contribute to the list, thanks.

Edit: Add a few items:

1. Make UI styles customizable. Maybe not have to provide a dialog for user to change fonts, colors..., but at least let user have the ability to change these stuff in a config file.
2. Command line. Allow users to run the app in a bat file.
3. Be able to embeded in other applications. Encapsulate core functions into a component (e.g. COM). So not only human users but also other applications are able to call your app. It is useful when people wants to automate some tasks.

Answer 1

An installer.

End-users will have no idea what to do with a .zip

Answer 2

Security and acceptable performance

Answer 3

Error handling.

Answer 4

Here's my list of things to add:

1) Deployment - Will this be a web application, desktop application that has an installer, or just a simple little exe file that doesn't need an installer?

2) Bugs/new features - How are these to be handled within the application? Is it acceptable to ship with bugs?

3) Network settings - If you are going to do the autoupdate then it should be noted what firewall settings will the application require for updates as well as to access any data it uses.

4) Technical support - If someone wants help using the application, what is the procedure they should follow?

5) Databases - Does the application require data to be stored in some fashion? Should this be encrypted in some way?

Answer 5

Portability and scalability - Especially web-apps.

It might cost them a few more bugs to make sure the app is upgradable to serverfarms and the likes, but in the long run, it's ussually worth it.

Answer 6

As a consultant it's your job to make these things clear to your customers whether or not they are technically savvy. You can present them as recommendations and hope they see the value in them or tell them these are items that you require that they allot time for in any of your projects.

Answer 7

Extensibility, which could be achieved through a plug-in system, scripting, ability to communicate with other applications... (where "communicate" can be as simple as allowing to export or import data into various common formats ).

Answer 8

I really feel every non trivial application should naturally have a feature that allows the end user to communicate back to the developer or software house. A "contact us" form on a web app or a nifty "give us your thoughts" link in an About dialog. We almost take these things for granted at this point but it deserves being mentioned.

Placing it in your documentation or in an e-mail they'll forget about roughly 10 minutes after getting it just doesn't cut it, in my opinion.

Enable and encourage communication even if you wind up ignoring 90% of it.

Answer 9

In addition to the above...

People expect their application to conform to "normal" user interface conventions. The problem is that there is no one right way to do a UI (although the Microsoft - http://msdn.microsoft.com/en-us/library/aa511258.aspx - and Apple-published conventions are a useful and defensible starting point). Business owners may not include details in the spec or time in the budget--at least not until they see your inline form-field validation and decide it should have been a pop-up (or vice-versa)! Some specifics:

• Tab order.
• Useful title bar text. Especially if you have a lot of windows open, and can only see the first few letters of each in the taskbar. (For that matter, make sure your app behaves predictably if the user opens it more than once.)
• Form field validation (this is a whole topic itself).
• Forgiving input - like trimming extra spaces in certain field, recognizing dates and times, auto-complete, etc. Spinners and pop-up calendars may be OK for Internet visitors, and might look great in a demo! ...but if your user's job is to use your app to schedule appointments (all day she does not want them.
• Keyboard shortcuts
• Copy and paste.
• Appropriate use of "save changes before closing?" type messages.

I also found Jef Raskin's classic The Humane Interface helpful to understanding these issues.

If nothing else I've had end users buy me a beer after work because they know I am attentive to their needs.

Answer 10

The most important: Security. They don't ask for their computer not to be hacked, or their data stolen. But if it happens they'd be pissed off.

Answer 11

Logging unexpected errors / exceptions back to base. Ala, Microsoft's error reporting service.

If your app blows up for whatever reason, your support staff should know about it within seconds of the crash. Customers are encouraged that you're dealing with errors quickly and not just ignoring them. You can fix all those errors that customers just ignore and work around.

And as part of this, you need a decent privacy policy.