| The Library Project is filled with features that target small library-style organizations. But it may not meet the needs of everyone. And that's okay. The users know your address and phone number; you'll hear from them. When they call, you can tell them that the software wasn't designed for everyone; no software can be. All software, even general-purpose applications such as Visual Studio, can never meet the needs of every person or organization. What is important is that the features included in the project meet the needs of the intended audience. That audience may be the card-catalog-using public, or it may just be a small library with one part-time staff member. Still, there is always room for improvement. Because the Library Project's real target audience was youthe student of Visual Basic and .NETit did not have all the features that most libraries would require. Looking quickly back through the source code, I came up with at least the following changes that could be made to the project to bring a lot more value to library administrators and users. Error logging. The application includes rudimentary error detection and handling features, but they could definitely be improved. The logging feature used in the application's GeneralError method (which includes a call to My.Application.Log.WriteException) sends the written content to any registered log listener. We just used the default listeners, but we could have added listeners to centrally collect error reports and details in a database or file for later analysis. Error handling. When an error does occur, most of the Library code simply reports the error and moves on. Some methods ignore errors completely. In general, the code could do a better job of processing error results. Some errors are more fatal than others, and specific errors should include additional options that the user can access to better recover from the fault. Multi-threading. We did not discuss or take advantage of any of the threading features included in the .NET Framework. Processor-intensive activities tend to kill the responsiveness of the user interface, but there are ways of mitigating the impact. In the Library Project, two specific areas would benefit from the use of background worker threads, by either using the features of the System.Threading namespace directly, or by using the BackgroundWorker control: (1) searching for library items through the ItemLookup form; and (2) processing overdue and fine data for a single day at all locations through the MainForm.ActDoProcess_Click event handler. User interface and presentation. Although I included some cute graphics on the main Library Project form and the Splash form, I didn't do much beyond that. Mostly it was an issue of time and effort, but I also have very little talent for the graphic arts. The program could use an update in its general look and presentation. And with the new graphics features built into Windows Vista, you could enable some really amazing effects with little programming effort. User interface consistency. Although I tried to be careful, there are probably labels, controls, and error messages that use two different names for the same thing. Perhaps I used the word "book" or "DVD" when I should have used the more general term "item." Although tracking down such inconsistencies is a lot of work, it increases the level of professionalism in your application. It also makes the task of foreign-language translation easier when localizing the program. Testing new databases. The LocateDatabase.vb form builds a connection string from the fields supplied by the user, but it does not test the connection to see if it works. Providing an option to test the entered values could reduce long-term errors. An even better option would be to let the user search for the database, similar to the way that SQL Server itself sniffs out and presents located servers and databases. Numeric title searches. The check-out and check-in features let you locate an item either by name or by barcode. If you enter a number, the program assumes that you have entered a barcode and retrieves the matching item. But there are some book titles that are numeric. For instance, David McCullough's book 1776 would cause the program some difficulty if each copy did not include its own barcode. An enhancement to the program would provide the user additional disambiguation options when a numeric entry matched both a barcode and a title. Enhanced item searches. Although I have much reason to be impressed by my item lookup code, the program could do so much more. When you use the card catalog systems at larger libraries, the lookup features include "proximity searches" that return results that are alphabetically close to the search terms provided by the user. SQL Server also has a "full text search" option that could be used to broaden the item lookups. Reserves and holds. I started to add a "reserves" feature to the Library Project, so that patrons could add their names to a waiting list for checked-out library items, and have those items placed aside by the library staff when they were returned by the previous patron. Although this would be a cool and useful feature for a library, it didn't add any pedagogic value to the book, so I left it out. But I still hear the software sniffling and crying once in a while when it thinks of the feature that might have been. This would be a great enhancement for "version 2." Incomplete item history. On the PatronRecord.vb form, the Fines list shows a patron's previously checked-out library items only if those items had once been overdue and had incurred fines. Items that were returned on time cannot be displayed in the list using the current form logic. A satisfying change would add a "Show all returned items" checkbox that would include these checked-in items. This would allow a librarian to charge for things such as damage on items that were otherwise free of fines. Return of missing items. If an item is marked as missing, the library staff may charge the patron for the loss of the book. If the patron later returns that item, the librarian can process a reimbursement to the patron. But the program could make this task easier by automatically marking the item as eligible for such a refund. This would require a new status field on the PatronCopy database table to track this status. Barcode design interaction. The BarcodeLabel.vb form is, I think, pretty amazing with its graphic preview of the barcode. But the preview is unidirectional only; the user is not able to select a display element by clicking on that element in the preview. Instead, it is necessary to click on the related item in the DisplayItems list. Enhancing the program to detect clicks on the preview and translate those clicks into item selections would make the program much more like other applications that support basic drawing features. Database setup features. Although we built the setup program for the main Library application, we skimped on the server side, providing only the database creation scripts as text files on the installation media. A more professional system would provide a separate installation program that could build and configure a new database from an existing SQL Server installation. Support for library standards. Just as the software development world has standard formats and protocols, such as XML, library systems also share common standards. Two accepted standards are MARC (Machine-Readable Cataloging, a standard card catalog data format) and the Z39.50 interface (a communications protocol used for inter-computer searches and data retrieval). Incorporating these standards into a small library system may be overkill, but they would bring a much higher level of automation and convenience to the library staff. Bug fixes. I probably left a few bugs in the application. No, wait. I think I put them in there on purpose to test you, to see if you were learning and growing in your programming skills. Did you find them?
These are just some of the improvements that I thought of off the top of my head. If I had gone all the way down to my shoulders, I could have come up with even more. If your software will target the general population of users, you will probably release updates on a regular schedule, such as annually, and charge appropriately for the improved features. If you wrote the application for one specific customer, the updates may be more frequent, even weekly or daily in some cases. Whatever the audience size, your opportunities to improve and enhance the software will be regularly and ongoing. |
