Table Of Contents ALF GUIDE AdventNet Look and Feel Guidelines... 3 Preface... 4 PART I : OVERVIEW... 6

Transcription

1

2 Table Of Contents ALF GUIDE... 3 AdventNet Look and Feel Guidelines... 3 Preface... 4 PART I : OVERVIEW : The AdventNet Look and Feel : The Java Look and Feel : The Java Foundation Classes... 9 PART II : APPLICATION DESIGN : Design Considerations : Visual Design : Application Graphics : Behavior PART III : COMPONENTS OF JFC : Windows and Panes : Dialog boxes and Alert boxes : Menus and Toolbars : Basic Controls : Text Components : Selectable Lists, Tables, and Tree Components PART IV : COMPONENTS OF JFC ( ADVANCED) : Introduction to JFC Components - Advanced Topics : Windows : Menu bar : Contextual Menus : Toolbar : Status bar : Contextual Help : Graphs : Behavior : Idioms : Responsiveness : Wizards : I18N Support in UI : Events and Alarms : Keyboard Shortcuts, Mnemonics, and Other Keyboard Operations AdventNet Inc. 1

3 PART V : EMBRACING ALF : Things to do Before and After : User Interface Checklist : User Centered Design Development process PART VI : APPENDIX Appendix i : Localization Word Lists Appendix ii : Switching Look and Feel Designs Appendix iii : Bibliography AdventNet Inc. 2

4 ALF Guide AdventNet Look and Feel Guidelines - For Java Applications (Version - 2.0) AdventNet, Inc. All Rights Reserved. "AdventNet", the oval AdventNet logo, "Excellence Matters" and "The Internet Management Infrastructure Company" are trademarks of AdventNet, Inc. All other trademarks are the properties of their respective holders. AdventNet Inc. 3

5 Preface The AdventNet Look and Feel Guidelines (in short, ALF Guide), second edition, provides essential information for those who are indulged in developing Graphical User Interfaces across AdventNet, especially using Java Programming Language. This guide is written based on the Look and feel specifications provided by Sun Microsystems. What is ALF Guide? ALF Guide provides a series of Look and Feel guidelines for the Java Applications, HTML applications, Help Documentations etc. ALF Guide is the bible for developing user interfaces across AdventNet products and the applications built on AdventNet products to maintain consistency. As said, ALF Guide adopts most of the guidelines from Sun Microsystems look and feel guide. This guide also has the essence extracted from the guidelines of Microsoft, IBM, Apple. Who should use this Guide? This guide basically addresses to the User Interface Engineers, Usability Engineers, Software Development Engineers. Some part of the guide addresses to the Technical Writers and the Quality Assurance Engineers, for their participation in writing user interface texts and developing user centric test plans. Otherwise, this book can be read by anybody, who has interest in user interface designing and usability. This book presumes that the reader has some basic idea about user interfaces (not necessarily be Java) and their usability. What is in this Guide? Basically this guide is divided into six parts, Part I - Overview Part II - Application Design Part III - Components of JFC Part IV - Components of JFC ( Advanced ) Part V - Embracing ALF Part VI - Appendix This section covers the need of AdventNet Look and Feel, Java Look & Feel and the Java Foundation Classes. This sections provides the general guidelines for designing an application, various factors that should be addressed while designing an application etc. This section deals with the complete set of components provided by Java Foundation Class library. The appearance and behavior of each component is covered in detail. The advanced topic is a extension of the previous section, with much more explanation in a user centric perception. This part offers several guidelines to stick on to the standards while designing & developing an user interface. This section also provides guidelines for user interface compatibility testing and usability testing and many more. This section includes the stuffs like localization word lists, graphics repository and a guideline for switching look and feel designs. The guide provides industry standards for Designing an application and testing it for consistency and usability. AdventNet Inc. 4

6 All the graphics (including screen shots) throughout the guide are designed / edited using Adobe Photoshop. Image References Note: This image implies any important Note or Tip provided to the user as an additional information in this document. Copyrights Adobe and Photoshop are the registered trademark of Adobe Systems Incorporated. Java TM the registered trademark of Sun Microsystems, Inc. AdventNet Inc. 5

7 Part I : Overview 1: The AdventNet Look and Feel The Look and Feel refers to the general appearance and operation of a user interface. The AdventNet Look and Feel (ALF) defines the specifications for the appearance and behavior of each user interface across the products of AdventNet. This chapter talks about the following: 1.1 Objective 1.2 How Consistency plays a vital role in User Experience? 1.3 How ALF has been defined? 1.4 Evolution 1.1 Objective If we look at number of successful products, we could easily make out that their success has been determined through various factors like, 1. Understandability 2. Predictability 3. Learnability 4. Memorability and 5. User Satisfaction The above factors will be applied automatically if there is a consistent appearance and behavior, for all the user interfaces and other components in the product. The consistency can be achieved only by defining specifications for the appearance and behavior of each user interfaces and that constitutes to a new look and feel. Effective applications are consistent in a number of different ways. Consistency in the visual interface helps people learn and then easily recognize the graphic language of the interface. Consistency in the behavior of the interface means that people have to learn how to do things such as clicking and pointing only once; then they can explore new applications or new types of features using skills that they already have. In general, consistency benefits the typical user, who usually divides working time among several applications, and it benefits software developers because their users can build on prior experiences with elements in other applications when learning how to use a new application. The following are some questions you can ask yourself when thinking about consistency in your product. Is your product consistent within itself? with earlier versions of your product? with AdventNet interface standards? in its use of metaphors? with people's expectations? AdventNet Inc. 6

8 Finally, the main objective of defining a separate look and feel for the products in AdventNet is to promote consistency and enhance user satisfaction. As per the analysis of various successful products, the success lies in the hands of consistency and it can only be achieved through a simple and effective specification for each components. 1.2 How Consistency plays a vital role in the user experience? Note that the most difficult kind of consistency to achieve is matching people's expectations. Because you often face a wide audience and a range of expertise, it's difficult to meet the expectations of everyone. You can address this problem by carefully weighing the consistency issues in the context of your target audience and their needs. The next time you read your favourite newspaper or magazine, take a good look at the cover or front page. Then, look through each section. What is the color scheme? What makes each section different but the same? Where are the editorials? Where are the feature stories? How do you know the weather is the back page or the police report is on page 3 of your local newspaper? How do you know that the letters to the editor are in the front of your favorite magazine or that reviews are in the back? One Word - Consistency It is important to consider consistency of your application while planning your User Interface, setting up a template, using some of the same graphic(s) on every window, dialog or wizard. With every screen looking the same and every screen feeling the same, users are more comfortable about using your application, knowing there are no shocking surprises waiting on the next click. It also gives users a better sense of "where they are now, what they needs to do and what would be the system's response on doing that". 1.3 How ALF has been defined? Sun Microsystems, has Design guidelines which talks about the look and feel of various user interface components. Sun's look and feel is named as Java Look and Feel (informally called as Metal Look and Feel, JLF). Sun has divided its specifications into two guides called, Java Look and Feel Design Guidelines 2.0 and Java Look and Feel Design Guidelines - Advanced Topics. AdventNet Look and Feel is the resultant when a formula E 2 C (Embrace, Extend and Customize) is applied on Java Look and Feel Guidelines. The idea is to have ALF as a layer to the top of JLF. ALF embraces most of the design guidelines provided by Java, it extends the concept where ever there needs to be more specifications and it customizes the guidelines where there is a contradiction or difference in implementation. E 2 C (JLF) => ALF The above derivation explains the concept in a more precise way. To be more clear ALF embraces the JLF design guidelines (Metal look and feel of Java) and it mostly extends / customizes the Java Look and Feel guidelines - Advanced Topics to make it more specific to suite AdventNet's products. 1.4 Evolution The AdventNet Look and Feel keeps evolving by leaving a way for the next generation user interfaces. In future it might differ from JLF design guidelines and can have its own user interface design completely. The Idioms gallery will have a handful of idioms that can be reused to maintain consistency across the products. AdventNet Inc. 7

9 2: The Java Look and Feel Sun Microsystems had set a unique look and feel that supports designers and developers to develop User Interfaces that is consistent in all platforms. We adapt the look and feel specifications provided by Java. The Java Look and Feel guidelines addresses all types of users, including those with physical and cognitive limitations. The chapters that are covered in Java Look and Feel guidelines are, as follows : 2.1 The Java Look and Feel 2.2 Fundamentals of the Java Look and Feel 2.3 Visual Tour of the Java Look and Feel o MetalEdit Application o Retirement Savings Calculator Applet All the links specified above will lead to Sun Microsystem's website ( AdventNet Inc. 8

10 3: The Java Foundation Classes This chapter discusses on the following topics in details, 3.1 The Java Foundation Classes 3.2 Java 2 Software Development Kit o Java Foundation Classes o Support for Accessibility o Support for Internationalization 3.3 User Interface Components of the JFC o Pluggable Look and Feel Architecture o Example Model and Interfaces o Client Properties o Major JFC User Interface Components 3.4 Look and Feel Options o Java Look and Feel - the Recommended Design o Supplied Designs AdventNet Inc. 9

11 Part II : Application Design 4: Design Considerations To create a well-designed applications, you must consider factors that appeal to the widest possible audience. For example: No architect would intentionally design a building to exclude people who use wheelchairs. Likewise while designing an user interface you should consider a wide range of users, including the users with physical and cognitive limitations. This chapter covers special user interface design considerations, such as choosing an applet (for security), accessibility, and localization. 4.1 Choosing an Application or an Applet o Distribution o Security Issues o Placement of Applet 4.2 Designing for Accessibility o Benefits of Accessibility o Accessible Design 4.3 Planning for Internationalization and Localization o Benefits of Global Planning o Global Design AdventNet Inc. 10

12 5: Visual Design Visual design and aesthetics brings user confidence in and comfort with your application. A polished and professional look without excess or oversimplification is not easy to attain. This chapter discusses these high-level, visual aspects of Java look and feel applications. 5.1 Visual Design 5.2 Themes o Colors o Fonts 5.3 Layout and Visual Alignment o Design Grids o Text Layout o Between-Component Spacing Guidelines o Spacing Guidelines for Specific JFC Components 5.4 Text in the Interface o Headline Capitalization in English o Sentence Capitalization in English 5.5 Animation Fonts All fonts in the Java look and feel are defined in the default Java look and feel theme as Dialog. Fone Default Theme Use Dialog 12-point bold window titles, sub headings in Alert boxes or dialogs Dialog 10-point plain Keyboard shortcuts in menus and tool tips Dialog 12-point plain Tree components and tool tips Dialog 12-point plain Buttons, check boxes, menu titles, labels, Text fields and tables Table Java Look and Feel theme defines the font style as Bold for the interfaces like Buttons, Check boxes, Radio buttons, Menu titles, Labels etc. But it is wise to use the plain style for the above said components, the sub headings used in the dialog boxes can be in bold style. 2. For more information refer Fonts in Java Look and Feel Design Guidelines - Ed2. AdventNet Inc. 11

13 6: Application Graphics This chapter provides details on: The use of cross-platform color The design of application graphics, such as icons, button graphics, and symbols The use of graphics to enhance your product and corporate identity Because the quality of your graphics can affect user confidence and even the perceived stability of your application, it is wise to seek the advice of a professional visual designer. 6.1 Working With Cross-Platform Color o Working With Available Colors o Choosing Graphic File Formats o Choosing Colors o Maximizing Color Quality 6.2 Categorizing Application Graphics 6.3 Designing Icons o Working With Icon Styles o Drawing Icons 6.4 Designing Button Graphics o Using Button Graphic Styles o Producing the Flush 3D Effect o Working With Button Borders o Determining the Primary Drawing Area o Drawing the Button Graphic 6.5 Using Badges in Button Graphics o Menu Indicators o New Object Indicators o Add Object Indicators o Properties Indicators o Combining Indicators 6.6 Designing Symbols 6.7 Designing Graphics for Corporate and Product Identity o Designing Splash Screens Copyright Information Configurable Contents o Designing About Boxes o Designing Login Screens AdventNet Inc. 12

14 6.7 Designing Graphics for Corporate and Product Identity Application graphics present an excellent opportunity for you to heighten your corporate or product identity. This section presents information about splash screens, About boxes, and Login splash screens. Note: Use the JPEG file format for any photographic elements in your splash screens and About boxes Designing Splash Screens A splash screen is a plain window that appears briefly in the time between the launch of a program and the appearance of its main application window. Splash screens disappear when the application is ready to run. The splash screen occupies the user's attention while your startup procedures are executing, giving the illusion that the application is loading faster. When the startup procedures are completed, you can load your first screen / window and unload the splash screen. In designing a splash screen, it's a good idea to keep it simple. If you use large images or a lot of controls, the splash screen itself may be slow to load. AdventNet Inc. 13

