Crisis Averted!

Recently while working on a few Swing applications at work, I realized that one of the most frustrating aspects of developing Swing apps (and perhaps GUI software in general) is also one of the most mundane: user preferences. Building out the main application is tremendously rewarding, but providing users with preferences can be a huge pain.

Most GUI applications provide some way for a user of the application to modify how the application behaves at run time. In fact, users expect some level of control over the application's behavior. As a user, I like having options, even options I know I won't need right away but might like at a some point in the future. But users — myself included until recently — don't realize that, as a developer, providing users with options is often a huge pain.

First, the preferences need a place to live. As developer, I need a way to retrieve preferences from somewhere and store them back again. This storage system could be a text file of key-value pairs, more complex XML data, an OS-provided data store (e.g. Windows registry), a relational database, or umpteen other possibilities. Choosing the proper way to handle the storage of user preferences depends on the size of the project, but is by no means a simple matter. Simple applications with many options can quickly outgrow a simple storage system.

Once I've decided on a storage system and implemented an API for manipulating it, it's time to give the user a way to see and modify the current configuration - a user interface. As luck would have it, there are no standard conventions for creating preferences UIs. Because the preferences for a unique application are, well, unique, there is no one generalized UI that will work in most situations.

It was at this point in the development of one Swing app that I had an epiphany.

A user preferences UI and storage system is a complete project in and of itself, with a purpose entirely separate from that of the application to which it provides configuration abilities.

It was also at this point in the development of one Swing app that I began to gently rock back and forth in my chair, mumbling incoherently as I realized exactly what I was up against.

The preferences UI has to make sense. The user has to be able to quickly find where a setting can be changed. If the preferences UI is too convoluted the application becomes difficult to configure, and the overall experience using the application can be adversely affected. Sometimes this is a task best left to designers or so-called information architects. I would advise against letting a strictly developer-type build your preferences UI. This is something that a user will see from time to time. It needn't be pretty, it need be easy to use.

Once I've sufficiently sketched the UI (or reviewed a designer's sketches) and feel I'm confident I understand how it will work, the biggest pain begins. I must now translate thoughts and drawings into code. This is perhaps the most time consuming step in the process. The preferences system I create must present a simple UI to the user and also be easily maintained when preferences are added, removed or modified.

Creating the UI itself isn't terribly difficult, but because preferences often use a myriad of UI controls such as text fields, select lists, drop downs and check boxes, the logic behind each control must be fleshed out and properly bound to the storage system. In some cases, controls will also have unique validation requirements such as a minimum character length or specific punctuation to avoid configuration errors. It's the 'controller' logic that is the real killer of moods. Creating this layer of the user preferences system is the most tedious and time consuming and can also be the least rewarding. It's just fluff, but it's important fluff. Therein lies the rub.

Finally, after I've designed and created the UI, bound the controls to the storage system, validated certain new values, after I click 'Save' and the the modified values are written out to the storage system, after the application responds to me changing preferences, my job is complete. I've just spent a few hours, likely days, and potentially weeks allowing Joe User to change his text color from Medium Quasar Blue to Metallic Pearl Shine. And because my application is not a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've just spent many hours on code that does not help accomplish my applications main goals.

At this point, my user is happy, and if I happen to work on another application that needs a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've already got some code to work with. However, I'll still need to decide upon the proper preference storage system, create a unique UI and write the tedious controller logic fluff. There's got to be a better way.