With our design papers in hand, we go on to recreate all the forms we created on Day 1. The original forms are always thrown away. Before we start any form generation, we must first edit the tables to add the captions the user wants for each field. Microsoft Access permits each field to have a caption that will be used for forms and reports. At this point in time, any multiple captions for the same field should be resolved by the user so that there is consistency.
The second step is to create queries that correspond to each of the screens we designed in our GUI meeting and to save the query with the same name. No forms or reports should use tables directly.
We now regenerate the forms, and our demo query looks like this:
We automatically create the forms matching each query and then go on to edit them so that they match the design from the GUI meeting. The majority of this activity is simply dragging the fields to their new locations and saving the form.
Add only the code that is needed to connect forms and reports. We are not building the application, only the GUI. A GUI prototype means that we are not concerned about validation or processing, only the appearance. The reasons we moved the data to a Microsoft Access database included:
Our last step is to walk through the forms from the main form, printing them as we go. We compare these new screen images to our hand-drawn paper drafts, correcting any errors or omissions. We send a copy of the final version to the user for comments.
After we have received written comments and suggestions from the user, we implement the changes in the forms and set up time to work with the user. The purpose of this time with the user is to allow the user to practice using the current GUI to identify any flow or design problems. We will observe while the user attempts to perform actual work in the test database. Action items to look for in this process are:
The test results are used to iterate the queries, forms, and reports. Eventually, we will obtain a satisfactory application. At this point, most mainframe developers should be in shock; we have spent a great deal of time on the user interface—dragging controls onto forms, cutting and pasting paper—and very little time on coding. Keep in mind that all the business rules validation issues are moved to the mainframe or the ODS server. We do not have to code them into the application.
Tuning the application is something that often occurs after the rollout to the user. The prototype should be carefully built to capture information about queries and the sequence of operations. This information can be used to simulate actual user load on the system. This type of benchmarking is not a one-day event if there are problems. Microsoft's internal information management group have started producing in-house applications that can log every query, as well as the query performance. These logs can then be played back automatically on test lab PCs to emulate various operating environments.
With our prototype and the time left, the process is simply one of comparing the query execution times using the actual database. The process of timing can be done in a few lines of Microsoft Access code.
Sub pbTitles_Click ()
On Error GoTo Err_pbTitles_Click
Dim DocName As String
DocName = "rptTitles"
startticks&=TimeGetTime()
DoCmd OpenReport DocName, A_PREVIEW
EndTicks&=TimeGetTime()
RecordDocPerformance DocName, StartTicks& - EndTicks&
Exit_pbTitles_Click:
Exit Sub
Err_pbTitles_Click:
MsgBox Error$
Resume Exit_pbTitles_Click
End Sub
This gives us accurate times to within a millisecond for the queries. You could even modify the Wizards to always automatically add these lines.