1. 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. )

2. 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)

3. 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

4. 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

5. 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.

6. 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).

7. Examples The intermediate containers ToolBarDemo ToolBarDemo2
InternalFrameDemo
MyInternalFrameDemo