Standards

Standards are absolutely essential for the success of large, multi-developer projects. We will review three distinct areas in which we have defined standards for our developers to adhere to: naming, programming and GUI design. Again, the effort involved here isn't so much difficult, but it does require some up-front investment (mainly of time) to put it into place. Once you have a well-defined set of standards in place, you will realize benefits in the following areas:

• Development time. The key is to drive down the time spent on essentially trivial matters: you don't want expensive resources like Visual Basic programmers endlessly debating naming or coding conventions with each other, or arguing over whether command buttons should have ellipses or have proper-case text. Naming, programming and GUI design standards should ultimately be so internalized by your development team that they become a base language everybody can take for granted.
• Maintenance time. Consistently named and formatted code is much easier to maintain than ad-hoc code. The classic example is returning to an application for changes or maintenance six months after it's been written: if you have the same conventions now as you did then, this just might be possible — if not, forget it!
• Customer acceptance. A consistent GUI design that basically adheres to Windows standards will present a more professional appearance and ease users' learning and ultimately acceptance of an application. Similarly, published naming and programming standards will increase the comfort level of IS personnel — an important issue if you are an independent developer working on custom corporate applications.

In this section we'll present a guide to defining your own standards in these important areas. As elsewhere in the presentation, our focus will be on how these standards are adapted to the Visual Basic world. We don't have time to present a complete standards document, but we'll try to present enough concrete examples to get you started.

Naming

In Appendix A we include a summary of a naming approach that has worked well for us. For now, we'll provide some general guidelines and then review some of the areas you will want to define a set of naming standards to cover.

General Guidelines

In general, our naming conventions obey the de facto standard construct:

<prefix><Mnemonic>

The <prefix> portion identifies the technical nature of the thing being named: what type of control it is, what data type a variable is, the scope of a variable, the type of object a variable points to, and so on. The <Mnemonic> portion identifies the business role the thing plays, or the function it performs.

You should have well-defined naming conventions for at least the following areas:

• Controls. Both standard and extended (third-party) controls should be covered.
• Variables. Some of the issues you should address include:
  • Scope, persistence, how arguments are passed to procedures
  • Data type
  • Object variables: distinguish between types of object variables and different object models (e.g. Jet, Microsoft Excel VBA)
• Procedures. Address issues such as:
  • Scope (global vs. form-level)
  • Function vs. Sub procedure

GUI Design

Having standards in place for graphical user interface (GUI) design should be as non-controversial as for naming or programming. With the newness of the Windows operating system environment and the recent "down-sizing of America," this does seem to be an area that lags behind the more "technical" areas in terms of standards implementation. Custom corporate applications have a particular set of interface issues that developer workgroups should define standards for; many of these issues are not discussed in the standard references (for example, The Windows Interface: An Application Design Guide, Microsoft Press®, 1992 is essentially written as a guide for commercial application developers). We don't have time in this presentation to provide a complete guide to GUI design; rather, we'll present an overview of the areas you should have standards in place for, and give what we feel are some of the "greatest hits" of required GUI design standards.

General Issues

• Proper keyboard support

  For any application requiring appreciable head-down data entry, this is probably a good rule to have in place. All menu commands need to be keyboard accessible (with either mnemonic keys or keyboard shortcuts), and all major system commands should be available from a menu. Remember, it's not the Windows interface that's keyboard-unfriendly, it's the GUI designer of a particular application.

• Textual feedback to the user

  Text messages, especially in informational and warning dialogs, need to be properly and consistently conveyed. Here are some worthwhile rules of thumb you should consider incorporating into your standards:

  • Avoid technical jargon.
  • Limit messages to 2-3 lines.
  • Avoid phrasing that blames the user.
  • Avoid the use of contractions.
  • Left-align multiple line messages.
  • Never, ever, ever include misspellings, bad grammar or incorrect pronunciation. If your programmers wear their bad grammar like a badge, that's all the more reason to have someone who doesn't review the application!
• Proper font usage

  Table 1 provides a simple guide to proper Windows font usage, adapted slightly for custom corporate projects. Something like this should be a part of your GUI design standards document.

Table 1: Proper font usage for custom applications

• Correctly labeling interface controls

  Inconsistently labeled interface controls (text boxes, combo and list boxes, option buttons and groups, and so forth) can do as much as any single factor to give an application a hurried, unprofessional look. Without going into detail here, we'll recommend you define standards for:

  • Capitalization
  • Alignment and positioning
  • Use of colons and other highlighting schemes

Windows and Dialogs

• Different window types/MDI Applications

  Windows applications are made up of three types of windows: application windows, MDI windows and dialog windows. MDI (for multiple document interface) windows are useful in applications where different views are required of the same underlying data. Since this is the situation in many moderate to complex Visual Basic projects (especially database applications), you should consider the MDI interface for your applications.

  Visual Basic has excellent built-in support for MDI applications. One project can have one MDI parent window, and the MDIChild property is set to True for every window you want to be an MDI child window. Once you've determined that an application should be MDI, here are some tips you might find helpful.

