Dialog Box Woes

Development got a requirement to display some data in the application. In addition, the user required the ability for some users to change that data. This is simple stuff. I figured this would be perfect for a Windows dialog box to handle. The only point of interest would be how the data gets saved. I figured that the system could enable a Save button when the user change the data. Then they could press this button to actually store the changed value. I figured this was a simple enough design.

A developer took this design and ran with it. However he figured we needed a little more details in the design. So he wrote down the flow for the scenario where the user changes the value, but then tries to close the dialog box without saving. At that point there were a few options that this developer wanted to handle: (1) user wants to save the data and continue closing the dialog, (2) user wants to close the dialog box without saving, and (3) user does not want to close the dialog box. To tell the truth, this confused one of the acceptance testers in the customer organization. So I explained how these scenarios would work.

The big day came when we were supposed to walk through the design with the customer. Hardly anybody from my team showed up on time. So my boss told me to take it away. I went through the design. It was easy because I did most of the design for all the requested changes. When I got to the part where the tester did not understand, I thought I would explain once again the different scenarios on closing. This erupted into a lengthy discussion on all of the paths through the logic. It felt like we had missed the point. The user wanted to view and save changes to some data. We got derailed and were discussing all kind of user interface design.

In retrospect, I think we should have stuck to a simpler method for dealing with this dialog box. If the user makes a change, we should save that change on exit. That’s the original intent of dialog boxes. I think developers have made things more complicated than they should be. This is, in essence, a user interface design issue. The best designs are simple and easy to understand. Following simple designs will keep us focused on the business of the applications.