The Twelve Days of Software Development
In the real world, people like to feel at home. When in someone else's home, you always feel a little out of place, because the other house doesn't have any of your stuff. People like to dress up their own house just the way they want it.
Similarly, when people use a computer, they like to dress it up in a such a way to make it their own. This is why systems let you customize the desktop image, add a screensaver and change some fonts and colours. These customizations don't provide any useful value, except to make the user feel at home. When building an application, it is often a good idea to add some configuration features so that the user can feel more comfortable using your application. The user is probably more likely going to continue using your application.
However, users don't need too much of this kind of configurability. Otherwise, the user will be too overwhelmed with the options presented to them.
There are three kinds of preferences:
- Required Settings: these are settings that are required to be set to something in order to use the product. For example, a mail client requires the user to enter their mail server in order to function. Because it is required, this information is often asked for during installation or when the application is first run.
- Optional Settings: these are settings that aren't required by everyone, but may be necessary for some users. For example, some users will need to use a proxy in order to download content from the web. Proxy settings aren't required for everyone though, but some users will be unable to use the application if it does not provide such settings.
- Optional Preferences: these are preferences that have been set to a suitable default value, but the user may change as necessary. For example, a background image or the number of items to display on a recently used files list. These can be broken down into two groups, those that allow the user to decorate the application as described above, and those that affect the functionality.
When deciding which preferences to include in your interface, determine which category each configurable feature falls into. Required settings are fairly easy to determine. Knowing the difference between optional settings and optional preferences can mean the difference between an interface that doesn't allow enough configuration and one that allows too much.
In order to keep the preferences panel simpler, prioritize the optional preferences, and decide which ones are more useful than others. You need to do this whenever someone wants a setting added. If someone asks for the ability to change the size of the font to make it more readable, you might consider adding such a feature. However, if someone wants to have a preference to change the sound effect played when a search doesn't find any results, you might consider not implementing it, since it is a rather specific configuration option. It's also entirely a 'feel at home' option, since it doesn't affect functionality. Learn to ignore the requests for really obscure things. Everyone will have their own things they would like to be able to change, but you have to set some limits.
Usability people tend to look at the preferences panel of an application as a history of all the arguments that the developers had. Each developer will want to have some say in how the application is built, and they will all have their own settings they want to add. This is especially true for large applications. Each group will want to ensure that their work has an equal part in the application.
Some people have considered using a Simple and Advanced mode for their application. In general this is not a good idea, as what constitutes Simple will be different for different people. If a user wants only a single feature in the Advanced category, they won't be able to use the Simple setting.
One thing to keep in mind is that users won't notice many preferences if they aren't present to configure. As long as your chose a default setting that makes sense, many users will just assume that the default is just way your application is supposed to work. Most people don't spend time thinking of other ways it could be done.
One possible way to allow extra configuration without adding too many settings is to make your application extensible.
Very few first releases of new applications focus on extensibility. Instead, the developers try to focus more on getting end-users to try the application, so they focus on features that users will want. This is especially true of new kinds of applications -- those that don't have any direct competition. These new applications are usually very simple.
Several releases later and people will have a good idea of what your application does and will have become familiar with its interface. Making drastic changes is probably not a good idea.
Instead, many applications provide a way for third-parties to create new features by extending the base product. Although users will appreciate the features others create, making a product extensible in more of a benefit to developers. If someone invests time and money to build an extension for your product, they will be likely to continue using your product to ensure they get a good return on their investment.
Some applications have provided a scripting tool that lets developers add functionality to manipulate the application. Sometimes, these are called macro languages, and are often used to automate specific tasks that particular people or groups of people need. A framework for creating macros is shipped with the product and is usually simple enough for people to use. However, they do have limits on what they can do.
These macro environments do have the advantage that they don't require any specialized tools to use, apart from what is included with the product. The more additional tools that are needed to extend an application, the less likely it is that extensions will be created. If your application requires a C compiler for creating add-ons, then you limit yourself to developers that know C, or those that are willing to learn it. You limit yourself even more if you require a specific compiler.
Mozilla Firebird, at the time of this writing, has 101 extensions, only a couple of which require a compiler or other specialized tools. The rest were created using only a text editor and a zip utility. This allows a larger number of people to create them. It also helps that Mozilla Firebird allows more significant kinds of changes than many other applications, for example by modifying and improving existing features as well as adding new features.
The more changable the application is, and the simpler it is to make changes, the more you'll find that developers will do so. The more extensions available for your product, the more useful users will find it, and the more likely they will continue to use it.
However, adding extensibility to an application isn't something that is viable in all cases. For some applications, a macro language is sufficient, for others a plug-in mechanism is possible. The complexity will also depend on the architecture of the application. It may be difficult to add a mechanism to extend an application to a existing product. Extensible applications will need to be more modular than other applications. There will likely be a trade-off in performance and size of your application.
A non-extensible application has the advantage that it can be architected more tightly together. Each part of the application knows exactly what kind of input it will receive, and what kind of input is most common, so it can be tailored to those particular circumstances. However, once you add extensibility, you may not be able to do this, since the add-ons may do things differently.
For this reason, applications usually add a small amount of extensibility at first, followed by larger frameworks in later releases. It is important to identify if developers are looking for ways in which to extend your product and in what ways. In this regard, the add-on developers become your target users when creating new features. Some applications, for instance, have features that were designed in such a way to aid in being extensible.
No matter what level of support you provide for adding to your application, there will always be someone out there that needs support that is just one level higher. If ensuring developers are able to build onto your product is important, you need to balance adding new extensibility features while improving existing features. If end-users are more important though, you will likely find that extensible features will suffer as a result. Developers will have trouble working with existing features, as focus will be on ensuring that end-user features work instead of developer features. Some products have appropriate developer support groups such as mailing lists or forums, or for larger companies, support one can pay for. This also encourages more developers to create add-ons as they know that can get help if necessary. If little to no help is available, you will find very few extensions created for your product.
At some point, you will want to have your product translated into other languages. This is especially true of software that will be downloaded from the web, since anyone could download it.
As usual, determining who your target audience is, will determine which languages you select to use. You'll only be able to select a small handful since there are so many. Fortunately, when it comes to basic aspects of localization, your task won't be too difficult. Applications usually allow localization by extracting out all of the places in which text, images, or other locale-specific information appears into a separate file or set of files. Thus, a new locale can be provided by modifiying only this small section rather than requiring the application to have to deal with locales in specific places within the code. A hard part is getting the programmers to remember to do this separation. You'll no doubt find some hard-coded text stuck in the depths somewhere.
Some applications even allow these extra locale components to be downloaded separately. That way, the user may select only the one they need, or more than one, if they wish. It also allows localizations to be made available after a main release of product. You may even wish to allow third parties to make these components themselves. Be careful about doing this though, as a minor change to the text or arrangement of a dialog box in the original version may break other localization modules.
Be aware also that there are hundreds of different langauges, some of which are used in very different dialects. For example, the French spoken in France is quite different than that used in Québec. This is certainly true of technical terms, where usage developed differently for different areas. This is also true of English as some words have various spellings.
Localization is more than just translating your product into another language though. Usually, other aspects of your product will need to be modified as well. For example, you may need to modify the user interface in some way as text in one language is much longer than your others. In this case, the size of a window may need to be increased, or you may need to shuffle some elements around.
A common mis-assumption is that other languages use the same word ordering. For example, let's say your application has an option 'Delete items older than [xxx] [days]', where the square brackets are fields or drop-downs that the user may fill in. In some languages, the two fields may need to be reversed. Make sure also to catch small labels such as 'KB' for kilobytes which you will also need to have translated, or placed in a different position with respect to a field. In some cases, you can get away without the reordering, as the text itself can sometimes be worded differently in other languages and still make sense.
Also ensure that you don't use terminology or have fields that someone in another region won't be able to understand or use. The classic example of this is having a field to enter a zip code and only allowing five numbers to be entered, even though most countries use different forms for their postal code. This is an even bigger problem if this field appears as a required field on a web site. People around the world won't be able to enter a valid value and you'll find that you have a disproportionate number of users from Beverly Hills.
Some web sites, especially those that started in a non-web business such as magazine publishing haven't adapted well enough to having a worldwide audience. Many still use phrases like 'across the Atlantic' and 'south of the border', even though that doesn't make sense to many people. This isn't such a big deal and not really of concern if you are just republishing articles that appeared in a local newspaper. But if your primary audience is readers on the web, avoid using such phrases and just say 'Europe' or 'Mexico'. In fact, you should just should avoid using such tired phrases whoever you are.
Another thing your application will need to do is use the correct date and number formats. For example, some regions will use a decimal point that looks like a period and others a comma. Conveniently, most systems and programming languages provide functions to obtain this information based on system settings.
Time zones are especially tricky to deal with. Most people will be in an area that is some number of hours ahead or behind you. In addition, there are time zones that are half an hour different and some that are a quarter of an hour different. Some towns that are near the border between two time zones are officially in one time zone, but use the other time instead. Some areas have daylight sayings time and others do not and it isn't consistent even within the same country. (Saskatchewan, and parts of Indiana, for example, do not). The date on which daylight savings time occurs is radically different for different regions. Some countries change the date every year. So if you need to use the time accurately, you will have a lots of things to think about when developing your application.
When building products for other countries, you will also have to deal with numerous other issues, including: different kinds of keyboards, different character sets, alphabets that are rendered right to left versus left to right, vertical writing, ensuring appropriate fonts are available, regions where certain images or icons may have negative meanings, or even political issues.
So, despite looking like a simple task at first, localization is a much larger task than one might think.
Most people who think of accessibilty think that it means providing support for people with special requirements such as those that are blind or cannot use one or both of their hands. While this is true, accesibility is actually about providing support to all of your users.
There are numerous specific accessibility aids, such as screen readers -- which read aloud content that would normally be displayed on a screen -- specialized input devices which replace a mouse, and voice activated systems. Operating system toolkits today have support for these types of devices built in. If your application uses platform conventions for displaying and manipulating its interface, support will usually be automatic, since the platform handles the required behaviour. In addition, special functions are available in case you need to handle such features yourself, for example if your application uses a more specialized user interface.
This is fortunate since many developers don't tend to focus on accessibility. Very few people know much about these specialized needs.
Don't assume that people use a system to the same way as others. Some people can only use a keyboard, only a mouse, and some will only be able to use a single button located near one of their fingers. Ensure that important operations are available in consistent ways. Provide both keyboard and mouse access to all operations. Buttons on toolbars, for example, usually have a similar command on a menu, for example. As long as you use common user interface conventions, the specialized accessibility devices will be able to handle things for you, mapping the input from the devices into mouse clicks for example.
Accessibility is more than just providing for special needs though. It is also about ensuring that everyone can use your application and this ties directly in with usability.
Typical web designers -- those people who make web pages for a living -- have this notion that they should make web pages for the majority of their audience. To them, it's acceptable for a small percent of people can be ignored. This is true of other industries as well since it is very costly to support all people. You may be able to support 95% percent of your users, but each extra percent is five times more costly than the one before it.
The typical web designer has this user in mind: someone who uses Internet Explorer 5.5 or 6.0 on Windows, with a screen resolution of 800x600 or higher and their windows maximized, is using the default background and text colours, has images enabled, has scripts enabled, has popup windows enabled, has Acrobat and Flash installed and enabled, has perfect vision, can read very small text, sits with their eyes directly in front of the monitor, isn't colour blind, has the use of both hands and is dexterous enough to use a mouse and keyboard, and understands computers well enough to be able to use less usable applications. Only a small number of users may not match each qualification when taken individually, however, when taken together, they represent a much larger number of users. I'd imagine that the number of people who pass all of the qualifications listed above is actually in the minority of users.
When building an application, don't assume that one kind of user is in the majority. In fact, all of your users are in the minority.
Features that you add to an application as an accessibility aid will also be used by people that don't absolutely require them. For example, many people will still increase the text size of a web page even if the text is already large. Even though the the text on the page isn't too small, the user would like it larger anyway. It is very costly to add elevators at every small train station, however they are built anyway. Few people who have trouble walking around, or cannot walk at all, will use them, but you'll still see lots of ordinary people taking the elevator. Don't assume that accessibiliy aids should be targeted towards certain people as other people will use them as well.
It is important to understand that people will have very different ways of using your application. It would be very contradictory to build an accessibilty aid that other people can't use as well.
Thus, your application will need to provide ways to improve the experience that all of your users will have using it. Allow the user to change fonts, colours and other styles. Don't force the user to use an application the way you want them to. Allow the user to use the application the way in which they feel most comfortable with.