15 1. The splash image should have all the necessary details like, 1. Company Logo 2. Product "Licensed to" information 3. Product Name with version 4. Progress status 5. Support mail id, company website address and copyright information. 2. The size of the splash screen should be 500 x 350 pixels (width x height). 3. Place your company logo at the top left corner of your splash screen. The logo size used is 123 pixels wide and 36 pixels height. 4. Provide the License details like "Licensee Name, Organization and the License number" at the top right side. 5. You can change the product name and the image present in the splash screen but the placement of the product name, image and other stuffs in the splash screen should be the same through out AdventNet. 6. Provide Release Number just below the Product title. The Release number is just a JLabel where the number will be updated on applying the Service Packs or any Software upgrades for that product. 7. Provide a progress bar in the splash screen to visually interpret the initialization of the product. During the product startup, you can intimate the users about various internal processes like, Loading menus, Loading toolbar, loading fonts etc. and that will enhance user interaction. 8. Use dynamic texts for displaying the state of the product during initialization. This type of texts keep users informed about the processes going on and keep them in control until the product gets started. 9. Provide the support mail id and the copyright information in the bottom left side and the website address in the bottom right side Copyright Information The Copyright message can be either, (current year) AdventNet Inc. All Rights Reserved. (or) 1996 (product started year) (current year) AdventNet Web NMS (product name) AdventNet Inc. All Rights Reserved Configurable Contents Table 6.1 Every product has a splash screen that contains the details of that particular product. Hence it is very difficult to maintain consistency between splash screens. But standardizing the placement of contents in the splash screen can overcome this. The configurable portions in a splash screen are, 1. The image and the product name (called as the visual identifier of the product) 2. The support mail id and the copyright information AdventNet Inc. 14

16 Figure Designing About boxes 1. An About box is a dialog box that contains basic information about your application. 2. Users typically display About boxes by choosing the "About Application" item from the Help menu. 3. An About box might contain the following elements: Product Name Version Number Build Number Service Pack applied Person the software is licensed to License key Evaluation days remaining (if the product is not licensed) Contact Information like, Company Address, Sales Id, Technical Support Id, Company Web site address etc. AdventNet Inc. 15

17 Figure The size of the about dialog is 556 x 440 pixels. The size is very reasonable to withhold all the above said criteria. 5. Ensure that the normal text is differentiated from the links such as support mail id, Website address etc. The links provided to the website address should take the user to the appropriate site and the mail addresses should open up the default mailing client configured in the user's machine. 6. Do not exceed the size of the dialog at any cost. If you have any additional contents, display it in the JTextArea found inside the dialog. 7. Ensure that you have provided a scroll bar (vertical) to read the complete content in the Text area. Align the contents in such a way that there is no need for Horizontal scrolling. 8. Provide an image in the left side, so that the dialog becomes more attractive even with all the verbal descriptions. The size of the image should be 144 x 350 pixels and it occupies one third of the entire dialog. 9. The image can have the product logo, company logo or any other collages that is relevant to that context. 10. Provide the warning and copyright messages as a last item. A proper separation should be provided between the other details and this type of legal warnings. 11. Because the dialog box title bar might not include a Close button on all platforms, always include a Close button in your About boxes so that users can dismiss them after reading them. (Follow the guidelines for button placement described in Command Buttons in Dialog Boxes ) 12. Pressing Escape (Esc) closes this dialog. AdventNet Inc. 16

18 6.7.3 Designing Login Screens To start things off, users are presented with a screen where they should enter the Authentication / Authorization information that will take them inside. The elements of this screen might include: Label and text field for a Login user name Label and password field Labels and interactive components (such as combo boxes) for any other information required by the system Buttons for logging in and canceling the Login splash screen If you want to increase the chance of users viewing your splash screen, it is a good idea to combine the Login window and splash screen. Provide a way for users to exit the Login splash screen without first logging in (if it is possible for users to do anything on the system without first logging in). A sample Login screen from one of the products of AdventNet is shown below. Essential factors in a Login screen Figure Make your Login screen as simple as possible with minimal data entry for the users. As you might know that "The first impression is the best impression", it is very important to make your Login dialog very simple. Because the first screen of your application, that your users will work with, is your Login dialog. 2. Ensure that your Login screen reduces the burden of entering values in each and every field of your dialog. Provide "Default" values wherever possible. AdventNet Inc. 17

19 3. Providing default values not only reduces the data entry time for the user but it also avoids erroneousness. 4. Group the fields accordingly that the mandatory fields gets into the top, then the next priority fields and so on. 5. In a Login dialog there should be only 2 to 4 mandatory fields, more than that will cause a negative impact on the user about the application. More over this will create a deception among the users. 6. Make the "Login" button as the default button in your dialog, so that the user hits the enter / return key to enter into the application. Pressing Escape (Esc) cancels the process and closes the dialog. 7. The Error / Warning messages should be very specific so that user knows the reason for Login failure. 8. No body is ready to read a message like, "your entry in the field 1 or field 2 or field 3 may be incorrect". Make it very clear and tell the user what is wrong like "Your password is incorrect" or "The Host is no longer existing". 9. Optionally, provide a help button if your Login dialog has too much of data fields (i.e. more than 3 mandatory entries) that is not self explanatory. 10. Do not provide resizing option to your Login screen. Design it in such a way that all the fields fits in that compact model irrespective of the operating system. AdventNet Inc. 18

20 7: Behavior Users interact with the computer by means of the mouse, the keyboard, and the screen. (Throughout this book, "mouse" refers to any pointing device, including standard mouse devices, track balls, track pads, and so forth.) Such interaction constitutes the "feel" portion of the look and feel. This chapter describes mouse operations, pointers, and drag-and-drop operations. It discusses keyboard operations, including the use of keyboard focus, keyboard shortcuts (Refer AdventNet specific keyboard shortcuts), and mnemonics in Java look and feel applications. It also offers guidance on how to provide feedback regarding application progress or status. 7.1 Mouse Operations o Pointer Feedback o Mouse-over Feedback o Clicking and Selecting Objects o Displaying Contextual Menus 7.2 Drag-and-Drop Operations o Typical Drag and Drop o Pointer and Destination Feedback 7.3 Keyboard Operations o Keyboard Focus o Keyboard Navigation and Activation o Keyboard Shortcuts o Mnemonics 7.4 Operational Feedback o Progress Animation o Status Animation 7.5 Design for Smooth Interaction o Initial Focus o Navigation o Password Field o Status and Error Messages o Text Selection and Filled Text Fields AdventNet Inc. 19

21 Part III : Components of JFC 8: Windows and Panes In a Graphical User Interface (GUI) application, a window is a rectangular area of the screen where the application displays output and receives input from the user. Therefore, one of the first tasks of a GUI application is to create a window. A window shares the screen with other windows, including those from other applications. Only one window at a time can receive input from the user. The user can use the mouse, keyboard, or other input device to interact with this window and the application that owns it. Golden Ratio While designing, make sure that the windows and dialogs have the correct aspect ratio, (Golden Ratio). Any object that satisfies the rule of Golden ratio looks aesthetically pleasant and consistent. Your Television screen, Computer Monitor, Artwork Frame are examples for the golden ratio. We can say that two lengths are in the Golden ratio if the ratio of the Longer Dimension (LD) to the Shorter Dimension (SD) lies between 1 and <= LD/SD <= Table 8.1 The Golden Ratio is not only a mathematical notation for the geometric objects, but also a way to measure beauty. Golden ratio can occur anywhere, in reality all the beautiful things that nature provides will comply to this ratio. You can imagine any thing that comes to your mind, say a Human face, a Petal, a Star or a Pyramid. Now draw a tangential box outside the circumference of the object of your choice, to your surprise the box will be in golden ratio. It is never a magic, but it is the way nature defines beauty. Figure 8.1 AdventNet Inc. 20

22 This chapter covers more areas in detail, they are: 8.1 Windows and Panes 8.2 Anatomy of a Primary Window 8.3 Constructing Windows o Primary Windows o Secondary Windows o Plain Windows o Utility Windows 8.4 Organizing the Contents of Windows o Panels o Scroll Panes o Tabbed Panes o Split Panes 8.5 Working With Multiple Document Interfaces o Backing Windows o Internal Windows o Secondary Windows o Internal Utility Windows 8.6 Window Titles o Title Text in Primary Windows o Title Text in Secondary Windows o Title Text in Internal Windows AdventNet Inc. 21

23 9: Dialog boxes and Alert boxes This chapter discusses about Dialog boxes, Classifications of dialog boxes, behavior etc. Refer the below links to explore more, 9.1 Dialog Boxes and Alert Boxes 9.2 Modal and Modeless Dialog Boxes 9.3 Dialog Box Design o Tab Traversal Order o Single-Use and Multiple-Use Dialog Boxes o Command Buttons in Dialog Boxes 9.4 Common Dialog Boxes o Find Dialog Boxes o Login Dialog Boxes o Preferences Dialog Boxes o Progress Dialog Boxes 9.5 Color Choosers 9.6 Alert Boxes o Error Alert Boxes o Info Alert Boxes o Warning Alert Boxes o Question Alert Boxes> o Fold and Unfold Alert Boxes o Progress Alert Boxes 9.7 Guidelines for writing Alert Box Messages 9.8 Command Buttons in Alert Boxes 9.9 Terminology 9.10 Phrasing Alert Box Messages Note: Make sure that all your windows and dialogs maintains the Golden ratio. 9.6 Alert Boxes Basic properties of an Alert Box : 1. A secondary window's purpose is to provide concise, predefined information. Avoid defining an Alert window to be resizable. If the user needs to resize your alert, the text is probably not concise enough. 2. An alert provides information about the state of the application system, or asks for essential information about how to proceed with a particular task. 3. It is distinct from other types of window in that it is not directly requested by the user, and usually contains a message or a question rather than editable controls. AdventNet Inc. 22

24 4. Since alerts are an unwelcome intrusion into the user's work, do not use them except where necessary to avoid potential data loss or other serious problems Error Alert Boxes Display an error alert when a user-requested operation cannot be successfully completed. Present errors caused by operations not requested by the user by another means, unless the error could result in data loss or other serious problems Images 1. Uses the stock error icon. Error Alert Image Title bar Message Table Use the title bar of a alert box to appropriately identify the source of the message usually the name of the object from which the alert window was popped up. 2. If the message results from a internal frame in a Multiple Document Interface (MDI), the title text is the name of that frame, followed by the application name. 3. If the message results from a non MDI object, then use the application name as the title bar text. Refer Figure Do not use descriptive text such as "Error" for alert box title text. The alert symbol already conveys the nature of the message. Also, never use the word "error" in the title text. The word "error" provides no useful information Guidelines on writing "Error" Messages 1. Refer Section General guidelines on Writing Alert box messages Terminologies 1. Refer Section General guidelines on using Terminologies in Alert boxes Command Buttons 1. Most Error Alert boxes will be equipped with a OK button. 2. The button is placed in the bottom-right corner of the alert. Pressing "Enter" would dismiss the error alert. 3. A convenience button may be present, to allow immediate handling of the error. For example, a Format... button in a "This disk is not formatted" alert. Place this button to the left of the Default button of the Alert box. Refer Default Button in Dialog boxes. 4. The Fold and Unfold alert boxes can be used to display an Error message. The details about the occurrence of the error can be communicated to the user by unfolding the dialog box. But use fold and unfold error dialogs very sparingly and reasonably Refer Error Alert Boxes provided in Java Look and Feel design guidelines. AdventNet Inc. 23

25 9.6.2 Info Alert Boxes Use an information alert when the user must know the information presented before continuing, or has specifically requested the information. Present less important information by other means such as a status bar message Images 1. Uses the stock error icon. Information Alert Image Title bar Message Table Use the title bar of a alert box to appropriately identify the source of the message usually the name of the object from which the alert window was popped up. 2. If the message results from a internal frame in a Multiple Document Interface (MDI), the title text is the name of that frame, followed by the application name. 3. If the message results from a non MDI object, then use the application name as the title bar text. Refer Figure Do not use descriptive text such as "Information" for alert box title text. The alert symbol already conveys the nature of the message Guidelines on writing "Information" Messages 1. Refer Section General guidelines on Writing Alert box messages Terminologies 1. Refer Section General guidelines on using Terminologies in Alert boxes Command Buttons 1. Most Information Alert boxes will be equipped with a OK button. 2. The button is placed in the bottom-right corner of the alert. Pressing "Enter" would dismiss the alert. 3. Do not use Fold and Unfold alert boxes for information alert boxes. Refer Info Alert Boxes provided in Java Look and Feel design guidelines Warning Alert Boxes Alerts the user to a condition or situation that requires the user's decision and input before proceeding, such as an impending action with potentially destructive, irreversible consequences. The message can be in the form of a question for example, "Save changes to MyProject.proj?" Images 1. Uses the stock error icon. Table 9.3 Warning Alert Image AdventNet Inc. 24

