The In-basket: the initial stages of designing a computerised exam

The occupational psychologist for whom I work (let's call her OP from now on) unveiled her latest project for me a few days ago - computerising the 'In-basket' exam. Although I've never heard of such an exam before, it turns out that it's a well known exercise in management and there are even complete books written about it, such as In-Basket Examination: Test Preparation Study Guide, Questions & Answers. There are many references to this kind of exam on the Internet, but most seem to be connected with branches of the American police. Here's a complete example which has nothing to do with the police.

I feel a little like Jim Graves (or whatever his name was, in "Mission Impossible"): your mission, should you decide to accept it, is to convert this text-only exercise into a computerised simulation.

The original brief which I received very briefly on Friday morning was that the user is presented with a series of emails with which she has to deal. During the course of the exam, more emails appear, and even a secretary enters the room to give details of current events. Apparently the scenario which the OP uses is based on events which happened (or supposedly happened) fifteen to twenty years ago in the chair manufacturing factory in which I work (so I doubt that there is an event in which the secretary rushes in to announce that the factory is on fire).

When considering how to program the simulation, it became clear that the program would need a timer which fulfills the following functions (dig that alliteration!):

• show the user how much time is left to complete the exam
• check every minute whether there are new events/emails to be displayed
• provide a time stamp for actions that the user has taken, so that afterwards her actions can be analysed according to the order in which they were performed

Originally I had assumed that it would be necessary to fake an email application in which some mails are already present, new mails get added during the course of the exam, and others are deleted after they are handled. In order to program this, I used a TListView. It also became clear that the program would have to use the MDI model in order to display all the opened emails, instead of working one email at a time. These are all techniques which I have used in the past few months, so I didn't have any technical problems in programming; the problems which I did have were in designing the interface, or more accurately, determining how the application should be presented to the user, what she would need to do in order to undertake the exam, what actions she would need to take and how these would be represented.

I wrote a pilot version of the exam before I had even seen the Internet material. Upon reading this, I extended the pilot version until I had something interesting - but also somewhat unwieldy.

My method of working was to think hard about how I wanted to implement something (not in the programming sense of implementation, eg how to implement quick sort) and then try and get the program to do what I wanted it to do. The programming per se wasn't hard although at times it was tricky and sometimes I did get bogged down on minor details (for example, in a MDI application, the 'OnKeyPress' event does not work - the solution is to use the TApplicationEvents component).

At this point, I contacted the OP and asked some pertinent questions about the direction of the program - should all the emails be presented at once (as per the example which I gave above) so that they could be prioritised, or should they be presented via the clock, which would make the prioritising much harder. How should the email replies be dealt with? One idea which I saw was to allow the user to 'make' phone calls - how could this be represented?

One idea which I had considered was to show the user's priorities by allowing her to sort the emails in the listview via drag and drop. Whilst waiting for an answer from the OP, I actually implemented this in a small test application. Her reply stated that the priorities would come from the order in which the emails were replied to and thus there was no need for drag and drop.

 

Once I had her reply, I thought a little more about what was needed, especially about how the user would reply to the emails. I had originally designed a simple dialog box (displayed as a non-modal mdi child form) which displayed the original email text in a memo along with two memo boxes connected to a database table in which the user would write his reply and attempt to explain her reasons for replying in this manner. At the bottom of the form were, as usual, two buttons: pressing the OK button would insert the user's answers into the database and would close the form whereas pressing the Cancel button would discard the user's answers and close the form. I had conceptual problems about editing - should the user be allowed to answer the same email twice (or at least edit the original answer)? What would happen to the time stamp in such a situation?

I utilised the time otherwise wasted whilst driving home from work in order to think about the new program structure. I realised that the OK button should initially be disabled; it should only be enabled after the user actually types something in the reply field. Then I considered the fact that if there was no need for drag and drop on the listview, there was no real need for the listview at all. New emails could simply be displayed on the desktop as mdi child forms. To prevent the user from closing the forms without replying (and without the listview, there would be no way of redisplaying the forms), I realised that the Cancel button should be removed!

I dropped the idea of 'recording phone messages' as these seemed to be identical to the 'instant messages', the equivalent of the secretary entering the office and announcing that the workers had gone home on strike. The 'instant messages' were virtually the same as the 'email messages' - the only difference (at the moment) being that the emails were 'sent' by somebody whereas the instant ones weren't. This meant that I could use one database table to store all the messages and display them in the same form (hiding the 'from' field if it were empty).

Upon getting home, I set about writing a new version of the demo exam. The database structure had simplified, so I deleted the original database file and defined a new one. This new version of the exam is - from a programming point of view - much simpler. Apart from a form which is displayed modally at the beginning of the exam in which the user enters her personal data, the program consists of one MDI main form with a timer; every minute, the program executes a query which determines whether there are any messages to be displayed. If so, a call is made to display an MDI child form as described earlier. There is only one button on the form - OK - which is initially disabled. If the user wishes not to act upon the form, it simply stays open on the desktop to be handled at a later stage. If the user types something into the form, pressing the OK button will save the data (along with the time stamp) and remove the form from the desktop - forever.

Now all I need to do is input the scenario  - the messages and when they appear - and the exam, at least in its initial stage, is complete. I am sure that there will be many changes, but most of them will be minor now that the architecture is in place. Of course, I could have misunderstood the OP's intentions.....