|Contents| |Previous|

10. The Finishing Panel:

Optimizing and Keeping Track of Edits

Once a user has an assembly of the fragments that they are confident is correct, the final step in producing a finished sequence is to examine the individual bases in the assembly and resolve discrepencies due to errors in the sequencing reactions. To do so in the FAKtory, one must designate one of the layouts in the master layout cache as being finishable. Only one layout in the list may be designated finishable at any given time. When open on the screen, the Finishing panel displays and operates upon the currently finishable assembly in the layout cache. The display contains a text window on a section of the multi-alignment of a contig of the candidate, a stick layout of the candidate with a box around the part currently in the text window, and if available, a scrollable set of waveforms for the fragments in the text window. This is very similar to the Staden Gap4 model, a model that has received high marks, is widely accepted, and is very natural.

Apart from this basic similarity, our finisher does differ in the details of its operation. First, the waveform area is a vertically scrollable canvas of all the traces relevant at the currently selected column of the multi-alignment. As expected, traces are always aligned with the currently selected column. The FAKtory uses its own internal compression method for storing waveforms so that a typical 600 base pair trace requires only 7kb of space. The FAKtory has an automated scanning mechanism that advances a user to the next ``problem'' column for editing, where the notion of a problem column is configurable in the Finisher Preferences panel. As such an editing sweep takes place, FAKtory records the regions of the finishable assembly that have been so scanned. Such intervals are called edited regions and are retained as an integral part of the finishable solution. A user will never be directed to such sections again by the automated editing scanner. Edited regions are highlighted on the stick layout of the candidate so a user can get a quick idea of their progress on the finishing task.

We paid particular attention to developing a protocol for an editing sweep that attempts to minimize the number of key strokes involved. We did so because it is clear that good ergonomics are essential to making this tedious task move as quickly as possible. Hitting a tab advances one to the next problem column flagged by the editing scanner and places the cursor on the consensus row of the column. Typing a letter with the cursor on the consensus character, turns every character in the column into that letter, i.e., the user is asserting that the letter is the correct call for the column. Hitting a carriage return moves the cursor from the consensus sequence row of the multi-alignment to the corresponding symbol of the first sequence. Subsequent carriage returns move the cursor to successive sequences allowing one to cycle through the sequences, making individual changes by simply typing a symbol. Hitting a tab in the middle of such a column tour moves one to the next problematic column. Backspace undoes the last edit. Shift-tab jumps to the previous problem. Delete removes the current column, space inserts a column of dashes, and so on.

When a user has finished an editing session, quitting the Finisher panel saves all edits as part of the assembly. One can also quit the session and discard all work done if desired. Finally, one can at any time ask the FAKtory to reflect the edits made to each fragment, back to its record in the FAKtory fragment database. Such a request will affect all future assembly generation steps as the edited sequences will be used. Moreover, these changes need not replace the current sequences, but instead may result in a new version of the sequences. The FAKtory supports a linear history of revisions of each fragment's sequence that may be controlled from the Finishing panel. Revisions may be removed at will, save for the original sequence which can never be overwritten.

One last and interesting design problem arose because of the fact that a FAKtory project can contain many layouts. One may select an assembly as being finishable, embark on finishing it, and after making significant progress, discover that this layout is not correctly assembled. Alternatively, a user may discover they need to reassemble the layout with some additional data. To handle this, the FAKtory allows one to designate another assembly as being finishable. However, this is not a light-weight process but involves the transfer of the edits and editing regions recorded for the current finishable assembly to its successor. Regions where the data is assembled differently or where new data is present, and their immediate surroundings must be marked as unedited as the user has not examined the effect of the reassembly. In other words, the FAKtory does everything it can to preserve the prior editing work, but inevitably some regions will need re-examination. Because the step can result in a loss of work, the user is advised to carefully contemplate the consequences of changing which layout is the finishable one.