26 Title bar Message 1. Use the title bar of a alert box to appropriately identify the source of the message usually the name of the object from which the alert window was popped up. 2. If the message results from a internal frame in a Multiple Document Interface (MDI), the title text is the name of that frame, followed by the application name. 3. If the message results from a non MDI object, then use the application name as the title bar text. Refer Figure Do not use descriptive text such as "warning" or "caution" for alert box title text. The alert symbol already conveys the nature of the message Guidelines on writing "Warning" Messages 1. Refer Section General guidelines on Writing Alert box messages Terminologies 1. Refer Section General guidelines on using Terminologies in Alert boxes Command Buttons 1. The Warning Alert Boxes will be equipped with the buttons relevant to the context displayed. You can abort or continue the action accordingly. 2. The buttons may be "OK", "Cancel" or "Yes", "No", "Cancel" (optional) with "Help" as optional button. Refer Figure The buttons are placed in the bottom-right corner of the alert. 4. Pressing "Enter", probably executes the default option associated with the Dialog. The default option should be the safer side of the user. Refer Default Button in Dialog boxes. 5. Do not use Fold and Unfold alert boxes for warning alert box. Refer Warning Alert Boxes provided in Java Look and Feel design guidelines Question Alert Boxes A Question alert box requests information from users. You can add components to this alert box (for example, a text field, list box, or combo box) in which users can type a value or make a selection Images 1. Uses the stock error icon. Question Alert Image Title bar Message Table Use the title bar of a alert box to appropriately identify the source of the message usually the name of the object from which the alert window was popped up. AdventNet Inc. 25

27 2. If the message results from a internal frame in a Multiple Document Interface (MDI), the title text is the name of that frame, followed by the application name. 3. If the message results from a non MDI object, then use the application name as the title bar text. Refer Figure Do not use descriptive text such as "Question" or "Query" for alert box title text. The alert symbol already conveys the nature of the message. Also, never use the word "error" in the title text. The word "error" provides no useful information Guidelines on writing "Question" Messages 1. Refer Section General guidelines on Writing Alert box messages Terminologies 1. Refer Section General guidelines on using Terminologies in Alert boxes Command Buttons 1. The "Question Alert Box" may have the buttons like "Yes", "No", "Cancel" or "OK", "Cancel" with optionally a "Help" button. 2. User will be prompt with a question and he can respond to it by pressing the relevant button of his choice. A dialog which comes up while closing a file without saving can be like this "MyProject.proj file not saved. Do you want to save the file?" with buttons "Yes", "No" and "Cancel". The Cancel button is a option to dispose the dialog without proceeding further. 3. The buttons are placed in the bottom-right corner of the alert. Pressing Enter may execute the default action associated with the alert. Refer Default Button in Dialog boxes. 4. Do not use Fold and Unfold alert boxes to display an Question. Refer Question Alert Boxes provided in Java Look and Feel design guidelines Fold and Unfold Alert box 1. You can use an unfold button to expand a window to reveal additional options as a form of progressive disclosure. An unfold button is a command button with a label that includes ">>" as part of its label, as shown in the figure You can use this type of dialogs in "Error Alert Boxes". The Unfold option helps to display any ideal information about the error caused to the user. 3. Use this type of dialogs very sparingly in your application. Do not use this dialog unless the application demands to do so. Figure 9.1 AdventNet Inc. 26

28 4. On pressing the unfold button (Details >> in this case), the dialog expands to show all the available details. The unfold button's label changes to "<<" on the dialog expansion, as shown in figure 9.2 Figure You can include your own graphics or animation in alert boxes (as shown in above snapshots). However, limit your use of these types of alert boxes. 6. Avoid defining new graphics to replace the symbols for the existing standard types. The standard symbols are tabulated below Information Alert Image Warning Alert Image Error Alert Image Question Alert Image Table To find more refer ---Alert boxes : Java Look and Feel design guidelines Progress Dialog A progress dialog box provides feedback for long operations and lets users know that the system is working on the previous command. Refer Progress Dialog Boxes for more details. Top 9.7 General Guidelines for writing Alert Box messages 1. Use complete sentences with ending punctuation. For example, instead of "Date too far in future," say, "The date is too far in the future." 2. Avoid contractions, especially in technical messages. Contractions may slow comprehension. 3. State the problem, its probable cause (if known), and what the user can do about it, no matter how obvious the solution is. Correct There is not enough disk space to save this file. Free additional space on this disk, or save the file to a different disk. Table 9.2 Incorrect Insufficient disk space. AdventNet Inc. 27

29 4. Make messages as specific as possible. Avoid combining more than two or three conditions in a single message. For example, if a file cannot be opened for several reasons, provide a specific message for each condition. 5. Avoid multi-step solutions. Users have a hard time remembering more than two or three simple steps after a message box closes. If multiple steps are necessary, provide general instructions, or add a Help button that displays a relevant Help topic. Always present the steps in the order they should be completed. Correct Remove the floppy disk, and then shut down the computer. Incorrect Shut down the computer after you remove the floppy disk. Table Provide only as much background information as necessary for the user to understand the message. Include enough information so that an advanced user or support person can help diagnose the problem. 7. To balance the amount of content you include, you can add a command button that calls a Help topic with further information. 8. You can also include a message identification number as part of the message text for each message for support purposes. However, to avoid interrupting the user's ability to quickly read a message, place such a designation at the end of the message text and not in the title bar text. 9. Use confirmation messages, such as "Are you sure you want to " judiciously. A more useful alternative is to describe to the user what the effect of the choice will be. 9.8 General Guidelines on Command Buttons in Alert Boxes 1. Typically, alert boxes contain only command buttons as the appropriate responses or choices offered to the user. 2. Designate the most frequent or least destructive option as the default command button. 3. Command buttons allow the alert box interaction to be simple and efficient. If you need to add other types of controls, always consider the potential increase in complexity. 4. If a message requires no choices to be made but only acknowledgment, include an OK button and, optionally, a Help button. 5. If the message requires the user to make a choice, include a command button for each option. 6. Include OK and Cancel buttons only when the user has the option of continuing or stopping the action. 7. Use Yes and No buttons when the user must decide how to continue. 8. If these choices are too ambiguous, label the command buttons with the names of specific actions for example, Save and Delete. 9. When you include Cancel as a command button in a alert box, remember that to users, Cancel implies restoring the state of the process or task that started the message. If you use Cancel to interrupt a process and the state cannot be restored, use Stop instead. 10. Some situations may require offering the user not only a choice between performing and not performing an action, but an opportunity to cancel the process altogether. In such situations, include a Cancel button, as shown in Figure 9.3. (Be sure to clearly label the button and the results the user can expect from clicking it) AdventNet Inc. 28

30 Figure You can optionally include a Help button in a alert box for messages that you want to provide more details about. This enables you to keep the message text succinct. 9.9 General Guidelines on using Terminologies in Alert Boxes Use terminology that your audience understands. Avoid unnecessary technical terminology and sentences. For example, "picture" can be understood in context, whereas "picture metafile" is a technical concept. The following messages are commonly used across all AdventNet products. Consider using or adapting them in your application in similar scenarios. Message Type File not found Re-running setup Sample Message The program cannot find the file <filename>. The <filename> file is missing. Run Setup again to reinstall the missing file. For more information about running Setup, press F1. Table Phrasing Alert Box Messages Avoid using "please" except in the following situations: 1. When the user is asked to wait while the program completes an action. For example, "Please wait while Setup copies files to your computer." 2. When the user is asked to retype information that is required before the user can continue. For example, "The password is incorrect. Please type the correct password." 3. When the user is inconvenienced in some other way. 4. Avoid phrasing that blames the user or implies user error. For example, use "The system cannot find the file <filename>" instead of "File name error." Avoid the word "error" altogether. 5. Do not anthropomorphize; that is, do not imply that programs or hardware can think or feel. Correct The node cannot use any of the available protocols. Incorrect The node does not speak any of the available protocols. Table 9.5 AdventNet Inc. 29

31 10: Menus and Toolbars The following sections cover the details of Menu bar and Toolbar in more detail: 10.1 Menus and Toolbars 10.2 Menu Elements o Menu Bars o Drop-down Menus o Submenus o Menu Items o Separators o Menu Item Graphics o Checkbox Menu Items o Radio Button Menu Items 10.3 Common Menus 10.4 Contextual Menus 10.5 Toolbars o Toolbar Placement o Draggable Toolbars o Toolbar Buttons 10.6 Tool Tips This chapter talks about the look and feel of the Menus and Toolbars. To know more facts about the user interaction and usability, refer Menu bars and Toolbars in "Part IV : Advanced topics" of this book. AdventNet Inc. 30

32 11: Basic Controls This chapter covers the basic User Interface controls needed or provided by JFC. This chapter also throws light into the areas like the classifications of controls, their appearance and behavior etc. The details are listed below: 11.1 Basic Controls 11.2 Command Buttons o Default Command Buttons o Combining Graphics With Text in Command Buttons o Using Ellipses in Command Buttons 11.3 Toggle Buttons o Independent Choice o Exclusive Choice 11.4 Checkboxes 11.5 Radio Buttons 11.6 List Boxes o Scrolling o Selection Models for List Components 11.7 Combo Boxes o Non-editable Combo Boxes o Editable Combo Boxes 11.8 Sliders AdventNet Inc. 31

33 12: Text Components This section deals with various Text components provided by JFC. The below listed headings cover them in detail, 12.1 Text Components 12.2 Labels o Labels That Identify Controls o Labels That Communicate Status and Other Information 12.3 Text Fields o Non-editable Text Fields o Editable Text Fields 12.4 Password Fields 12.5 Text Areas 12.6 Editor Panes o Default Editor Kit o Styled Text Editor Kit o RTF Editor Kit o HTML Editor Kit AdventNet Inc. 32

34 13: Selectable Lists, Tables, and Tree Components This section contains information about the programming elements used with List boxes, Tables and Trees. The below given headings cover them in detail: 13.1 Selectable Lists, Tables, and Tree Components 13.2 Selectable Lists o Selectable Lists and Associated Tables o Selectable Lists and Associated Text Fields 13.3 Tables o Table Appearance o Table Scrolling o Column Reordering o Column Resizing o Row Sorting o Selection Models for Tables 13.4 Tree Components o Lines in Tree Components o Graphics in Tree Components o Editing in Tree Components AdventNet Inc. 33

35 Part IV : Components of JFC ( Advanced) 14: Introduction to JFC Components - Advanced Topics An application's usability depends on its appearance and behavior - its look and feel. A consistent look and feel helps users learn an application faster and use it more efficiently. In addition, a consistent look and feel helps users learn other applications that share that look and feel. This book provides guidelines for designing applications with the Java look and feel. All the guidelines are intended to help you create a well-designed application. Well-designed applications have the following characteristics: 14.1 Logical organization 14.2 Scalability 14.3 Predictability 14.4 Responsiveness 14.5 Efficiency The rest of this chapter describes each of these characteristics, why each is important, and which parts of this book relate to each characteristic. Logical Organization Applications that use the Java look and feel consist of user interface components displayed in windows. The way that you organize your application into windows and components should be consistent with the logical divisions that users perceive in their tasks. For example, a logically organized application might include: A window for reading received messages, each of which is an object A window for composing messages, with components such as text fields for addressees, a text area for the message, and a button for sending the message Logical organization is especially important in applications that display many objects in several windows. For example, an application for managing a large network might display: Windows displaying sets of network domains Views (such as icons or table entries) of each domain's nodes Views of each node's properties (for example, its network address) Within a window, usability often depends on whether menus, Toolbars are organized logically. Chapter 16, Chapter 18 describes how to design menus and toolbars. Scalability Applications sometimes need to display widely varying numbers of user interface objects. For example, in an application that monitors the computers of a growing corporation, the number of objects representing computers at a particular site might increase rapidly. When looking for a particular object in a window representing that site, a user might need to view 15 objects in one month or 1500 the next. The user interface of such an application should be scalable. In other words, it should enable users to find, view, and manipulate widely varying numbers of objects. This book discusses several ways to make your application's user interface more scalable. For example, Chapter 21 describes filtering and searching - features that enhance an application's ability to manipulate large sets of objects. AdventNet Inc. 34

36 Predictability To learn new parts of an application, users often rely on their experience with the application's other parts. Slight inconsistencies between the look and feel of different parts can frustrate users and reduce their productivity. Chapter 22 describes ways to group JFC components into reusable units that promote predictability in your application. Responsiveness Responsiveness is an application's ability to keep up with users. It is often cited as the strongest factor in users' satisfaction with applications. Chapter 23 describes techniques for measuring and improving your application's responsiveness. Efficiency To provide maximum usability, your application must be efficient. An application's logical organization, scalability, predictability, and responsiveness all contribute to its efficiency. Efficiency is especially important if users' tasks are complex and time-consuming. User aids, such as wizards, can help new users and experienced users work efficiently. Chapter 24 describes how to design wizards that are as efficient as other user-interface designs. In applications that monitor and manage real-time systems - such as large computer systems and networks - a user's ability to respond efficiently to alarms can sometimes prevent major system failures. Chapter 26 discusses how to design applications that enable users to handle alarms efficiently. AdventNet Inc. 35

37 15: Windows In a GUI application, user views and interacts with data by the help of Windows. Consistency in window design is particularly important because it enables users to easily transfer their learning skills and to focus on completing their tasks rather than on learning new conventions. Make sure that all your windows and dialogs complies with the Golden ratio. This chapter describes the general window types and presents guidelines for their appearance and behavior, 15.1 Windows, Objects, and Properties 15.2 Overview of Window Types 15.3 Window Types for Objects, Properties, and Actions 15.4 Primary Windows o Title Bars in Primary Windows o Toolbars in Primary Windows o Status Bars in Primary Windows 15.5 Property Windows o Property Window Characteristics o Choosing the Correct Property Window Characteristics o Dedicated and Non-Dedicated Property Windows o Inspecting and Non-Inspecting Property Windows o Behavior and Layout of Property Windows 15.6 Action Windows o Title Text in Action Windows o Command Buttons in Action Windows 15.7 Window Titles for Identically Named Objects and Views o Window Titles for Identically Named Objects o Window Titles for Multiple Views of the Same Object 15.8 Setting the State of Windows and Objects o Positioning Secondary Windows o Restoring the State of Property Windows 15.9 Alerting Users After an Object's State Changes Multiple Document Interfaces AdventNet Inc. 36

