How I Learned Human-Computer Interaction at a Law Library

Posted 2015-04-03 08:31 PM GMT


My first programming job was working in the systems department of the BYU Law Library. I worked on a wide variety of projects, including installing Firefox on law professors' computers and writing Perl scripts to process huge and disgustingly poorly formatted Oracle reports. But my favorite projects by far were building web applications for law students and library employees to use. This story is about one of those web applications.

Every semester the library circulation manager has to create a work schedule for all of the circulation employees. There are 2 desks that must be manned from 6:00 AM to 12:00 AM, books must be reshelved at regular intervals, and various other roles must be filled. Undergraduate students fill all of these positions, and students can't work while they have class. No student can close one night then open the next morning. More tenured student employees get more desirable shifts. If a student wants to work 12 hours per week, that student should not be scheduled for more than 14 hours, nor less than 10 hours. Shifts are diced up in 30 minute increments, with the minimum length of 2 hours and maximum length of 4 hours. I could keep going, but I think the point is quite clear: this was a system with numerous conflicting constraints. The process of creating the work schedule would generally take the circulation manager about 2 months (i.e. half of a semester).

The Challenge

I was a new, overly confident programmer, certain that the computer could solve any problem. I saw the two month process of papers, spreadsheets, frustration, and tears, and I knew there was a better way. During the spring of 2009, I took on the challenge. In less than 2 months, with the assistance of Object Oriented PHP, I created a web application that would create and display a fully compliant schedule. Bursting with pride, I ran from my windowless room down the 2 flights of stairs to the circulation manager's office. The 2 month process was about to become a 15 second process (again, I was a new programmer, and I had never studied algorithms; all things considered I think 15 seconds was pretty good). I was jubilant as I watched her click the "Build the Schedule" button. The computers had won!


Then my jubilee ended. She spent less than 10 seconds looking at the schedule my program had made, then she said, pointing at the screen, "These two can't work together. They wouldn't get anything done." My face fell, but I was not defeated. My mind quickly scanned the possibility of adding employee compatibility to my model when I heard, "Oh, Anne is probably too shy to work the front desk. Unless Jess or Brandon is doing shelving at the same time..." Now I knew that I was beat (but still not defeated). In theory I could make an employee model detailed and accurate enough to handle these new constraints, but I knew these two new constraints were just the beginning and not the end. My program worked in a cold, mechanical sense, but it lacked a human touch.

The Lesson

I returned to my desk with a completely different view of the role that computers should play in our lives. In the five minute interaction I had with the circulation manager, I learned two important lessons:

  1. Computers work best when they are used to assist us (humans) in the tasks we are trying to perform. Calculations, data transfer, and even data analysis are perfect jobs for computers, but human decisions should be left to humans. A computer may sift through the many applicants for a job to surface the most qualified candidates, but a hiring manager would be loath to relinquish the interviewing and final hiring decision to the computer.
  2. Humans enjoy doing work. People want the satisfaction of doing work more than they want the free time available by having computers do the work for them. Even if a computer can do a job as well as (or better than) a human, there are certain tasks that humans don't want to give up because the work is so satisfying.

I reused the Object Oriented code I had written for the fully automated schedule builder to create a schedule building interface that the circulation manager could use to add a human touch to the process. As far as I know, the rewritten program is still being used today.