Conform to the User’s View of the Task Don’t make the user do steps that make it easier to write the program but don’t have meaning as far as the task is concerned Switching to command mode to move Stating a reason for the move Assigning a name to the move Specifying to what game the move applies Arbitrary restrictions (limits on length, Undo, all fields must be filled, sort only three keys, etc. )

Don’t impose your problems on users Keep to the user’s vocabulary Don’t reference program internals Find a power/complexity balance Sensible defaults Templates or canned solutions Progressive disclosure Generic commands (create, open, move, copy, save, delete, print, show, properties, follow link) Do a small number of tasks well (easily)

Don’t Complicate the User’s Task Common tasks should be easy (“the usual”) Support customization (change defaults) Provide wizzards (step-by-step guides with menus) No extra problems to solve File in wrong format to use in program Program incompatible with common software Odd error messages (contrary to facts user knows) Inconsistent terms cause confusion “insert” instead of “set” Align horizontally vs ? PIN vs. password

Promote Learning Think “outside-in” (designers tend to want to surprise, amaze and delight users with the treasures they build into software. That’s not why the user is there). Textual ambiguity Typographical ambiguity Graphical ambiguity (misinterpreted 3D shading) Consistency3—foster habits Dangerous because multi-dimensional problem. Need to seek user’s perceptions Provide low-risk environment Minimize consequences of mistakes Exploration == Learning

Tool Bars JToolBar objects display the expected behavior when dragged around the window IF the JOptionPane is managed by a BorderLayout AND the JToolBar is the only component that can be moved, AND it can move to any of the four border areas or outside the window (the component referenced by the tool bar is placed in the CENTER). setFloatable(false) prevents dragging. The tool bar can hold more than buttons.

Internal Frames To develop a windows-within-windows GUI you generally add JinternalFrame objects to a JDesktopPane that is a child of JLayeredPane (coming up), that sits on the RootPane and manages several content panes. Everything on (in) the JDesktopPane is invisible by default. MyInternalFrame is a child intended for multiple instances. Internal frames are more flexible than JFrames but they require more programmer attention as well. You must set the size You should set the location There are separate dialog classes for use in internal frames You must make the internal frame visible after adding it. You must write internal frame listeners to catch the window-like events (close, iconify, maximize).

Examples The intermediate containers ToolBarDemo ToolBarDemo2 InternalFrameDemo MyInternalFrameDemo