38 16: Menu bar This chapter discusses the ways to make the menu bar look consistent. It talks about the basic properties of a menu bar and provides a guideline to arrange the Menu bar items, so that it promotes consistency. For more details about the appearance of the Menu bar, refer Chapter 10 in this book Basic Properties 16.2 Guidelines for Grouping Menus 16.3 Text in Menus 16.4 Menu Titles 16.5 Globally Used Menu Items o A Typical File Menu o A Typical Edit Menu o A Typical View Menu o A Typical Tools Menu o A Typical Window Menu o A Typical Help Menu 16.6 Some Proposals for Tool Specific Menu titles 16.7 Graphics 16.8 Ellipses 16.9 Mouse Operation Keyboard Operation 16.1 Basic Properties 1. The Menu bar should always be visible and there should not be any option to hide the menu bar. 2. User should find all the options in the Toolbar and Pop up menus in the Menu bar. 3. Do not use Menu bars in the Internal Frames, which in turn brings two sets of Menu bar one in main window and another in the Internal frame. This leads to a severe confusion to the user. 4. Menu bar titles should be represented only in text, Images may form chaos to the user. 5. Menu bar should contain all the items present in the Tool bar irrespective of the frequency of usage. 6. For a menu list there can be a maximum of two levels of sub menus. 7. The Menu bar should not grow then and there for various selections, all the menu items irrelevant of the current selection should be visible but can be enabled or disabled accordingly. 8. All the Menu item should have a status message in the Status Bar. For e.g. when "New" is selected in the Menu, a message like "On selecting this option, it will create a new file... " should appear in the Status bar. AdventNet Inc. 37

39 16.2 Guidelines for Grouping Menus 1. The best size for a group is around 2-5 items. Single-item groups are best placed at the top or bottom of a menu, otherwise try to group them with other single items of the same type on the same menu. 2. Order items within a group logically, numerically, in task order or by expected frequency of use, as appropriate. 3. Only place one type of menu item in each group command, mutable, checkbox or radio button. For example, do not place commands (such as View->Reload) and settings (such as. View->Toolbar) in the same group Text in Menus 1. The Menu bar titles should be a meaningful single word. The Menu Items can have combination of texts explaining its functions up to a maximum of four words. 2. All Menu item should be "Headline Capitalized". For e.g. Open file should be represented as "Open File", There is no need of Headline capitalization in case of any prepositions, conjunctions like and, with etc Hierarchy of Menu Titles 1. The Menu Title always starts with "File" Menu as the first menu. 2. The order of the Menu bar should be like "File Edit View... Tools Window Help" 3. Tool specific menus should be inserted in between View and Tools Menu. This is the Flexibility that ALF Provides to the products so that it can maintain a same feel on all the Menus throughout. 4. The order should not be violated. 5. Let us attempt it with an example, Assume your product uses Menus like Build, Operation, Project etc which are tool specific. In this case follow the Universal Menus "File, Edit, View" as it is and after that insert your choice of Menus "Operation, Build, Project". 6. Even though there would be a minor change in the Menus of one product and the other, it won't be hindering to the user because it would be very easy for him to locate a Menu Item in the Menu. Figure 16.1 AdventNet Inc. 38

40 16.5 Globally used Menu Items A Typical File Menu : 1. File Menu should be the First Menu in the Menu bar. 2. The File Menu should have all the options that are related to the File / Project / Workspace, that are currently opened. 3. If your application can create a number of different types of document, you can make the New item a sub-menu, containing a menu item for each type. Label these items New document type, make the first entry in the submenu the most commonly used document type, and give it the Ctrl-N shortcut. 4. Note: A blank document will not necessarily be completely blank. For example, a document created from a template may already contain some data. 5. Provide "..." (Ellipses) to the suffix of the Menu item as it indirectly informs the user that the task is not completed by selecting the Menu Item alone. i.e. he / she may be asked to do some simple data entry before confirming to their action. 1. If there are submenus for a specific Menu item, then the Ellipses (...) should be given to the Sub menus of that Menu item (Refer Figure 16.2) as it is more appropriate Figure The File Menu should follow the same hierarchy as shown in the Figure AdventNet Inc. 39

41 6. The tool specific Menu Items will be dealt in this between Print Menu Item and Properties Menu Item. All the other globally used menu items will remain in their place to ensure consistency. 7. If any of the above given Menus doesn't make sense in any of the Products, then it can be removed from the Menu List 8. The Menu Items should not violate the order and grouping mentioned above. The menu items are logically grouped from the basic operations to advanced (or) higher level operations of the File. 9. Open Ctrl -O: Opens an existing document in a new window. Present the user with a standard Open File dialog from which they can choose an existing file. If the chosen file is already open in the application, raise that window instead of opening a new one. 10. Close Ctrl-W : Closes the current document. If it has unsaved changes, present the user with a confirmation alert giving the option to save changes, discard them, or cancel the action without closing or saving the document. 11. Save, Ctrl-S : Saves the document with its current filename. If the document already has a filename associated with it, saves the document immediately without any further interaction from the user. If there are any additional options involved in saving a file, prompt for these first time the document is saved, but subsequently use the same values each time until the user changes them. 12. Save As...: Saves the document with a new file-name. Present the user with the standard Save As dialog, and save the file with the chosen file name. 13. Open Recent Menu item consist of the Files / Projects that is opened most recently by the user. This Menu Item should show Five files by default. 14. The Sub Menu should display only the File Name rather than showing the full path (Menu gets Longer if the path is too long). 15. The Full Path corresponding to the Menu selection should be given in the Status Bar on mouse over. 16. Properties : Opens the document's Properties window. This may contain editable information, such as the document author's name, or read-only information like the date and time when last modified / compiled or details about the Look and Feel set to that particular file Exit Ctrl - Q : Closes the application. If there are unsaved changes in any open documents, present the user with a confirmation alert for each affected document, giving the option to save the changes, discard them, or cancel. If there are no unsaved changes, close the application immediately without presenting any further messages or dialogs. 18. Use Separators to differentiate between groups A Typical Edit Menu : 1. Edit Menu should be the Second Menu in the Menu bar. 2. The Undo and Redo options can be disabled whenever there is not content in the History to Undo or Redo. The Redo option will be disabled until the user Undoes any action. 3. Cut Menu Item enables the user to Move the selected Component / Text to the Clipboard. When no item is selected, the Cut Menu Item should be disabled. AdventNet Inc. 40

42 Figure The Edit Menu should follow the same hierarchy as shown in the Figure Copy option makes a copy of the selection to the clipboard. This Menu Item should be enabled only when the user selects any Component / Text from the File or Project. 6. Paste option Pastes the data that is Copied or Moved to the Clipboard in the position where the cursor blinks (in a Text based file) or in the specific area where it is meant to be placed (like Draw area). The Menu Item should be enabled only when the user selects any of the above option, Cut or Copy. 7. The Delete option simply wipes out the selection from the display area. It is not copied to the Clipboard, hence one cannot Paste the selection elsewhere. 8. Select All selects all the Components or Texts that are displayed in the Display Area. 9. Find option is to search for a specific component in a group of components. This Menu Item will pop up a dialog where the user have to enter his / her content to be searched. The specific component / content will be selected if it is found or will pop up a dialog saying "No Match Found" or something similar. 10. There should be a option called "Find Again" (In the dialog popped up) with Shortcut F3, which will search for any repetition of the component that is to be searched. 11. Find / Replace Option enables the user to Find a specific component / text and Replace it with some other component / text. There should be a option called "Replace All" (In the dialog popped up), which will replace all the matching entries with the users' choice. 12. Go To option stands more specific to the text editors which have Line Numbers. The User can straight away jump to a specific line of the content by referring to the Line Number. This comes to a great help during the debugging operation. Note: Go To option is specific to certain Tools, hence ALF provides a flexibility to take off this Menu Item from the Product that don't need this option. 13. On Selecting Preference option, opens a preferences window allowing the user to change preferences for the whole application. Changes will apply to all running and subsequent instances of the application. 14. All the Global Settings / Customization of the tool should be available in Preferences Menu Item under Edit Menu. The settings that are given in this Menu Item will take effect in the all the Files / Projects that are created using the tool. 15. Use Separators to differentiate between groups. AdventNet Inc. 41

43 A Typical View Menu : 1. View Menu should be the Third Menu in the Menu bar. 2. The View Menu consists of Menu Items that can be customized by the user while working with the Tool. 3. The Specialty of these Menu Items is that, the changes done in this Menu Items will not be reflected in the File or the Project that is saved. 4. Moreover the user really enjoys working when he has some options to setup his own views while working. 5. The View Menus can't be dealt in a more specific way, as different product may have its own unique functionality where every thing can't be captured in general. To Narrow down and to provide a minimal choice of violation, the View Menu has been arranged as three parts, Part 1: This part holds the Navigational functions if any in the product. It also has a option to Refresh the display. Part 2: This part deals with the settings / customization that is provided to the user while working. Part 3: The show option for various components. top Figure The View Menu should follow the same hierarchy as shown in the Figure The Navigation Option contains Go Back and Go Forward for which the shortcuts will be "Alt - Left Arrow" and "Alt - Right Arrow". 8. The Refresh option is given here to refresh the display or view. 9. If your application does not need Navigation or Refresh option, it can be taken off but if it is been used then it should be placed in the following Hierarchy as in the image. 10. Users' view like "Add View", "Modify View" and "Delete View" can be grouped under the "Custom View" Menu. 11. The Look and Feel option can be listed under the View menu. The user can setup his own Look and Feel using the Theme Manager. 12. Showing various Reports can be dealt after this. For E.g. Some tools may support Reports and they produce Performance Reports, Comparison Reports etc. This will be applicable in tools like Automated Testing. AdventNet Inc. 42

44 13. The Show option enables the user to Show / Hide various window components like Toolbar, Status Bar etc. Apart from the window components there may be some additions which are tool specific like Show Grid, Show Runtime View etc A Typical Tools Menu : 1. The tool specific Menus should be inserted in between the View menu and the Tools menu. 2. The Tools Menu will have a provision to accommodate all the external tools that are used by the Product. 3. For example, Bean Builder is a product which has plugged in many standalone tools like "Versioning Tool", "Deployment Wizard", etc. This tools can be consolidated under Tools Menu. 4. For a legible presentation, the tools menu has been segregated into three portions. Part 1:All the Tools from AdventNet can be Placed in the first part. Part 2:If the product supports any Third Party tools integration then it can be given as a second part. Part 3:Customization or Configuration of Tools can be done here. Figure The View Menu should follow the same hierarchy as shown in the Figure If the Product supports any Internal Tools, then List down all the supported tools in the First Part of the Tools Menu. 8. If the product has support to Third Party Tools or plug-in then provide them in the Second part of the Tools Menu. 9. Configure Tools option should be placed as the last Menu item in the Tools Menu. This enables the user to configure / incorporate any other tools into the application he / she is working with. 10. Here is an example (Figure 16.5a) screen shot of a Tools menu from one of the products of AdventNet Inc. AdventNet Inc. 43

45 Figure 16.5a A Typical Window Menu : 1. The Window Menu should be consisting of the Window related options. 2. For a legible presentation, the Windows menu has been segregated into two portions. Part 1:The Options to arrange the windows Part 2:The second part shows all the files / windows that are currently opened. Figure The Window Menu should follow the same hierarchy as shown in the Figure Note: Window Menu will be of great use when the application uses Internal Frames (Multiple Document Interfaces - MDI). 4. There three different styles that the windows can be arranged like "Cascading", Tiling Horizontally and Vertically etc. These options should be captured in the first part. 5. All the windows / files / projects that are opened, should be listed out in the second part. 6. The Active file or the file that the user is currently working with should be denoted by a radio button check. 7. The Menu Items formed will be very dynamic, so allocating mnemonics will be very tedious. Hence, the mnemonics are assigned to the numbers which will be displayed in ascending order (Refer Figure 16.6a) AdventNet Inc. 44

46 8. The Radio Button Menu Items should be used in this case as only one Window / File can be selected at any point of time. Do not use any other representation like a tick / cross to indicate the selection. 9. When the "Currently Opened Windows" list goes beyond the limit (say : 10), then the Menu Item "More" will be enabled and it will pop up a dialog which will display all the windows in a JList. On Double clicking or clicking open button (with the a entry selected in the List) will open the respective file. 10. Here is an example (Figure 16.6a) screen shot of a Window menu from one of the products of AdventNet Inc. Figure 16.6a A Typical Help Menu : 1. The Help Menu should be the last menu of Menu bar. It should provide all the necessary informations about the Product, Company, How to Register, How to Update, Access to the technical document and so on. Figure The Help Menu should follow the same hierarchy as shown in the Figure The Contents Menu invokes the Help of the Product. The term "Contents" should not be replaced with any other term at any cost. 4. The Mnemonics is "C" and shortcut is "F1". 5. This option is used to denote a Context Sensitive Help. 6. What's This? is well known as Context-Sensitive Help. When user selects this option, there is a change in his / her mouse pointer similar to the graphic found in the Figure 16.7 (prefix of the What's This? Menu item). When the user clicks the mouse on any of the objects in the screen, he gets an answer for the question "What's This?". AdventNet Inc. 45

