GUI Design
The hardest part about GUI programming isn't the mechanics of managing windows and controls; with a tool like GUIBuilder, a lot of the mechanical details can be automated. The real difficulty is learning how to think in an entirely new way. In a GUI program, you do not directly control program flow; you create a window with various graphical controls and wait for the user to do something. As long as a control is visible and enabled, the user can activate it (push a button, select a menu item, check a check-box or radio button, or type into an edit box, for example). Your program needs to be prepared to respond in a logical way to whatever the user chooses to do. Your direct control over the process is limited. One of the more useful approaches is to only make windows and controls visible and active when you are prepared to respond to them. For example, if there is no printer configured, you can gray out printer-related functions. The user can only select the Print option when you know the printer is available, so error handling becomes much simpler.
GUIBuilder does a good job of managing the technical (housekeeping) details of an event-driven GUI program, but it can't help out with program design. Because a GUI program operates very differently from a traditional character mode program, it's a good idea to invest some time in reading and thinking about GUI design issues. The following references are a useful starting point:
The Windows Interface Guidelines for Software Design (Microsoft):
https://www.microsoft.com/win32dev/uiguide/
Macintosh Human Interface Guidelines (Apple):
https://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html
Interface Hall of Shame, Interface Hall of Fame, and useful links:
Articles in The Advantage: