Task Orientation vs. Software Orientation
I used to teach an introductory Microsoft Access course at a technical college. I used a very common Products/Customers/Sales model as the assignment for the semester. I had already taught the students introductory database design. Now it was time to try to create a working sample application from the ground up. The students dutifully created the tables, keys and relationships. They were anxious to leave the world of Dr. Codd behind and move on to the exciting business of creating a user interface with colours and images and things that reacted when you clicked on them. Most of them smugly ran the Form Wizard against each of the tables they had created and handed in their first assignment deliverable thinking that making money as a developer was going to be child's play.
When we reviewed the students' handiwork in class, reality started to set in. Admittedly, the standard Create, Retrieve, Update and Delete operations could have been accomplished using the simple interface they had created, but things started to fall apart when we worked through some simple scenarios.
"How Do I Do My Job?"
I had the students consider the plight of the receiver at the distribution centre when faced with using their applications. The receiver's main task is to receive shipments of products accurately and record their availability so that other employees can find them in the database and create Sale or Order records in which customers agree to purchase those products. In our simple database, the Product table included columns or fields like "ProductID", "Description", "QtyOnHand" and "QtyOnOrder". To receive a shipment of a particular product, the receiver had to do the following:
- find the record for the product using the ProductID from the copy of the purchase order
- increase the value in the QtyOnHand field by the number of that product received
- decrease the value in the QtyOnOrder filed by the same amount
How could this be done using our simple Products form? Once we had navigated to the desired record using a Filter or Search we had to enter the current value in the QtyOnHand field into a calculator and add the quantity received before entering the new value, then calculate the new QtyOnOrder using a similar technique before moving to the next record to save our changes. Even the students who at first helpfully suggested popping up the Calculator program on the screen eventually realized that this was not user-friendly. When a user working on a powerful PC must use a calculator in order to complete an operation in your application, something is seriously wrong with your design!
Start With The Task
Lacking experience with application design and the needs of end users, the students had made a typical rookie mistake. They had carefully designed a back-end database to efficiently and securely store data. Then they had created a front-end that was simply a graphical add-on that mirrored the back-end. The data in the tables may have been accessible, but not in any usable way.
As an introduction to the programming tools available for Microsoft Access, we set about creating an interface that mirrored the tasks users needed help with, rather than the design of the database itself. We started with a blank form and named it after the task it was to accomplish -- Receiving. We worked through the steps in this task.
Assuming that the products to be received had been verified by way of a purchase order number and that the quantity was correct, the first step was to enter or find the ProductID number. We placed an unbound text box named ProductID on the blank form with an appropriate label next to it.
Assuming the ProductID was valid (more on this shortly), the next task was to enter the quantity received. We added an unbound text box named QtyReceived to the form with an appropriate label beside it.
Finally, the updates had to be made to the database. For this simple example, we added a button with a caption like "Process" or "Receive Product" to the form. Clicking this button would call some code in a module that would find the record for the product and update the "QtyOnHand" and "QtyOnOrder" fields.
Make The Task Easier
Once the steps in the task were established, the students worked on simplifying each step. For example, rather than a simple text box control in which the ProductID was entered, what about a look-ahead combo box that found the number as the user typed or displayed a drop down list of sorted numbers with a description alongside? Considerations would include how many numbers the user might be forced to scroll through and how to handle numbers that were not found.
Could the layout of the controls on the screen be fine-tuned to make the steps easier to follow. For example, should the controls be arranged in a top to bottom or left to right order that suggested the sequence in which they should be used? This may seem like a no-brainer until you consider cultural differences. A number of written languages read from right to left, so the left to right English language model may not be as obvious to your users as it may seem to you.
Are labels easily read in the environment where the application will be used? Remember that not all computers reside on desktops with ideal lighting. Are fonts used of a size and style available on the target machine or are they simply the personal favourites of the developer?
Is a simple list of instructions displayed on the screen so that going somewhere else, such as Help for answers is less necessary? If the task is part of an entry-level position's responsibilities, new and inexperienced users may need constant reassurance.
Make The Task Error-Proof
At each of the steps in the task, I made the students go through the exercise of stopping and asking: "What could go wrong?"
What if the ProductID could not be found? A simple typographical error might prevent the receiver from finding the product. Is it possible to find a product by description? Is an image of each product available for comparison with a physical example?
What if the user makes a typing error in the quantity text box? Could code be written to check for a numeric entry and warn the user, or, better yet, should a custom control be designed that allowed only positive integer entries? What if the quantity received does not match the quantity on the purchase order?
What happens if the user clicks on the "Receive Product" button before entering all the required information? Should the button be disabled until all the information is in place?
What happens if the user clicks on the "Receive Product" button more than once, either accidentally or because they are not sure if processing has taken place? Should the button be disabled after the first click? Perhaps a message should be displayed telling the user that their task has been completed. Perhaps the table needs a time stamp field indicating the time and date that the record was last updated and by whom to reassure the user that their task completed successfully.
What if an error occurs during processing? Should the update be handled as a transaction so that it can be rolled back if necessary?
The Bigger Picture
After this bout of micro-thinking, the students were asked to take a step or two back and see where this simple screen they were designing fit in with the other tasks users needed to perform. Would it be easier for the receiver to fill out a list of products received and quantities that matched a particular purchase order or shipment and then process them all as a batch? Were the individual parts of the receiving process separate enough that the application could scale up to a larger database or scale down onto a hand held device in the future? How much would have to be rewritten if the application had to run in a browser instead of Microsoft Access?
At the school where I worked, Microsoft Access was part of the curriculum at the time. I saw my job when teaching the course not as helping the students learn how to create Access applications, but rather helping the students learn how to use Access to create applications. There is a subtle but important difference. The first approach centres on using the wizards to get something working quickly and then expecting the users to adapt to the new application by "learning Access." This approach centres around the software. The second approach makes Access just one more tool in the arsenal of skills the students would leave with and produced applications in which, rather than users learning the application, the developers -- in this case the students -- learned the tasks the users had to accomplish and built an application around those tasks.
(I originally wrote this article for TechRepublic. It appeared on their site way back in 2006)