47 7. This provides a great help in understanding the terms and components used in the User Interface. This Help invokes a Multi-Lined Tool tip which explains about the component in a short and crisp way. 8. If there is no Help for any of the component then, it should be indicated to the user by the appropriate Mouse Pointer feedback [ ] 9. The Tip of the Day option invokes a dialog which gives a random tip regarding the hidden features in the tool. This also helps to keep the user informed about the easiness of the tool or guides him to improve the usage of the tool. There should be a option to disable this option when ever the user needs so. 10. AdventNet Online leads the user to the Product Profile page of the Company's website. 11. The Register helps the user to register the product during evaluation time. Once he / she registers the product, the option should be taken off from the Help Menu. 12. News & Updates option takes the user to the Corporate News and Service Pack Update page in the Website. 13. The About option displays the information about the Product, Version, Copyright, Support and the Company details Some Proposal for Tool specific Menus. These Menu names can be adopted in the products as it is given below. Name Details Mnemonic top Operation Format Project Make 1. The functions like Connect, Disconnect, Interactions between the components etc. can be listed under the Operations Menu. 2. Some of our Tools support Get, Get Next, Set etc. These Menus can be listed below this Menu. The formatting options like Aligning (Left, Right, Center, Justify), Size (Same Height and Width) sort of stuffs should be listed under Format Menu. If the tool supports Project, then all the functions related to Project should be captured under this menu. This Menu contains all the necessary options like Build Type, Compile, Run, Regenerate etc. Table 16.1 O R P M 16.7 Graphics 1. The Size of the Images should be 16 x 16 (in pixels). 2. Images should be aligned to the left end of the menu item. 3. The text should be aligned to left after the image and a blank space should be placed on the Menu Item where there is no image. i.e., all the sub menus should be left aligned after the image or space. 4. Each image should be used for a specific function and should not be used for some other function in the same or different product. 5. If an function / operation has an icon (pictorial representation) some where in the product, then it should be given for the corresponding Menu Item in the Menu bar. AdventNet Inc. 46

48 16.8 Ellipses (...) Ellipses (...) are punctuation marks that indicate the omission of one or more words that must be supplied in order to make a construction complete. In your menus, you can use ellipses in a similar way: to indicate that the command issued by a menu item needs more specification in order to make it complete. If a menu item does not fully specify a command and users need a dialog box to finish the specification, use an ellipsis after the menu item. For example, after choosing Save As..., users are presented with a file chooser to specify a file name and location. Warning : Do not use an ellipsis mark simply to indicate that a secondary or utility window will appear. For example, choosing Preferences displays a dialog box; because that display is the entire effect of the command, however, Preferences is not followed by an ellipsis Mouse Operation On mouse over the menu title, the menu list should not drop down. Only after clicking on the menu, it should drop down the menu list and should continue the mouse over till the mouse is clicked Keyboard Operation 1. The Standard mnemonics, globally accepted should not be violated. 2. Key board shortcuts is necessary for the Menu Items that are accessed most frequently by the user. We should not violate the Standard shortcuts used universally. Refer : Global shortcut Vs AdventNet shortcut. 3. It is not compulsory to have shortcuts for all the Menu Items in the Menu but there should be mnemonics mentioned for all the Menu Items. AdventNet Inc. 47

49 17: Contextual Menus A context menu is a floating menu that can pop up wherever it is needed for selections in a particular editing or user interface context. A context menu should be used for context sensitive interaction with the objects in an application. If an object is selected in an application and the context menu is opened, the context menu should only contain actions which are appropriate for the selection. For more details on the design of Menu bar and Contextual Menus refer Chapter 10 - Menus and Toolbars. This section deals with the following, 17.1 Basic Properties 17.2 Structure of Contextual Menus 17.3 Contents in a Contextual Menu o Submenus o Number of Items o Completeness o Default Menus o Default Functions 17.4 Advantages of Contextual Menus 17.1 Basic Properties 1. You can access the contextual menus by right clicking the mouse. Display the menus specific to that object on which the mouse is clicked. 2. Make sure that the contextual menu popped up always falls with in the display area. Do not let the menus to go out of the screen resolution. 3. Include only frequently used menu items in contextual menus. 4. If your application has contextual menus, ensure that it has them for all its objects. 5. In an open contextual menu, dim unavailable menu items that cannot apply to the current object. Do not display unavailable menu items that cannot apply to the current object. 6. The Pop up Menu should have Mnemonics for all the Menu Items. The Menu Items will be activated on pressing the character (that is underlined) from the keyboard. Note: Keyboard Shortcuts in the contextual menus doesn't serve much. So you do not display the shortcut keys in the contextual menus Structure of Contextual Menus 1. Place the object's primary commands first. i.e. If there exits a default action for a context menu, this action appears as the first entry of the menu item list. 2. Place storage or valued tasks next. Order the transfer commands as follows: Cut, Copy, Paste, and other specialized Paste commands. 3. Include other commands supported by the object (whether provided by the object or by its context). 4. Include Properties command, if supported by your application. 5. Place the Help command, when present, as the last command on the menu. 6. Use separators to separate groups of commands. AdventNet Inc. 48

50 17.3 Contents in a Contextual Menu Figure 17.1 The context menus may contain the following elements: 1. Menu entries (text), 2. Icons (in front of the text), 3. Ellipses (following the text, indicate that a dialogue box is called), 4. Arrows (following the text; indicate that the menu contains a further menu level which is displayed as a cascading menu), 5. Separator lines for clustering the menu items into useful groups. Warning: Since the user may not be aware of their presence, do not provide functions that are only accessible from popup menus, unless you are confident that your target users will know how to use popup menus. Figure17.2 AdventNet Inc. 49

51 Submenus Context menus may contain submenus, but only one more level. Hierarchies with more than two levels are not allowed Number of Items Popup menus need to be as simple as possible to maximize their efficiency. Do not place more than about Ten items on a popup menu, and do not use submenus Completeness A context menu should contain the complete set of menus that exists for a given object Default Menu On the screen background or on other undefined screen areas, the context menu only displays the item "No entry".this way users receive feedback saying that there exists a context menu functionality, but that at this location no sensible actions can be provided Default Functions 1. All text fields (e.g. also table cells) contain at least the items "Cut", "Copy", "Paste" and "Select All". 2. The default functions available for each component are shown below, a Default Contextual Menu while editing a Cell in a Table: b Default Contextual Menu while editing a Column in a Table: AdventNet Inc. 50

52 17.3.5c Default Contextual Menu while editing a Row in a Table: d Default Contextual Menu in a Tabbed Dialog: e Default Contextual Menu on selecting a Leaf Node: f Default Contextual Menu in the Root node of a Tree: AdventNet Inc. 51

53 17.3.5g Default Contextual Menu in the Tree Container: h Default Contextual Menu in a Text Area: i Default Contextual Menu in a Text Field: j Default Contextual Menu in a Group of Components: k Default Contextual Menu for a Graphic: AdventNet Inc. 52

54 17.4 Advantages of Context Menus 1. Context Menus provide rapid access to frequently used functions. 2. Context menus allow users to remain focused on their work area. 3. Context menus also minimizes the screen clutter because they are displayed only on demand and do not require dedicated screen space. 4. Finding the right menu command to use can sometimes be difficult when an application has a complex menu system. Use of context menus simplifies the operations. AdventNet Inc. 53

55 18: Toolbar A toolbar is a panel that contains a set of controls, designed to provide quick access to specific commands or options. Specialized toolbars are sometimes called ribbons, tool boxes, and palettes. Refer Chapter 10 : Menus and Toolbars to know more about the toolbar size, toolbar graphics etc Basic Properties 18.2 Number of Toolbar items 18.3 Toolbar Configuration o 1. Toolbar graphics o 2. Legible Buttons o 3. Toolbar Buttons o 4. Hidden Toolbar Items 18.4 Vertical Toolbar 18.5 Toggle Buttons 18.6 Support for User Actions 18.7 Keyboard Access 18.1 Basic Properties 1. By default, the toolbars should be located just below the menu bar. It will remain as it is unless the user changes or rearranges it. 2. Toolbars provide shortcuts to menu commands, so all the functions in the toolbar should be available in the menu bar, immaterial of where they are placed in the menus. 3. Provide "Tool tips for all the toolbar buttons. The tool tip will help the user to understand the toolbar graphic easily. Refer Chapter 20 - Contextual Help for more details. 4. Do not display shortcuts in the tool tip by default. Provide it as an option in the global preference where the user can choose whether he needs the shortcut to be displayed in the tool tip or not. 5. The tool bar buttons should be aligned to the left side and the company logo should be glued to the right end. 6. Ensure that all the buttons are visible in the toolbar on the default pop up of the application. 7. Handle the toolbar buttons properly by making it available or unavailable (Enabling / Disabling) according to their need in that particular screen. 8. If your application has more than three toolbars, allow the user to turn them on or off individually by placing a menu item for each one in a Toolbars sub-menu on the application's View menu. Place the Main Toolbar item first (if your application has one), followed by the others in alphabetical order. Various options in the toolbar like, Image and text, image only and text only is shown below : Figure 18.1 AdventNet Inc. 54

56 Figure 18.2 Figure 18.3 For more details on Toolbar refer Java Look and Feel Design Guidelines Number of Toolbar Items 1. Don't add buttons for Help, Close or Quit to your toolbar by default, as these are rarely used and the space is better used for more useful controls. 2. Only provide buttons for Undo, Redo and the standard clipboard functions if there is space on the toolbar to do so without sacrificing more useful, application-specific controls. 3. A maximum of 18 tool bar items can be used in a single tool bar. i.e., it will look good even in 800 x 600 monitor resolution Toolbar Configuration To provide maximum flexibility for users and their tasks, design your toolbars to be user-configurable. 1. Toolbar graphics : Provide three image sizes, from which user can select any one of his choice and all the images in the toolbar buttons will be changed to that. The images can be classified as, 1. Large (32 x 32) 2. Medium (24 x 24)and 3. Small (16 x 16) 2. Legible Buttons : To Make the toolbar buttons look legible and clear, leave 3 pixels gap between the graphic and the button edge. 3. Toolbar Buttons : While designing a toolbar in you application, consider the other type of users who may have some visual disabilities to recognize the color and graphics, so provide the below mentioned options to gain a wide accessibility for your application. 1. Images along with Text placed next to the image 2. Images along with Text placed below the image 3. Text only 4. Images only 4. Hidden Toolbar Items : A control (>>) includes an option to display buttons hidden by a resized toolbar, as shown in Figure The toolbar includes a double-chevron button that the user clicks to display the hidden buttons in a toolbar (shortcut menu). AdventNet Inc. 55

57 Figure Vertical Toolbar In general, don't use vertical toolbars. The eye does not scan vertically as well as it does horizontally, groups of mutually exclusive (groups) buttons are less obvious when arranged vertically, and showing button labels is more awkward and less space-efficient. Also, some toolbar controls just cannot be used vertically, such as drop down lists. Only consider using a vertical toolbar if: the configuration of the application window means there would be a lot of wasted space if a horizontal toolbar was used instead, or your application would otherwise require three or more rows of toolbars to appear below the main menu bar by default. Note however that in this situation, the better alternative is usually to display fewer toolbars by default. If you must use a vertical toolbar, ensure the user can configure it to appear horizontally if they prefer Toggle buttons You can make a toolbar button perform specific actions or reflect a state, mode, or property value similar to that of option buttons or check boxes. The typical interaction for a toolbar button is to return to its normal "up" state, but if you use the button to represent a state, display it in the option-set appearance. When the user clicks a button that represents a tool mode for example, in clicking and dropping a bean in a visual IDE tool display the button using the option-set appearance and change the pointer to indicate the change in the mode of interaction. More Usable Approach To make it more usable, when the button in a bean palette is double clicked, it remains in the "up" (the state can be visually shown by a badge on the top left corner of the button) state until the user clicks on the button again to reset it. This will be helpful when multiple operation has to be done with same button selected. For example, the user needs to drop five JTextFields while designing a User Interface, he has to click (n*2) times for dropping the component. But the above said option reduces the clicking strain drastically and enhances the productivity in designing. AdventNet Inc. 56

58 18.6 Support for User Actions 1. Give the user the option to display or hide toolbars. 2. You can also include options that allow the user to change or rearrange the elements included in toolbars. Make sure your configuration options are also available from the keyboard to ensure that they are accessible for all users. 3. Although toolbars are typically docked by default that is, aligned to the edge of a window or pane to which they apply consider designing your toolbars to be moveable so that the user can dock them along another edge or display them as a floating palette window. 4. When you provide support for toolbar configuration options, always preserve the current position and size, and other state information, of a toolbar configuration so that they can be restored when the user reopens the window. When you restore the configuration of a toolbar, verify that the size and position are appropriate for the current display settings Keyboard Access 1. Omit all toolbar controls from the keyboard traversal order so that the expert users could navigate more easily. If a user presses the Tab key to move keyboard focus in a window, do not move focus to toolbar controls. 2. Provide keyboard access to the toolbar items by providing a equivalent action in the Menu bar. Toolbar controls can differ from their corresponding menu items - but only in that the toolbar control uses default values, whereas the menu item opens an action window. AdventNet Inc. 57

59 19: Status bar A status bar, is a special area within a window, typically at the bottom, that displays information about the current state of what is being viewed in the window or any other contextual information, such as the keyboard state. Although a status bar can contain controls, it typically includes read-only or noninteractive information. This chapter covers the following, 19.1 Basic Properties 19.2 Status bar configuration 19.3 Status Animation 19.4 Status Message 19.5 Toolbar on Status bar 19.6 LED Panel 19.1 Basic Properties 1. Use status bars only in application or document windows. Do not use them in dialogs, alerts or other secondary windows. 2. Only place a status bar along the bottom of a window. 3. Only use status bars to display non-critical information. This might include: 1. general information about the document or application. For example, current connection status in a network application, or the size of the current document in a text editor. 2. information about the task the user is currently performing. For example, while using the selection tool in a drawing application, "Hold Shift to extend the selection" 3. progress of a background operation. For example, "Sending to printer", "Printing page 10 of 20", "Printing Complete". 4. a description of the control or area of the window under the mouse pointer. For example, "Drop files here to upload them" 4. Remember that status bars are normally in the user's peripheral vision, and can even be turned off altogether using the application's View->Status Bar menu item. The user may therefore never see anything you display there, unless they know when and where to look for it. 5. In a window's status bar, ensure that each message fits the available space when the window is at its default size. 6. The click-able components in a status bar should have "Tool tips" explaining about the function in a word or two. The "Inlaid" area in a status bar shows that it is not interactive and the flat (Beveled out) portion similar to the Toolbar in Figure 19.1 is click-able. 7. For every user action, there should be a status message in the status bar. The status message should be a short simple sentence which should explain the entire objective to the user. 8. Don't use multiple layers in the status bar. Figure 19.1 AdventNet Inc. 58

60 19.2 Status bar Configuration 1. To provide maximum flexibility for users and their tasks, design your status bar to be userconfigurable. 2. Provide the user an option to display or hide the status bar Status Animation 1. The status animation and the mouse pointer should go hand in hand, i.e. if the status animation is playing, the mouse pointer should be indicating a "Busy" cursor. 2. The status animation can be used in a two different ways, 1. Progressive status animation 2. Processing status animation Progressive status animation : 1. In this kind of animation, user is clear with the time frame that, when the task will be complete and how long will he needs to wait, etc. 2. A progress bar that increases gradually (in progression) with the details (in percentage) of the task completed constitute a progressive status animation. Processing status animation : Figure The processing status animation is a painted rectangle moving left to right indicating that the system is busy processing the data internally. Figure 19.3 Note: User should have an option to stop / cancel the process by pressing Escape (Esc) key or by clicking the stop button in the toolbar Status Message 1. Provide status bar message for every user actions. For example, if the user points the mouse pointer on a toolbar button for "Copy", provide a message saying that "this command will copy the contents to the clipboard". 2. To avoid displaying obsolete information in a window's status bar, clear each status message when the next user action occurs in that window. 3. Ensure that you have a clear demarcation of Error Messages and Status messages. 4. When there is no interesting status to report, leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the status bar, the user is more likely to notice it. AdventNet Inc. 59

61 5. Do not use colors to indicate the severity of the status message, it will indeed irritate the user while working. Instead use a small (16 x 16) image in the left of the error / warning messages in the status bar. 6. Use status bar to display non-critical messages. 7. Do not display critical messages in the Status bar. Use Alert boxes to display the critical or fatal error messages. -Warning Message - Error Message Table 19.1 For more details on Status bar messages, refer Chapter 20 - Contextual Help in Status bar 19.5 Toolbar on Status bar 1. Toolbar on status bar acts as an shortcut for the tools that are plugged into the current application. 2. There is a drag texture in the left end of the toolbar, this enables the user to detach the toolbar from the status bar. The toolbar is displayed in a floating window (not resize-able). when the window is closed, the toolbar regains its position in the status bar. 3. Ensure that the status message area fills up the toolbar's space when it is detached. 4. Show tool tip for all the toolbar buttons in the status bar LED Panel Figure The elements in the extreme right bottom or top is noticed first by anyone working on a computer. So the LED Panel should be placed in the extreme right of the status bar. 2. The LED panel can be used to show the continuous change in the data or the severity of the data that is constantly changing. 3. In any kind of application where LED panel makes no sense, but the application needs to show a state of "Connect / Disconnect", then the LED panel can be replaced with the application's specific components. Note: Don't ever populate the status bar with unnecessary images, which has no impact on the current data or current state of the system. This simply distracts the users from their intended tasks. AdventNet Inc. 60

62 20: Contextual Help Contextual Help provides immediate assistance to users without their having to leave the context in which they are working. It provides information about a particular object and its context. It answers questions such as "What is this?" and "Why should I use it?". Some of the basic ways to support contextual user assistance in your application include: 20.1 Context-sensitive Help o Shortcut Keys for Context-Sensitive Help o Guidelines for Writing Context-Sensitive Help o Items that need Context-Sensitive Help 20.2 Tool Tips 20.3 Status bar messages 20.4 The Help Command Buttons 20.1 Context-Sensitive Help 1. The Context-Sensitive Help (What's This?) command allows users to obtain contextual Help information about objects on the screen, including controls in property sheets and dialog boxes. 2. You can support user access to this command by including the following in your application: 1. A What's This? command from the Help drop-down menu of a primary window. 2. A What's This? button on a toolbar. 3. A What's This? button on the top right corner of a secondary window (shown in Figure 20.1). 4. Support for the What's This? shortcut key when a control has the input focus. Figure Display the context-sensitive Help pointer (Figure 20.2) only over the window that provides context-sensitive Help; that is, only over the active window from which the What's This? command was chosen. 3. Display a context-sensitive Help window for an object that the user clicks with the primary mouse button (usually the Left button in the mouse). 4. The context-sensitive Help window provides a brief explanation about the object and how to use it. AdventNet Inc. 61

63 5. After the context-sensitive Help window is displayed, return the pointer and pointer operation to the usual state. 6. If the user chooses the What's This? command, clicks outside the window, or presses the ESC key, cancel context-sensitive Help mode. Restore the pointer to its usual image and operation in that context. -Context-Sensitive Help Available - Context-Sensitive Help Not available Table Shortcut keys for Context-Sensitive Help 1. The F1 and SHIFT+F1 keys are the shortcut keys for invoking contextsensitive help. The F1 key displays the most context-sensitive Help available based on the current context. 2. In primary windows, pressing F1 typically displays the HTML Help viewer with an appropriate topic. 3. In secondary windows, pressing F1 typically displays the context-sensitive pop-up window for the control that has the input focus. 4. However, if you support context-sensitive Help for elements of your primary window, use SHIFT+F1 to begin context-sensitive Help mode, changing the pointer and enabling the user to click a menu or control in the window to provide the context. 5. In secondary windows, use SHIFT+F1, like F1, to display the contextsensitive Help pop-up window for the control that has the input focus Guidelines for Writing Context-Sensitive Help 1. When writing text for context-sensitive Help, you are answering the questions "What is this?" and "Why would I want to use it?" Indicate the action associated with the item. 2. In English versions, begin the description with a verb; for example, "Adjusts the speed of your mouse," or "Provides a place for you to type a name for your document." 3. For command buttons, you can use an imperative form for example, "Click this to close the window." 4. When describing a function or object, use words that explain the function or object in common terms instead of technical terminology or jargon. For example, instead of using "Undoes the last action," use "Reverses the last action." 5. Use sentence-style capitalization and ending punctuation. Also use the system-defined Help font, but avoid the use of italic text because it is hard to read on the screen. 6. In the explanation, you might want to include "why" information. You can also include "how to" information, but if the procedure requires multiple steps, consider using procedural Help to support this information. 7. Keep your information brief but as complete as possible so that the Help window can be read quickly and is easy to understand. AdventNet Inc. 62

64 Items that need Context-Sensitive Help While you can provide context-sensitive Help for any item in your application's windows, always provide it for the following elements: 1. All editable elements or labels for editable elements 2. Status bar items that do not have text labels 3. All toolbar buttons and controls 4. All menu items Avoid creating context-sensitive Help for parts of the interface that do not do anything, such as group box labels or static descriptive text fields. You can create a common Help topic for group labels such as the following: "Help is available for each item in this group. Click? at the top of the dialog box, and then click the specific item you want information about." 20.2 Tool Tips Tool Tips are another form of contextual user assistance. Tool Tips are small pop-up windows that display the name of a control when the control has no text label. The most common use of Tool Tips is for toolbar buttons that have graphic labels, but they can be used for any control. 1. Display a Tool Tip after the pointer (or pointing device) remains over the button for a short period of time. 2. The Tool Tip is displayed until the user presses the button or moves the pointer off the control, or after another time-out. 3. If the user moves the pointer to another control that supports a Tool Tip, ignore the time-out and display the new Tool Tip immediately, replacing the former Tool Tip. 4. The details about Onset delay and Duration is discussed in Java Look and Feel Design Guidelines - Advanced Topics. 5. To know more about the appearance and behavior of Tool tip, refer Tool tip in Java Look and Feel Design Guidelines Contextual Help in Status bar You can use the status bar to provide contextual Help. 1. In addition to displaying information about the state of a window, you can display descriptive messages about menu and toolbar buttons. 2. When the user moves the pointer over a toolbar button or menu item, presses or clicks the primary mouse button when the pointer is over a menu or button, or uses the keyboard to move the input focus over a menu or toolbar button, display a short message describing the use of the associated command. 3. The user should be able to hide the status bar, avoid using the status bar to display information or access to functions that are essential to basic operation and are not provided elsewhere in the application's interface. 4. More over, because the status bar might not be located near the user's area of activity, the user might not notice it. It is best to consider status bar messages as a secondary or supplemental form of Help. AdventNet Inc. 63

65 Figure Guidelines for Writing Status Bar Messages 1. To write status bar messages, use simple familiar terms. Do not use jargons. 2. Start with a verb in the present tense. For example, use "Cuts the selection and places it on the Clipboard." 3. Try to be as brief as possible so the text can be read easily, but avoid making the text so short that it is cryptic. 4. Be constructive, not just descriptive, and inform the user about the purpose of the command. To describe a command with a specific function, use words specific to the command. 5. If the command has multiple functions, try to summarize them for example, "Contains commands for editing and formatting your document." 6. When you define messages for your menu and toolbar buttons, don't forget their unavailable (or disabled) state. Provide an appropriate message to explain why the item is not currently available. For example, when the user selects a disabled Cut command, you could display the message "This command is not available because no text is selected." More details about Status bar is given in Chapter 19 - Status bar of this book. AdventNet Inc. 64

66 20.4 The Help Command Button You can also provide contextual Help for a property sheet, dialog box, or message box by including a Help command button in that window. Figure 20.4 Ensure that you provide all the below given functionality while choosing a Help button in the dialog, 1. When the user clicks the Help command button, display an overview, summary, or explanatory topic for a page or for the entire window. For example, for a message box, the Help message can provide more information about causes and remedies for the reason the message was displayed. 2. Placement of a Help command button is important. If you include the Help command button with the OK and Cancel buttons, it implies that Help applies to the entire window. If you use the Help command button to display Help for a specific screen within the window, place the button on that page. 3. The user assistance provided by a Help command button differs from the What's This? form of Help. In this form of Help, you should provide more general assistance rather than information specific to the control that has the current input focus. 4. In addition, display the information in the HTML Help viewer, rather than in the contextsensitive Help pop-up window. 5. Consider the Help command button an optional, secondary form of contextual user assistance. 6. Do not use it as a substitute for context-sensitive (What's This?) Help. Also avoid relying on it as a substitute for clear, understandable designs for your secondary windows. AdventNet Inc. 65

67 21: Graphs Today's readers expect to see professional graphics in the products and its documents. The old saying that a 'Picture is worth a thousand words' is true! However, graphics should not be placed in the Product / document without a good reason and should be designed and placed in accordance with certain principles General Graphic Guidelines 21.2 Display Style for Texts in Graphs 21.3 Color Choices 21.1 General Graphic Guidelines You should observe these guidelines when using any Graph or Chart: 1. Provide proper Title to the graph. 2. Write in Upper and Lower case. Words written in all capital letters are hard to read. 3. Make the chart easy to read. Label the X and Y axis and label the lines, bars, or pie wedges. Provide headings on X and Y axis. 4. Make the most important text largest, the most important data lines or sections darkest. 5. Be accurate. Always start a numerical axis at zero. 6. Eliminate all unnecessary details. 7. Avoid grid lines, data points, boxes, and other devices unless they relate to the message or make it configurable by the user. 8. Use no more than four colors per visual. If the graph depicts a comparison between data, display the bars in different colors. 9. Avoid vibrating fill patterns, such as contrasting lines, wave patterns, and crisscrosses. 10. Make bars and columns wider than the spaces between them. 11. Graph size should not exceed the screen size. 12. Provide scroll bar if the graph goes longer. 13. Legends for graphs can be: 1. Legend moves with the mouse pointer. 2. Fixed legend on the top-right corner of the graph. 3. Floating legend, which can be moved anywhere using drag texture. AdventNet Inc. 66

