Making FAKtory Flexible Yet Simple

A basic problem in building a single software tool to support DNA sequencing is that different laboratories use different sequencing protocols, maintain different information about their sequencing reactions, and so on. How do you build one software tool that can handle a wide range of situations?

To address this, the FAKtory has been designed so that it can be configured in a number of ways. For example, one can configure a process pipeline for sequencing reaction data to consist of any number of stages each of which may be configured to perform a different function, such as vector removal or poor-data trimming. One can also configure a database of the sequencing data where each entry has a particular set of fields of specified types of data. In the FAKtory those configuration options which cannot be modified once data begins to enter a project are called customizations. Configuring the pipeline and establishing the form of the database are examples of customizations. All other configuration options are termed preferences. These range from fairly complex settings such as those that program a vector trimming operation in the pipeline, to simple options, such as setting colors for waveform trace displays.

The next design problem arises from the answer to the previous problem: now one has a system of significant complexity because of the large number of dimensions in which it is configurable. Most users will not have the time to learn to operate such a system. Moreover, one cannot be expected to set all these configuration options every time a new project is begun. What is desired is a mechanism whereby a group of end-users at a sequencing center are presented with a system that has been pre-configured by a master user who is expert in the workings of FAKtory. The end users see a relatively simple system, one that is essentially tailored to the production protocol employed at their site. The only preferences these users might wish to set themselves are those concerning colors, input file name conventions, or operating modes for the pipeline.

To achieve this, the FAKtory uses the idea of a bilevel default scheme. There are about twenty different configuration panels in the FAKtory, and the settings of each can be saved and loaded from either the user or master level. When a new project is first opened, the FAKtory looks to see if there are any user-level defaults and loads any it finds for use in the new project. If any configuration options are still unset, FAKtory next looks at the master level for defaults specifying them and loads them if found. Finally, any remaining, unset configuration options are set to values hard-coded in the software. The execution of this default chain protocol on new project initiation has the following desirable properties. If a master user has established a configuration for his laboratory at the master level, then all end-users will see this configuration, unless they choose to establish their own defaults which always take precedence. This they may do in the parts where they desire to exert control by saving defaults at the user level. User level defaults are specific to each user, so each end-user sees only their customizations. Once a project has been created, its configuration settings are saved and loaded with the project thereafter.