Over the years, I’ve established guidelines for building database software with a two-fold goal: 1. Make it easy to program for the development team and 2.  Make it easy for end-users to learn.  If you’re writing a new software tool, evaluating existing software solutions, or trying to learn a new database software product, breaking the software into the following layers will help you work towards understanding the fundamentals of the product and aid in your success in writing, learning, or teaching the solution.

Navigation - This is usually accomplished using “tabs”, a “tree view”, or something similar and should be labeled according to the primary “nouns” the database solution manages.  For example, consider the tree view control inside MS-Outlook.  It contains an “Inbox” for email messages, a “Calendar” for appointments, and a list of “Tasks”.  All nouns.  If you see words other than nouns in the navigation area of the software, especially verbs such as “Create new message” or “Create new task” as a tab or a tree view node, expect decreased usability and increased training time.

The Three S’s: Search, Sort, and Select - Once you’ve navigated to the nouns you are interested in working with, you should be able to search the list, sort the results, and select the particular records of concern or interest.  If the solution does not provide a simple means to accomplish these three functions in a simple, intuitive manner, expect confused users and a feeling of being isolated from the data.  When end users navigate to the “nouns” they are interested in working with, they don’t want to see the software standing between them and their data - they want to see their data.  Moreover, they want to be able to perform the three S’s.

C.R.U.D. Management - C.R.U.D. stands for create, read, update, and delete.  These are the basic operations that the database software needs to perform for managing data.  The more consistently the software can handle these basic operations, the easier it is for the software developer to scale the software and the easier it is for the end-user to learn these basic functions.  If navigation is about the “nouns”, CRUD is certainly about the “verbs”.  Verbs should be identified in the user interface as buttons or toolbar items.  “Create a new record”, “Save the record”, and “Delete the record” should be buttons or in a toolbar.  End users are accustomed to seeing these standard operations this way - don’t confuse them. 

Tools & Wizards - Advanced data operations (beyond simple CRUD management) should be performed using action dialogs & wizards which will guide the end user through a specific task.  Like any verbs, tools & wizards should be launched from buttons or a toolbar so as to associate their use with adding/modifying data.  The “features” list of the software should be evident in the tools & wizards made available to the end user.  If the user is excited about a particular feature in the software and that feature is explicitly identifiable by means of a tool or wizard dialog, the probability of success for both the developer and the end user increases dramatically.

Reports - If C.R.U.D. and Tools help the user get data into the system, certainly reports help get the data out.  But, more than that, reports should turn the data into information.  Each report should have a clear description that states succinctly what kind of information it returns and how it is intended to be used.  Furthermore, 90% or more of the reports should be “parameterized”.  This means the end user has the ability to specify a date range or other information which may filter the results according to their needs.

In summary, these are simply the fundamentals that I use when evaluating and writing database software.  Advanced solutions would require a fourth “s” to be added: security; however, this topic goes beyond the scope of this post.