68 21.2 Display style for Texts in Graph Figure 21.1 Top Text Font Size Style Color Sample Title / Main Times New Black 18 pt Bold Heading Roman (#000000) Dark Green Axis Heading Dialog 12 pt Bold (#306700) & Blue (#2833CC) Dark Green Axis Data Dialog 10 pt Regular (#306700) & Blue (#2833CC) 21.3 Color Choices Table 21.1 Top Particulars Colors Sample Background Light Blue (#E9FEFE) Plot Area Background Ivory (#FDFDDF) Axis Line Black (#000000) Grids Gray (#C0C0C0) Line / Bar 1 Red (#FF0000) Line / Bar 2 Green (#00FF00) Line / Bar 3 Blue (#0000FF) Line / Bar 4 Violet (#FF00FF) Line / Bar 5 Cyan (#00FFFF) Line / Bar 6 Orange (#FF8000) Line / Bar 7 Black (#000000) Table 21.2 AdventNet Inc. 67

69 22: Behavior "Behavior" refers to how applications interact with users. Chapter 7 of this book discusses that. This chapter provides additional information about the following aspects of behavior: 22.1 Modes o Modal Secondary Windows o Modes Set From Tool Palettes o Application-Wide Modes 22.2 Selecting Multiple Objects 22.3 Filtering and Searching a Set of Objects o Complex Filtering and Searching o Simple Filtering and Searching o Stopping Searches and Filter Operations 22.4 Tool Tips AdventNet Inc. 68

70 23: Idioms One main characteristic of a well-designed user interface is consistency among its parts. This characteristic helps users learn similar parts of the user interface faster. You can help users learn your application's user interface faster by creating its similar parts from the same sets of JFC components - that is, by implementing the same patterns, or idioms. This chapter explains what idioms are and then describes idioms for: Selecting and editing in tables provided by your application Arranging such tables Combining a tree component with a table Working with text fields and lists Displaying a hierarchy of containers in a split pane 23.1 Overview of Idioms 23.2 Idioms for Selecting and Editing in Tables o Selection Models and Editing Models for Tables o Using Row Selection Models o Editing Row-Selection Tables o Using Cell Selection Models o Editing Cell-Selection Tables 23.3 Idioms for Arranging a Table o Table Appearance o Table Command Placement o Column Reordering and Column Resizing o Row Sorting o Automatic Row Sorting 23.4 Tree Table Idiom 23.5 Idioms for Text Fields and Lists o Browse Idiom o Key-Search Idiom o Add-and-Remove Idiom 23.6 Container-and-Contents Idiom AdventNet Inc. 69

71 24: Responsiveness Responsiveness is often cited as the strongest factor in users' satisfaction with software applications and has been linked to users' productivity. Responsiveness, is "the software's ability to keep up with users and not make them wait".- Jeff Johnson (in his book GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers) 24.1 Characteristics of Responsive Applications 24.2 Problems of Unresponsive Applications 24.3 Responsiveness as Part of Performance o Computational Performance o Scalability o Perceived Performance, or Responsiveness 24.4 Determining Acceptable Response Delays 24.5 Measuring Response Delays o Setting Benchmarks for Response Delays o Tools for Measuring Response Delays 24.6 Responding to User Requests 24.7 Providing Operational Feedback o Deciding Whether to Provide Feedback o Types of Visual Feedback o Providing the Correct Type of Visual Feedback o Letting Users Stop Commands in Progress 24.8 Guidelines for Responsive GUIs o Design, Then Build o Put the user in charge 1. i. Don't make the user wait. 2. ii. Let the user know what's going on. 3. iii. Stay in sync. 4. iv. If it looks idle, it should be idle 24.9 Responsive Application uses Threads 24.8 Guidelines for Responsive GUIs This section introduces two basic guidelines for writing responsive GUIs: 1. Design, then build. 2. Put the user in charge. Following these guidelines should mitigate or eliminate GUI responsiveness problems. However, you need to consider the specific recommendations that follow in the context of your own program and apply the ones that make sense. AdventNet Inc. 70

72 Design, Then Build (Repeat) In nearly any engineering endeavor, it's important to spend time designing your product before you try to build it. While this is obvious, it's not always as clear how much time you should spend on the design before you start trying to implement it. Design work tends to be time-consuming and expensive, while building software that implements a good design is relatively easy. To economize on the design part of the process, you need to have a good feel for how much refinement is really necessary. For example: if you want to build a small program that displays the results of a simple fixed database query as a graph and in tabular form, there's probably no point in spending a week working out the best threading and painting strategies. To make this sort of judgment, you need to understand your program's scope and have a feel for how much it pushes the limits of the underlying technology. To build a responsive GUI, you'll generally need to spend a little more time on certain aspects of your design: Managing component life cycles. o If you're working with a large number of GUI components, think carefully about how and when they're created. You also need to consider when to cache, reuse, and discard components. o Constructing windows. o If your GUI contains more than a handful of optional windows, construct and cache the windows that are most likely to be needed next. o Handling timing issues in distributed applications. o If your program uses services provided by other machines, or even other processes on the same machine, its GUI must accommodate performance latencies and other unpredictable timing issues. This is essential for making the program feel responsive to the user Put the User in Charge Today, new programs are often distributed-they depend on services provided by other processes on a network, often the Internet. In this environment, a good performance model for a program is taking a dog for a walk: It's OK for the dog to stop and sniff as long as a tug on the leash gets a quick, appropriate response. Your program is the dog and the user is holding its leash. Your performance- engineering job is to make sure that the leash is as short as possible and your program is well-behaved. You don't want your 200-pound Labrador rolling around in the neighbor's geraniums on a 50-foot leash made of rubber bands. The following sections describe four key guidelines for keeping your distributed applications in check: 1. Don't make the user wait. 2. Let the user know what's going on. 3. Stay in sync. 4. If it looks idle, it should be idle AdventNet Inc. 71

73 1. Don't Make the User Wait If the user has to wait for more than 50 milliseconds for a response, the program is going to seem slow. Pauses of less than 50 milliseconds between when the user presses a key or button and when the GUI responds feel instantaneous to the user. As the delay grows, the GUI begins to feel sluggish. When the delay reaches 5 seconds or more, users are likely to assume that the program isn't working at all. In response, they often bash the keyboard and mouse in frustration, which can render the program truly nonfunctional. In a distributed application, it's often not possible to provide results instantaneously. However, a welldesigned GUI acknowledges the user's input immediately and shows results incrementally whenever possible. Follow the guideline for Providing Operational Feedback to engage the user during long response delays. 2. Let the User Know What's Going On When the user launches a time-consuming task and has to wait for the results, make it clear what's going on. If possible, give an estimate of how long it will take to complete the task. If you can't provide a reasonable estimate, inform the user that the particular operation will take few minutes to complete. Do provide him with the choice of cancelling / stopping the operation. Your interface should never be unresponsive to user input. Users should always be able to interrupt time-consuming tasks and get immediate feedback from the GUI. In distributed systems, aborting a complex task can sometimes be as time-consuming as completing the task. In these cases, it's better to let the task complete and discard the results. The important thing is to immediately return the GUI to the state it was in before the task was started. If necessary, the program can continue the cleanup process in the background. iii. Stay in Sync Distributed applications often display information that's stored on remote servers. You need to make sure that the displayed data stays in sync with the remote data. One way to do this is to use explicit notifications. For example, if the information is part of the state of an Enterprise JavaBeans component, the program might add property change listeners for each of the properties being displayed. When one of the properties is changed, the program receives a notification and triggers a GUI update. However, this approach has scalability issues: You might receive more notifications than can be processed efficiently. To avoid having to handle too many updates, you can insert a notification concentrator object between the GUI and the bean. The concentrator limits the number of updates that are actually sent to the GUI to one every 100 milliseconds or more. Another solution is to explicitly poll the state periodically-for example, once every 100 milliseconds. iv. If It Looks Idle, It Should Be Idle When a program appears to be idle, it really should be idle. For example, when an application is iconified, it should remove listeners that have been installed on objects in other processes and pause or terminate polling threads. Conversely, if a program is consuming resources, there should be some evidence of that on the screen. This gets back to letting the user know what's going on. Imagine a program that displays the results of a database query each time the user presses a button. If the results don't change, the user might think that the program isn't working correctly. Although the program isn't idle (it is in fact performing the query), it looks idle. To fix this problem, you could display a status bar that contains the latest query and the time it was submitted. AdventNet Inc. 72

74 24.9 Responsive Applications Use Threads Although threads need to be used carefully, using threads is often essential to making a Swing program responsive. If the user-centric guidelines presented in Section 24.8 were distilled down to their developer-centric essence, the rule for handling user-initiated tasks would be: If it might take a long time or it might block, use a thread. If it can occur later or it should occur periodically, use a timer. Occasionally, it makes sense to create and start a thread directly; however, it's usually simpler and safer to use a robust thread-based utility class. A thread-based utility class is a more specialized, higher-level abstraction that manages a worker thread. Concurrent Programming in Java by Doug Lea describes many other useful thread-based abstractions. Swing provides a simple utility class called SwingWorker that can be used to perform work on a new thread and then update the GUI on the event-dispatching thread. SwingWorker is an abstract class. To use it, override the construct method to perform the work on a new thread. The SwingWorker finished method runs on the event-dispatching thread. Typically, you override finished to update the GUI based on the value produced by the construct method. (You can read more about the SwingWorker class on The Swing Connection.) The example given below (Code 23.1), shows how SwingWorker can be used to check the modified date of a file on an HTTP server. This is a sensible task to delegate to a worker thread because it can take a while and usually spends most of its time blocked on network I/O. final JLabel label = new JLabel("Working..."); SwingWorker worker = new SwingWorker() { public Object construct() { try { URL url = new URL(" return new Date(url.openConnection().getLastModified()); } catch (Exception e) { return ""; } } public void finished() { label.settext(get().tostring()); } }; worker.start(); // start the worker thread Code 23.1 In this example, the construct method returns the last-modified date for java.sun.com, or an error string if something goes wrong. The finished method uses SwingWorker.get, which returns the value computed by the construct method, to update the label's text. Using a worker thread to handle a task does keep the event-dispatching thread free to handle user events; however, it doesn't magically transform your computer into a multi-cpu parallel-processing machine. If the task keeps the worker thread moderately busy, it's likely that the thread will absorb AdventNet Inc. 73

75 cycles that would otherwise be used by the event-dispatching thread and your program's on-screen performance will suffer. There are several ways to mitigate this effect: Keep the priority of worker threads low. Keep the number of worker threads small. Consider suspending worker threads during CPU-intensive operations like scrolling. Using threads is relatively easy; however, using them correctly can be difficult. You can find the example that illustrates as many of these guidelines and techniques as possible in Example : Searching the Web. For tips and tricks on enhancing performance and responsiveness of your application, refer Java Platform Performance. AdventNet Inc. 74

76 25: Wizards Even in well-designed software, complex or unfamiliar tasks can be difficult. You can make performing difficult tasks easier and quicker for users by providing a kind of user interface known as a wizard. A wizard is a window that leads a user through a task one step at a time - requesting a series of responses from the user and then performing the task based on those responses. Except for a user's responses, a wizard provides all the information needed to perform the task. Typically, wizards are intended to simplify a task so that inexperienced users can perform it easily, or to expedite a complex task by grouping its steps in a single place. Often, wizards both simplify a task and expedite it. This chapter introduces wizards and then describes : How to decide whether users need a wizard How to design the layout and behavior of wizards The links given below covers them in detail : 25.1 Fundamentals of Wizards o Standalone Wizards and Embedded Wizards o Typical Uses of Wizards 25.2 Deciding Whether You Need a Wizard 25.3 Providing Alternatives to Wizards 25.4 Types of Wizard Pages o User-Input Pages o Overview Page o Requirements Page o Confirmation Page o Progress Pages o Summary Page 25.5 Designing Wizard Pages 25.6 Designing the Title Bar 25.7 Designing the Bottom Pane 25.8 Designing the Right Pane o Subtitles o Main Instructions o User-Input Areas o Additional Instructions o Navigation Instructions 25.9 Designing the Left Pane o Deciding What to Display in the Left Pane o Left Pane With a List of Steps o Left Pane With Steps That Branch or Loop o Left Pane With Help Text o Left Pane With Steps and Help Text o Left Pane With a Graphic AdventNet Inc. 75

77 25.10 Designing Wizard Behavior o Delivering and Starting Wizards o Supporting a User's Entire Task o Positioning and Sizing Wizards o Checking Wizard Dependencies and User Input o Providing Operational Feedback in Wizards o Alerting Users in Wizards Designing Installation Wizards o Choosing a Location for a Wizard's Code o Helping Users Decide Whether to Install o Tasks That Installation Wizards Should Handle AdventNet Inc. 76

78 26: I18N Support in UI Reference 1. Internationalization Concepts & Terminology - Designing Enterprise Applications with the J2EE Platform, Second Edition. 2. Here's the Most Frequently Asked Questions about Internationalization. 3. Internationalization of the Java 2 platform, Standard Edition, version Internationalization : Localization with Resource Bundles, Article by John O'Conner. 5. Essentials of the Java Programming Language - Chapter 12 : Internationalization by Monica Pawlan. 6. Know about Effective Layout Management - Short course. 7. Find the JavaDocs for the Class ComponentOrientation. AdventNet Inc. 77

79 27: Events and Alarms This chapter talks in details about monitoring the application's change of state and handling them. The following topics cover them in detail : 27.1 Events and Alarms 27.2 Alarm Conditions 27.3 Levels of Severity 27.4 Alarm Status 27.5 Logging Events 27.6 Displaying Alarm Views o Alarm Graphics o Monitored-Entities View o Detailed Alarm View AdventNet Inc. 78

80 28: Keyboard Shortcuts, Mnemonics, and Other Keyboard Operations This chapter provides the Keyboard shortcuts, Common Mnemonics and the various other keyboard operations for the user interface components. Please look into the following for details: 28.1 Keyboard Shortcuts, Mnemonics, and Other Keyboard Operations 28.2 Common Keyboard Shortcuts o Common Keyboard Shortcuts Vs AdventNet Keyboard Shortcuts 28.3 Common Mnemonics 28.4 Backing Windows and Internal Windows 28.5 Checkboxes 28.6 Combo Boxes 28.7 Command Buttons 28.8 HTML Editor Kits 28.9 List Components Menus Radio Buttons Scrollbars Secondary Windows and Utility Windows Sliders Split Panes Tabbed Panes Tables Text Areas and Default and Styled Text Editor Kits Text Fields Toggle Buttons Tool Tips Toolbars Tree Components Common Keyboard Shortcuts Vs AdventNet Keyboard Shortcuts Standard Shortcuts AdventNet Shortcuts Sequence Equivalent Sequence Equivalent Ctrl-N New (File menu) Ctrl-D Debug (g - Mnemonics) Ctrl-O Open (File menu) Ctrl-J Load <File> Ctrl-W / Ctrl-4 Close (File menu) Ctrl-U Unload <File> Ctrl-S Save (File menu) Ctrl-Shift-J Load <File> (Second Priority) Ctrl-Shift-S Save As (File menu) Ctrl-Shift- U Unload <File> (Second Priority) AdventNet Inc. 79

81 Standard Shortcuts AdventNet Shortcuts Ctrl-P Print (File menu) Ctrl-M Mib Viewer / Mib Browser Ctrl-Q / Alt-4 Exit (File menu) F4 Settings / Properties Ctrl-Z Undo (Edit menu) F7 Show / Hide Status Window Ctrl-Y Redo (Edit menu) Ctrl-L Compile Ctrl-X Cut (Edit menu) Ctrl-R Run Ctrl-C Copy (Edit menu) Ctrl-T Threshold Configuration Ctrl-V Paste (Edit menu) Ctrl-] Match Brace Delete Ctrl-F Ctrl-G / F3 Ctrl-A Ctrl-H Ctrl-E Delete (Edit menu) Find (Edit menu) Find Again (Edit menu) Select All (Edit menu) Replace (Edit menu) Align Center (Format menu) Ctrl-R Align Right (Format menu) Ctrl- + Ctrl- - Ctrl-1 Ctrl-0 F5 F1 Shift-F1 Alt- <- Alt- -> Zoom In (View menu) Zoom Out (View menu) Actual Size (View menu) Fit to Screen (View menu) Refresh (View Menu) Help Contents (Help Menu) Contextual help (Help Menu) Back Forward AdventNet Inc. 80

