Project Post-Mortem

only for RuBoard - do not distribute or recompile

Every project that was worth doing should have a post-project debrief. What went wrong? What could have been done better? While the ideas are still fresh, you have to ask yourself what things should go into the next version.

The application probably could have made all changes be automatically saved (to the customer record, frm_main) and the cmd_save_edits button could have been removed altogether. The times when edits won t be saved will be very rare. So such a change probably wouldn t impact usefulness and would save more keystrokes than it created. Instead, simply run the update database procedure every time frm_main is moved off the current record.

Regarding the changes made to frm_items_ordered, simple is best. If a set of widgets can be put into a vertical packing box as opposed to a vertical packing box with a number of child horizontal packing boxes, that is simpler and better to implement, assuming it doesn t affect usability.

Check the resize action of the window widgets early in the development cycle ”as soon as possible after all the child widgets have been filled in ”to see that the form is resizing correctly. As an example, see Figure 7.10. Notice the wasted space when this form is resized. Even though this form will rarely be used (due to the way it is used and its short life cycle), it would have been nice for it to look correct even when maximized.

Figure 7.10. frm_main maximized; clearly this is not the desired result!

Figure 7.10 shows frm_main in its maximized state. Fortunately, there is no really good reason for the user to do this while using the application! Clearly, more time could have been taken to make sure that the resize action was a bit more, um, palatable. Compare Figure 7.10, however, with Figure 7.11.

Figure 7.11. frm_items_ordered maximized; now that s more like it!

Figure 7.11 shows frm_items_ordered maximized, and although it was never intended to be maximized, it doesn t look too bad. The primary difference between them is that frm_main used all vertical and horizontal packing boxes, while frm_items_ordered used the horizontal and vertical paned widgets.

The add-quantity box between the CList boxes in frm_items_ordered probably could have been done away with. In fact, so could the other quantity spinbutton in the upper-left corner. Instead, the user could have just entered the same item twice to clist_items_ordered, and the result would have been the same. This only makes sense if it is far more normal to order only one of something; if quantities of two or more occur (for example, 40% of the time or more), then perhaps the way it was done is best. This is something that would need study in the actual environment in which it was being used.

A double-click event on the rows of the clist_widgets would have been useful; for example, to double-click clist_items and to have it run the same code as on_cmd_add_down_clicked() would have been an easy and functional addition using already existing code. Unfortunately, there is no double-click event in the GTK+ event model.

The desired functionality of being able to do nearly everything ”at least the common things, anyway ”all from the keyboard was achieved. Someone who takes time to learn the keystrokes and the various key shortcuts (like Shift-Tab to go back one widget in Tab order) will be able to enter orders extremely quickly.

only for RuBoard - do not distribute or recompile