Presentation
Now you need to decide how to present the configuration choices to your users. Do you want all the choices in one document, or spread out across multiple documents? Depending on your audience and your application, you may want to use a profile document or documents, a single form with all of the configuration options in one place or in multiple documents. Some of these choices will depend on how complex the application is going to be, or how complex the configuration choices will be.

The Help Desk application I've shown you is fairly straight forward, but the configuration choices were complex enough that trying to fit them all on a single record didn't seem like the best way to solve the problem. The list of groups being assigned tickets, as well as their members, could change, as could the list of categories and their subcategories. This chore could have been handled with dialogs and lists, but this method works just as well and requires less work. As a result, I have at least three configuration forms and multiple documents using each.

I tend to use multiple documents most of the time, both for ease of development and because if one of them gets deleted accidentally (less of a problem with profile documents, though they have other potential drawbacks), only a small portion of the application will have problems. I also tend to use fairly generic forms, such as the two in Figure D, for setting up configurations.

FIGURE D


These are just two examples of very generic configuration documents that can be used for multiple functions in the same or different applications. Roll over picture for a larger image.

With some applications, it makes more sense to put all the choices in one place. You may also want to use configuration documents for functions that really lend themselves to a separate document for each situation, like a function that needs to act differently based on the type of form that record uses. Using multiple documents can make the initial development process, where things are in flux, easier to deal with as well. If you wish to you can later go back and consolidate them into a single form.

Some considerations when designing for user administration
As I've begun to outline here, there are a number of ways to design an application so that it's relatively easy for users to change the way things work for themselves. Before you decide which ones to use and how to set them up, you need to consider a few things.

Application complexity
How complex is your application? The more complex it looks like it might be for a user, or even a systems administrator, to administer, the more clarity you'll need to supply.

There are many ways you can make your application less complex for the user, but I find that the best way is to break it into easy-to-follow chunks of related information. For example, if you have an application with a multi-stage process such as order entry and fulfillment, break the configuration documents up by the stages -- one for the order entry stage, one for the accounting department's approval stage, and one for fulfillment.