82 Part V : Embracing ALF 29: Things to do Before and After... This checklists enables to evaluate various aspects of your prototype. This chapter covers the following : 29.1 Things You Can Do Yourself o Before you Start o Keyboard Access and Focus o Theming Colors and Contrast o Animation 29.2 Things You Can Do with Other People o Get Early Feedback o Internationalization and Localization 29.1 Things you can do Yourself Before You Start Write down the type of people you expect to use your application. Then write some "scenarios" for each type of user a little story that describes the typical tasks those users will use your application for. These tasks should be along the lines of: "Fred needs to find an about widgets that he received last week" rather than "Fred clicks on the Find button and types widgets into the dialog". Table 29.1 This way, you can use the same scenarios to test and compare different interface designs, and to spot any missing functionality. Include these user descriptions and scenarios with the documentation you commit to CVS. This way, other contributors will get to understand your users too, can help to develop the application with that knowledge, and can provide more scenarios of their own Keyboard Access and Focus When you have started implementing your interface, hide your mouse, and make sure you can still use it to do everything using only the keyboard. Implement keyboard functionality at the same time as mouse functionality don't leave it until the end. Using only keyboard commands, move the focus through all menu bars and toolbars in the application. Also confirm that: 1. Context sensitive menus display correctly (F1 / Shift-F1). 2. Tool tips can be popped up and down for all controls that have them. 3. All functions listed on the toolbar can be performed using the keyboard. AdventNet Inc. 81

83 4. You can fully operate every control in the client area of the application and dialog boxes. 5. Text and objects within the client area can be selected. 6. Any keyboard enhancements or shortcut keys are working as designed. 7. Verify that when moving among objects, the visual focus indicator is easy to identify at all times Themes, Colors and Contrast Test various themes to ensure that your application respects all the available settings. Test your application with black and white, high contrast themes and confirm that all information is still conveyed correctly. If you don't have a suitable high contrast theme available to test, print off some screen shots in black and white (not grey scale) and make sure all the important information is still visible this will approximate what a high contrast theme user will see Animation Ensure you have implemented an option to turn off any animation in your application (for accessibility reasons), and that it is working as designed. Turn the animation off. Confirm that all information is still conveyed correctly Things you can do with Other People Get Early Feedback It's always tempting, but don't start coding your interface straight away. Sketch out some ideas on paper first, or in Glade or HTML if you prefer. (But don't be tempted add any functionality at this point if you do it this way!) Show these prototypes to other people - Ask them to use these prototype interfaces to run through some of the scenarios you came up with earlier. You'll probably get questions like "how would I do X", "which menu is Y on"... these questions will help you think about the interface from the user's viewpoint. You'll probably also get a few suggestions about how to do things differently - these ideas may or may not turn out to better than yours, but any idea from a potential user is worth considering! You should also consider seeking opinions from the AdventNet Usability team [uetteam@adventnet.com]. They have designed many user interfaces before and may be able to spot potential problems at this early stage, before you take your design too far to change easily. Once you've decided on the basic interface design and have started coding parts of it, find somebody to try it out again - it doesn't have to be the same person. You'll probably find some more problems that were hard to see on your static paper prototype. By finding these now, it's usually not too late to fix them without too much trouble Internationalization and Localization If you intend your application to be translated into different languages, check for the behavior of your layout, such as not leaving enough space for translated labels, shortcut keys that cause problems on a different keyboard layout, or using new terms in your application that are hard to translate. AdventNet Inc. 82

84 If possible, try out your application with users from the locales you are targeting. This will help you determine whether users understand how to use the application, if they perceive the graphics and colors the way you intended, and if there are words or images in the application that may cause offence to users of that locale. AdventNet Inc. 83

85 30: User Interface Checklist 30.1 Purpose : This checklist is for AdventNet UI designers and developers. It provides reminders for the details that can sometimes be overlooked when creating a screen. This document is not intended as a replacement for the AdventNet Look and Feel Guidelines. Please consult ALF Guide for complete design guidance. 1. Titles 2. Text If a dialog is called from a menu, its title should be the same as the menu item. Otherwise for all other dialogs: <dialog name><space><hyphen '-'><space><product name> / <Feature name> Dialog name will be the Feature name/object name which popped up the dialog (eg. wintest1 - Properties). Consult Usability Engineers Team for any clarifications. Ensure that your Application's Title bar has the Product specific icon. There need not be any Title bar icon for Modal Dialog / Wizards. The Product Icon should be placed in the Title bar of the Modeless Dialog. Are you using sentence capitalization for text that is in a complete sentence? (Details) Are you using headline capitalization in other components, e.g., checkbox labels, menu names? (Details) Every word is capitalized except articles ("a", "an", "the"), conjunctions ("and", "or", "but", "so", "yet", and "nor") and prepositions with fewer than four letters (e.g., "in"). The first and last words are always capitalized in headline capitalization. 3. Keyboard Can the dialog be used without touching the mouse? Arrow keys should allow users to move within groups of components. For example, Tab will put focus in a list box and then the arrow keys will move focus among the list box items. The Tab key is used to move among checkbox. Make sure whether the currently selected value is set into the focused component (the behaviour is specific to the components refer behaviour) when the 'Return' key is pressed. If it is a button then the Action Performed Event should be fired. Does the dialog come up with focus set on the component that is normally used first? (Details) Is tab traversal set correctly, e.g., as in the diagram below? AdventNet Inc. 84

86 4. Resizing Figure 30.1 Did you specify appropriate resize behavior for your window's components? Since there are no hard and fast resizing rules, consult Usability Engineering Team or post a question to uetteam@adventnet.com if you have any questions. 5. Mnemonics Does every component have a mnemonic? If the component is labeled, does its label have a mnemonic? (Details) Note: use "labelfor"! (Details) Are the mnemonics all unique? Make sure that there is no conflict between mnemonics. 6. Shortcuts If you have shortcuts, are you sure they don't conflict with existing ALF shortcuts or with JLFdefined shortcuts (Global Shortcuts)? 7. Validation Did you bring up a Alert dialog box when the screen is submitted with incomplete information. Did you bring up a Alert dialog box when invalid values are entered in the components (JTextField, JPasswordField, etc.). Does your Application's data fields prompt with a Alert Dialog box when ever a wrong value / invalid character is keyed in. 8. Menu bar (Details) Ensure that your Application has only one Menu bar, placed immediately below the Title bar. All the operations / functions that your application has should be available in the menu bar. Make sure your Menus / Menu items become Available or Unavailable according to the context. Does your application adds Menus in the Menu bar dynamically which results in a dancing menu bar. AdventNet Inc. 85

87 9. Toolbar (Details) Ensure that all the buttons are visible in the toolbar on the default pop up of the application. Handle the toolbar buttons properly by making it available or unavailable (Enabling / Disabling) according to their need in that particular screen. Don't add buttons for Help, Close or Quit to your toolbar by default, as these are rarely used and the space is better used for more useful controls. Omit all toolbar controls from the keyboard traversal order so that the expert users could navigate more easily. Provide keyboard access to the toolbar items by providing a equivalent action in the Menu bar. 9. Status bar (Details) Is your Status bar placed in the bottom of the application window. In a window's status bar, ensure that each message fits the available space when the window is at its default size. Make sure that you use status bars only in application windows. Do not use them in dialogs, alerts or other secondary windows. Do not display critical messages in the Status bar. Use Alert boxes to display the critical or fatal error messages. When there is no interesting status to report, leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the status bar, the user is more likely to notice it. 10. Contextual menu (Details) Ensure that all the Clickable components (except JButton), should have a Contextual Menus. Check if the contextual menu items present for a particular component make sense. 11. Help Pressing 'F1' in the keyboard should invoke the HTML version of the Help. Pressing 'Shift+F1' should invoke the 'What's this?' (Contextual Help) of the component that has the focus. In certain case the 'F1' can invoke contextual help where the main help / HTML Help version is not present (still it should have access to Shift+F1 for consistency). Check whether the context sensitive help button is placed in the Top Right corner (below the title bar) of the dialog and it is consistent through out. 12. Buttons (Details) Are buttons right-aligned where appropriate? (this depends on the locale that you are using.) Does your dialog have a default button? (Details) Is help button the last button in row of buttons? Is default button the first button in row of buttons? 13. Ellipses (...) in Menu Items and Buttons Did you use ellipses for menu items and buttons that require specification to complete their action? (Usually, this means they display a dialog requesting user input, and that some action takes place after the dialog is dismissed.) (Details) Examples: Save As..., New..., Print... But, the Preferences menu item would not have an ellipsis, since displaying the Preferences dialog is not required to complete the intended action; it is the intended action. 14. Behaviour Ensure that the components (JTextField, JCombobox, JButton, etc.) are made available or unavailable accordingly. AdventNet Inc. 86

88 15. Work around Make sure that a space is not used as the first character in checkboxes and radiobuttons! (because of a bug in Swing # in Bugparade) 16. Spacing Are you using appropriate inter-component spacing? The figures below provide a rough guideline, but consult this section of the JLF guidelines for more information. (More Details) Figure 30.2 Figure 30.3 Figure 30.4 AdventNet Inc. 87

89 Figure 30.5 Figure 30.6 Figure Tool tips for properties This section addresses the use of tool tips in property sheets, where tool tips are perhaps the most necessary, but where they can be difficult to write. For properties in a property sheet, tool tips can be used to do many things, such as: describe what the property does describe possible property values describe what form to use when entering a value (for example, noting which delimiter to use when entering strings) There are no rules about what type of information a tool tip must provide. A good tool tip presents the information that is most useful to the user for that particular context and which may not be obvious to the user. Check whether the Tooltips are Internationalized. AdventNet Inc. 88