Tab Order
You would be amazed at the number of applications where the tab order of the controls on the user interface does not follow a consistent flow around the window. Imagine using the file open dialog in windows but instead of the nice flow you expect the focus shifts from the file name to the list of drives to the open button to the list of files etc. This would be very frustrating and annoying for your users.

Make sure the tab order of your form flows around the controls in the order that the user expects, if this sequence is not obvious ( it normally is ) then ask the user! Another aspect to consider is the focus starting point, a lot of the time the top left hand corner is the best starting point but in the file save dialog the filename is the start location which is probably where you want it to be. Again ask your users.

One last thing is to make sure you do not have a tab order on things that do not make sense, for example you may have used a group box to logically group a few edit fields together for the user, but this group box does not need to be part of the tab sequence.

Accelerators
This is the feature of windows that allows users to use the ALT key and a letter to jump to a field or menu. The user knows which key to use because one of the letters on the field or menu is underlined. The most important thing is to make sure you add these to your interface, it is very annoying to keyboard users to have to tab through 20 fields or scroll through 10 menu items using the cursor keys just because you where too lazy to add accelerators to the fields and menu items.

When you are adding accelerators you should start with the menu, if you are using words on the menu that are also in other applications then check to see what accelerators are used in those applications and where possible make yours the same. It would be very annoying if your application used i for the accelerator on the File menu when all the other applications in the world use F.

Next you should add accelerators to each item on the sub menus. Make sure there are no duplicates and start with the most commonly used menu items first. These most common items should have the first letter on the first word as the accelerator.

Then move on to your windows. The golden rule is that you cannot use any accelerators that have been used by the menu. Then follow the same rules as the the menu items, start with the most important fields, if you do not know what these are then ask the user. Use the first letter of the the first word of the most frequently used items and then work your way backwards. For complex or large windows I normally have a piece of paper with the alphabet written on and tick them off as I go.

Consistency is also key, if you have a Search button on 10 windows in your application but 5 accelerators use S, 3 use E and the rest use H then the user does not gain as much benefit as if they where all same letter.

One last not is that any default or cancel buttons do not need accelerators, the user will 99.9% of the time use the Enter button and the Escape button so you can use those valuable two letters else where in your windows.

Views and Panels
These are new additions to the GUI interface arsenal and are a method for splitting a window into multiple resizable sections each dealing with a slightly different aspect to the application. These can be a great productivity aid for the user BUT make sure there is a keyboard equivalent to the mouse for changing the focus between the views.