Exercises for teaching GUI / Windows interaction basics It is now very easy to plop together some visual User Interface controls on to a form and hook them to events. In Microsoft Windows, there are a staggering number of properties and events available for controlling all aspects of a GUI. While simple apps can be created in moments, more complex ones involving enabling / disabling sets of controls, etc., can be fraught with unexpected complexity and paradox.

What are some good initial projects for working with just the UI aspects of a design? Ignore all the details of what the events will actually do, and get the user interaction working, to do some nontrivial things? We are currently using as our textbook "C# Programming" by Doyle, and the Windows GUI section is chapters 9 and 10. The examples in chapter 9 had some poor practices (while loop inside a button click event handler?) which might be improved on, perhaps with the more detailed information in chapter 10, which covers input controls such as textboxes, radio buttons, checkboxes and listboxes.

One example I created was of a simple method for students to "clock in and out" of the classroom sessions (as part of workplace readiness training). It looks bone-simple: a little box with their Windows Domain Name, two radio buttons for IN and OUT actions, and a few read-only textboxes that display accumulated time for the day and week. (It connects to a database on a server). I wanted the interface to behave "a little strangely":


Neither radio button would be checked when the program starts
Attempting to clock IN outside of time bounds would show OUT
A database access failure shows NO radio buttons checked
The app becomes 'topmost' at the start and end of each time period
It stops being topmost when the user interacts with it


This takes some interesting code and unusual settings at design time, yet it creates an ideal interface to allow the desired functionality and nothing undesirable. It could not be simpler. What other examples of Windowing interface situations would make for concise, understandable and broadly applicable exercises? How can the students learn the pitfalls of event-driven interfaces without having to master them entirely? In particular, what does not make sense in an event-driven scenario?
The last time I took a session on UI, that was when I was teaching these students who had finished a course on C sharp (dot net) and now wanted to build simple UI so they can turn their just learned programming skills into visibly usable software.

Since they were on dot net, I advised them to start by building a calculator using WPF. When I say calculator, it was a simple calculator. Build the number pad, and then implement just the addition and subtraction. While many of them were proficient in programming, they found themselves baffled...connecting the UI with code that would otherwise work just fine on the console. As they got the hang of things, I asked them to add more and more UI elements, until they had a full fledged scientific calculator with a fairly complicated UI. 

My advice to those who are new to UI is to allow the UI to evolve, and make sure that your backend development skills are up to the mark.