Tip: MDI Applications. Even though child windows, according to the standard references, should be completely sizable, we've found a slight departure from this works best in custom application work. Since many data windows present fixed fields and controls on the form, make these MDI child windows fixed in size and not maximizable. Give them these property settings:

Tip: Reusable Interface Components. Better yet, create template forms for your MDI parent and child forms. Even though Visual Basic doesn't have the concept, as does Access, of a "normal" form on which default properties can be based, we've found that template forms can be used to much the same purpose. For example, template forms can be created with fairly extensive menu systems, both to demonstrate to your developers what your standard menus are for MDI parent and child forms, and to save them the time of having to create them over and over again. We keep our template forms in a shared project called GLOBALS.MAK. This not only contains re-usable interface components, but also our standard modules of generic procedures, global and constant declarations and so forth.

• Using Windows common dialogs

  Few things are more truly reusable than the resources provided by the underlying operating environment. In Windows 3.1x applications, you can use the File Open, File Save As, Color, Font, and Printer dialogs by either making a Windows API call or by using the common dialog custom control in Visual Basic. Getting used to using these operating system resources is important, and will become even more so as your applications make the transition to the Windows 95 environment. Windows 95 will make available a much higher level of functionality in the form of dialogs accessible by API calls, as long as you're programming to the Win32® API set. Some of these will be a rich-text editor with built-in spell checking, and lots of interesting interface gadgets, such as gauges, scroll controls, and so forth.

Menus

• Menu types

  Given the three primary menu types Windows supports — pull-down, pop-up and cascading — you should define a standard for when to use what type of menu. In general, most Windows 3.1x Visual Basic applications rely primarily on pull-down menus. The use of cascading menus has been discouraged in the Windows 3.1 environment, but the Windows 95 user interface relies heavily on cascading menus, and due to their easier operation it actually improves a user-interface somewhat.

  You should also define a standard for when to use pop-up (context-sensitive) menus, since users are beginning to get used to their availability in popular application suites such as the Microsoft Office.

• Menus in custom applications

  In database applications, certain types of forms are so common that you can define a good standard for the menus that should be available for every form of a specific. For example, in our work we've defined a data window as any window that provides record or row-based navigation of an underlying table or set of records. You'll save a lot of time and develop more consistent and professional-looking applications if you define your own standard. Figure x-x shows one of the standard "Record" menus we use in our applications' data windows. Again, this form is included in the session code.

Tip: Copying and Pasting Menus. Always remember to save your Visual Basic forms as text files (make sure the "Save as Text" checkbox is selected in the "Save File As" dialog). If you do, you can reuse interface components such as menus, even if you don't implement the complete forms-template approach we discussed above. You can do this by loading the form definition .FRM file for any of the forms in your application, copying the menu definition portion of the file to the clipboard, and pasting it into the proper location in a "target" form requiring the same menus. For example, Listing 1 shows the definition of a "Records" menu that could make sense in any table-based form.

Listing 1: Menu Definition Section of a .FRM File

Begin Menu mnuRecords 
      Caption         =   "&Records"
      Begin Menu mnuRecordsGoto 
         Caption         =   "&Go To"
         Begin Menu mnuRecordsGotoFirst 
            Caption         =   "&First"
         End
         Begin Menu mnuRecordsGotoLast 
            Caption         =   "&Last"
         End
         Begin Menu mnuRecordsGotoNext 
            Caption         =   "&Next"
         End
         Begin Menu mnuRecordsGotoPrevious 
            Caption         =   "&Previous"
         End
      End
      Begin Menu mnuRecordsSep1 
         Caption         =   "-"
      End
      Begin Menu mnuRecordsSort 
         Caption         =   "&Sort..."
      End
      Begin Menu mnuRecordsFind 
         Caption         =   "&Find..."
         Shortcut        =   ^F
      End
      Begin Menu mnuRecordsSep2 
         Caption         =   "-"
      End
      Begin Menu mnuRecordsAdd 
         Caption         =   "&Add"
         Shortcut        =   ^A
      End
      Begin Menu mnuRecordsDelete 
         Caption         =   "&Delete..."
      End
      Begin Menu mnuRecordsSave 
         Caption         =   "&Save"
         Shortcut        =   ^S
      End
   End

Custom Controls and Add-Ons in Visual Basic

Given the popularity of .VBX custom controls and add-on tools, you really have to define a standard toolset for your Visual Basic development teams. If you don't, your applications will not have a consistent look and feel, and your developers will continually be wasting time learning the latest cool tool. Without recommending any specific tools, here are the categories of add-ons our we've defined standards for:

• Enhancing the Visual Basic design environment
• Collections of enhanced/data aware versions of "standard" controls
• Collections of non-standard controls (e.g., tab controls, customizable toolbars, etc.)