VB "Working" User Interface Standards ------------------------------------- The following user interface guildelines are followed by Galacticomm software engineers when developing client apps. Common Elements of User Interface --------------------------------- Complex apps that require a common toolbar and menu bar across multiple windows should use MDI. MDI apps take up a lot of screen space, so should not be used where unnecessary. Forms should have grey backgrounds. 3D controls should be used where possible, except for 3D menus. Text boxes and list/combo boxes should have white backgrounds. Otherwise, most other controls should have grey backgrounds. Every app should have a menu bar on its main form. Each of these menu bars should include "File", "View", and "Help" menus. The "View" menu should include a "Toolbar" option to enable/disable the toolbar. This option should be sticky across sessions (saved as system- *and* user- specific). The "Help" menu should include a "Toolbar" option to get straight to toolbar help. If the only options require children, "Window" menus should go away when on MDI parents with no children. Every app should have a toolbar. A toolbar will be made up of a panel with a 3D command button array on it. Each 3D command button will have a 32x32 pixel graphic (usually an icon) on it. A different graphic should be used to represent disabled buttons. If a toolbar button needs to stick in the down position, use a 3D group button. In general, non-toolbar buttons should be text-based. Graphics-based buttons should only be used in cases where the graphic is easily understood and the button represents a common activity that the user will see in multiple places. OK buttons should normally have the "default" property set and no hotkey for ALT-O. If there is a multi-line text box on the same form as an OK button, the OK button should not be default, and have a hotkey of ALT-O instead. When the OK button isn't currently a valid selection on a form, it should be disabled. Close and cancel buttons should have the "cancel" property set, and no hotkey for ALT-C. Standard list boxes should be 3D list boxes in 2D mode. Combo and drop-down list boxes should be the same. Drive, directory, and file list boxes should be standard 2D list boxes. Don't enable "integral sizing" on list boxes. The white sliver in combo boxes should be covered with picture boxes. List boxes that need to stick out should be on inset panels. A label should be bold unless it itself is labeled by another bold label. Labels over text or list boxes should be capitalized as if they were mini-sentences: usually only the first letter of each label should be capitalized. Labels that need to stick out should be on inset panels. (Nothing in excess.) Text boxes that can't be edited by the user should be enforced as read-only. To jazz up the interface a bit, decorative icons should be placed on high profile forms, as appropriate. List boxes should use graphics on the left to distinguish different types of list box entries, as appropriate. Modal forms should have "fixed double" borders. Modeless forms should have "sizable" or "fixed single" borders. About boxes should be modeled after the OSM's About box. Text boxes prompting for numbers should have spinner controls next to them. A "F&ind..." button should appear near (usually beside) text boxes prompting for User-IDs. Use ALT-I as the hotkey unless there's a conflict on your form. (The reason for ALT-I to begin with is that it is less likely to be in conflict than ALT-F.) List boxes, when the main attraction on a form, should generally default to having the first item highlighted. In theory, our text boxes should behave the way most others do: when you TAB to them, they highlight their text. Unfortunately, this isn't easily supported across the board in VB. So, for now, our text boxes should behave the way VB wants them to: you have to highlight text manually (if you do, leave, and then come back, it remembers). This way, our interface is at least consistent. Dates and times should appear according to the current Windows international settings. Use TIMEFMT as the Format$() method for times. Use DATEFMT, MDATEFMT, or LDATEFMT as the Format$() method for dates. To make dates editable, use masked edit boxes with masks of "##/##/##". You'll need to call mebdate() to convert dates correctly to this format. Where possible, "User-ID" should be referred to as "user" to C/S users. ("Enter a partial user" is a good example of when to stick with "User-ID".) The term "client/server" should always appear in one of the following forms: "C/S", "client/server", "Client/server", or "Client/Server". Unless abbreviated, capitalize as if "client" and "server" were two separate words. A client/server application can be referred to as an "application" or an "app". An application ID should be referred to as an "App-ID". A system ID should be referred to as a "System-ID". Generally, an app should not pop up an error message when unable to connect to the server. Just ignore whatever action (usually a button click) that required the connection. If the user clicked "cancel", he knows why the action he just selected didn't actually happen: he cancelled it. If the connection failed for some other reason, the OSM notifies the user via pop-up boxes as appropriate. So, it will be clear to the user what happened and why in most (if not all) cases. Sizes and Shapes ---------------- The VB grid should be set to 60x60 and enabled. By default, try to keep things aligned to the grid. But, you will have to "touch up" some object positions by hand (like labels next to text boxes). Standard buttons should be 960x360 twips. "Find..." buttons should be 855x315 twips. Standard labels should be 240 twips high. (If your labels automatically round to be 252 twips high, that's OK too.) Toolbar buttons should be 660x660 twips with standard 32x32 16 color graphics on them by default. The siztbar() routine should be used to automatically size toolbar buttons based on current video mode. Positioning ----------- Objects should generally be either 1 or 2 grid snaps away from each other. Like objects should be 1 grid snap apart (SAMEDIST). Unlike objects should be 2 grid snaps apart (DIFFDIST). An example of like objects: buttons in the same group. Examples of unlike objects: button and form edge, button and frame edge, text box and form edge, etc. The position of the main app form(s) should be sticky across sessions (saved as system- *and* user-specific). Other forms should either be positioned relative to the main form location or centered on the screen. In many cases, forms should appear in positions that make sense relative to other forms (see most existing Windows applications for examples). In order to support this, never move a form's position at design-time unless you either intend its position to change at run-time, or you know for a fact that the form is explicitly positioned at run-time. Toolbar buttons should be grouped logically. Two toolbar buttons should be right up against each other, or DIFFDIST apart. Labels over text or list boxes should be (vertically) right up against what they label. Saving Preferences ------------------ Client-side user preferences (like download directories, window postions and sizes, etc.) should be saved as system-, app-, and user-specific. This means that a user will have to set his preferences the way he'd like for each system he uses. This approach allows the most user flexibility when using different systems for different things, as well as keeping different users' preferences separate when multiple users share one Worldgroup Manager on a home computer.