Java Look-and-Feel Design Guidelines – Part IV - PowerPoint PPT Presentation

java look and feel design guidelines part iv l.
Skip this Video
Loading SlideShow in 5 Seconds..
Java Look-and-Feel Design Guidelines – Part IV PowerPoint Presentation
Download Presentation
Java Look-and-Feel Design Guidelines – Part IV

play fullscreen
1 / 41
Download Presentation
Java Look-and-Feel Design Guidelines – Part IV
Download Presentation

Java Look-and-Feel Design Guidelines – Part IV

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Java Look-and-Feel Design Guidelines – Part IV Eileen Kraemer University of Georgia CSCI 4800/600

  2. Previously, we talked about … • Applet v. Application • Placement of applets • Designing for accessibility • Checking for accessibility • Usability testing • Internationalization / localization • Creating/using resource bundles

  3. Designing for accessibility • Provide accessible names, accessible descriptions • Use mnemonics and keyboard shortcuts • All interface components must be keyboard traversable • Assign initial keyboard focus • Specify tab traversal order • Don’t customize fonts or colors unnecessarily • If necessary, use properties to specify colors, fonts • Use dynamic GUI layout • Custom components must implement accessible

  4. Now, … • … let’s look at the “nuts and bolts” of accomplishing these goals

  5. The Java Accessibility API (JAAPI) • standard extension in all releases of the Java 2 platform • component can utilize this extension by implementing the Accessible interface • only one method call: getAccessibleContext() • returns an instance of AccessibleContext • specific to the component • provides the info and functionality to enable accessibility • AccessibleContext • info about the component's role (button, checkbox, etc.) • accessible name (more on this soon) • Number of children, & more • Can generate accessibility events when a noteworthy event has occurred. • All of the standard JFC/Swing components implement the Accessible interface

  6. Accessible name, description: how used • accessible name • succinct explanation of component’s purpose • assistive technology will often present (speak) the name of each component encountered by a user • accessible description • more verbose explanation • provide in cases where additional info needed • assistive tech retrieves when user requests it

  7. Accessible name: how to set • JFC/Swing components with non-editable text (menu items, buttons, etc.) have accessible name set automatically • Other components need to have accessible name set by developer • If the component has a label: JTextField text = new JTextField(20); JLabel label = new Label("Address Line 1"); label.setLabelFor(text); // ... Add the text and label to a Container • For ImageIcons , create using: ImageIcon(URL url, String name);

  8. Accessible description: how to set • Accessible descriptions set automatically by setting tooltiptext: JComponent.setTooltipText( ) • If component has no label or tooltip, directly set name & description: • permanently overrides values pulled from label or tooltip AccessibleContext context = component.getAccessibleContext(); context.setAccessibleName("Zip"); context.setAccessibleDescription("Recipient's Zip Code");

  9. Don’t Customize Fonts or Colors Unnecessarily • JFC/Swing components/ applications automatically inherit font and color properties from desktop and user prefs. • In most cases, get good results by accepting user's preferences.  

  10. But, if you have to specify colors and fonts …. • Use a properties file • Example: • want flight simulator to have a red "stop" button in Western countries • define a property, • store it in a file, flightsim.stop.color=#ff0000

  11. Then, use the properties: • The program can load properties file as a ResourceBundle: ResourceBundle resources = null; Color stopColor =; // the default try { resources=ResourceBundle.getBundle("flightsim"); String colorString = resources.getString("flightsim.stop.color"); stopColor = Color.decode(colorString); // the specified } catch (MissingResourceException missingException) { // Report the error, according to severity } // stopColor has now been customized

  12. Use Dynamic GUI Layout • Don’t call setSize() with constant values. • defeats dynamic layout • resulting application won’t adapt properly to users' settings. • Instead, adjust the size of each JFrame, JDialog, and JWindow at creation and each time its contents change window.setSize(window.getPreferredSize()); • allows all nested layout managers to affect the size and position of each object at runtime. • If component’s preferred size is not acceptable(rare), call setSize() with a value between getMinimumSize() and getMaximumSize().

  13. Dynamic LayoutManagers • position graphical objects relative to each other • changes in size are handled automatically • components never obscure one another. • All JFC/Swing layout managers are dynamic (BorderLayout, FlowLayout, GridBagLayout, etc.) setLayout(null); // Don’t do this!! • Requires manually setting (x,y) of every component. • interface won’t work right with many accessibility options, internationalization , user-defined preferences.

  14. Custom Layout Managers • Implement LayoutManager2 interface • (old LayoutManager interface is obsolete). • Components should be positioned relative to each other when the toolkit invokes layoutContainer() on the custom layout manager.

  15. All Interface Components Must Be Keyboard Traversable • … because many people can’t use a pointing device effectively • Pressing tab key should move input focus from component to component • shift-tab should move focus in opposite direction.

  16. How to implement? • default FocusManager sets focus order : left-to-right and top-to-bottom. • If component shouldn’t receive input focus, create a subclass and override isFocusTraversable() to return false. • Invoke setNextFocusableComponent() on each JComponent to "hard-wire" the focus traversal order. • Messy to do this on some components and have others use the default ordering. If used, invoke on all JComponents in a window. • Implement a subclass of java.awt.FocusManager and install it with the static method FocusManager.setCurrentManager().

  17. Use Mnemonics • Mnemonics • underlined characters that appear in menu items and on the buttons in some dialog boxes. • can only be activated when the item is visible and does not require a modifier key (e.g., the user does not need to press the Alt key). • If keyboard use is to be practical, then All menu items must have mnemonics menu = new JMenu(); menu.setText(resources.getString("fileMenu.label")); menu.setMnemonic( resources.getString("fileMenu.mnemonic").charAt(0)); item = new JMenuItem(); … item.setMnemonic( resources.getString("").charAt(0)); …

  18. Use Accelerators • displayed on menu items or buttons in parentheses after the item's text [e.g., "Save (Ctrl+S)"]. • requires the use of a modifier key • can be activated any time the application's window has the input focus. • … item = new JMenuItem(); item.setAccelerator(KeyStroke.getKeyStroke( resources.getString(""))); …

  19. Custom Components Must Implement Accessible • All standard JComponent subclasses implement this interface and do everything necessary to be accessible • All custom components should extend a standard class as far down the JFC/Swing inheritance hierarchy as possible. • For example, you want round buttons • First try to extend JButton, override all paint methods, add support for any new properties. • If JButton is too restrictive, then try to extend JButton's superclass, AbstractButton. • Only if AbstractButton is too restrictive should you extend directly from JComponent. • JComponent doesn’t implement Accessible, so subclass must do more work to work w/ assistive technologies. • Some methods do exist in JComponent to help: getAccessibleParent() and getAccessibleName() will work properly for most JComponent subclasses, with no additional code (other than 'implements Accessible').

  20. Custom components, continued • must express its accessible role as specifically as possible. See: • Each JFC/Swing class contains a protected inner class that actually does the accessibility work, and the root class is JComponent.AccessibleJComponent • To extend accessibility behavior of subclass, create a protected inner class that extends the inner class of the superclass • override getAccessibleContext() to create an instance of this new accessibility class.

  21. Example public class WarningLight extends JComponent implements Accessible { public AccessibleContext getAccessibleContext() { // variable accessibleContext is protected in superclass if (accessibleContext == null) { accessibleContext = new AccessibleWarningLight(); } return accessibleContext; } protected class AccessibleWarningLight extends AccessibleJComponent { public AccessibleRole getAccessibleRole() { return AccessibleRole.ALERT; } … // Implementation of WarningLight omitted... }

  22. Test Cases • 1. Don't touch your mouse • Bring up each window and popup in your application and attempt to visit every component using only the Tab key on the keyboard. • Use the application without touching the mouse • Verify that: • Application’s features are all available • Frequently-used functionality is directly accessible via an accelerator • All menu items have mnemonics  

  23. Test Cases • 2. Change the default font and color • Choose a font of 24 points or larger, and colors other than the default. • Bring up each window of the application and verify that screen objects do not overlap and that the colors are correct. • If overlapping occurs, check the code that interacts with the LayoutManager in that window.  

  24. Test Cases • Try using a low-vision look-and-feel • Here’s a sample • Compile the file • Add this code to your application: import LowVisionMetalLookAndFeel; // ... code omitted try { UIManager.setLookAndFeel("LowVisionMetalLookAndFeel"); } catch (Exception ex) { System.out.println("Failed loading Low Vision Metal Look and Feel"); ex.printStackTrace(System.out); }

  25. Test Cases • 3. Use a screen reader • Download and install a trial version of a screen reader that works with Java applications, (more/better links coming soon) • • Bring up each window in your application and tab to every component, verifying that you hear a reasonable description of each component as it receives the input focus. • Turn your display off. • Try to use your application in this mode, accessing both core functionality and more lightly-used features.

  26. Internationalization • Identify Culturally Dependent Data • Isolate Translatable Text in Resource Bundles • Deal with Compound Messages • Format Dates and Times • Use Unicode Character Properties • Compare Strings Properly • Convert Non-Unicode Text

  27. Nuts and Bolts … • Creating and accessing resource bundles … • ResourceBundle objects contain locale-specific objects. • When you need a locale-specific object, you fetch it from a ResourceBundle, which returns the object that matches the end user's Locale.

  28. The ResourceBundle Class • each ResourceBundle is a set of related subclasses that share the same base name. • Example: ButtonLabel // base_name ButtonLabel_de // with language code ButtonLabel_en_GB // with language and country codes ButtonLabel_fr_CA_UNIX // with lang, country, and variant codes

  29. To select a ResourceBundle • invoke the ResourceBundle.getBundle method. • Example: Locale currentLocale = new Locale("fr", "CA", "UNIX"); ResourceBundle introLabels = ResourceBundle.getBundle(“ButtonLabel”, currentLocale);