DIY: Developing Web Applications In-House

By Nicole C. Engard
ONLINE Magazine, vol. 30, no. 6, November/December 2006, p.35

When it’s time to either upgrade or replace an application in your library, you face several questions: Do you write up an RFP (request for proposal) and send it to area programming agencies? Or do you do it yourself with in-house talent? If you’re contracting with an agency, what are the chances you’ll find someone who is able to do 100 percent of what you asked for? Will the product end up exactly the way you expected? In my experience, the answers to these last two questions are “not likely” and “probably not.”

Many libraries find themselves hiring outside programmers to do individual projects because they don’t think they have a choice. This can lead to less than satisfactory results. Why aren’t libraries looking in-house for help with programming projects? Perhaps they don’t realize that training someone in-house or hiring someone new may actually be more affordable and produce results that are more satisfactory. This way, you will be sure to have applications built by someone who not only cares about your organization, but also knows the inner workings of your library.

Outside consultants may meet with the staff once or twice. After that, they will most likely work through a specific contact in the library. This makes the staff think twice before requesting they do something differently. Staff wonder if their request is really worth the time and money. This doubt leads to less-than-satisfactory results. In our library, people are constantly stopping by my desk to ask if something can be upgraded or done differently-no matter how small the request. The staff feels comfortable with our team because they see us every day, they have been working with us for years, and they know that we’re more than happy to help in any way we can.


Jenkins Law Library is a small (40-employee) membership library in Philadelphia. Prior to 2004, no one on the staff had the ability to develop database applications. As a solo Web manager, I was finding it hard to keep up with the day-to-day updates to the library Web sites and still find time to work on new projects. I reviewed our site and found several areas where a database would improve my work flow. Attending a 4-day workshop on PHP and MySQL provided by HOTT (Hands on Technology Transfer) helped enormously to focus my plans for the Jenkins Web site.

By attending the class with a specific goal in mind, I was able to take everything I learned and apply it to our situation. I also made sure to spend some one-on-one time with the teacher and learned a few tricks to help me make the necessary upgrades. After the 4 days, I had learned everything necessary to be able to start our first Web database application.


To be an effective programmer, I needed to learn about and understand how others went about their jobs. If you’re coming from a Web design background (as I was), it’s important to remember that your staff members are now your users. Designing for them is different than designing for your patrons. We all know that librarians can be more particular than the average Internet user, so as a developer you need to make sure to spend time with everyone who will be using the new application.

Meet with the relevant users and find out what their goals are. Take notes, ask questions, and observe the staff at work. Some processes may seem strange; questions such as, “Couldn’t you do it this way?” and, “Wouldn’t it be easier if you did this?” will get the users thinking about whether or not the way they’ve always done things is really the best way. In many cases, work flow has developed around available applications. If the staff had been given a choice from the beginning, they may have done things differently. These questions give you an idea of which processes are necessary to the task and which the user created as a work around. Your primary goal is to improve work flow and efficiency. Sometimes changing the way tasks are done isn’t the right path to take.

Share your notes, assumptions, and ideas with the staff. These types of projects will inevitably come back to you with clarifications and questions of their own. Continue this exchange until you feel you have a strong understanding of the goals and needs of your users. In our library, we use a project-specific blog to keep track of all communication; this makes it easier for me to review all of our notes as I develop the applications. Other options include software such as Microsoft Project or a wiki.


As a Web manager, my first project was to automate some of my daily Web updates. These types of projects are always the easiest because you’re designing for yourself-and who knows the way you like to work better than you? The drawback with this project was that I didn’t have anyone to bounce ideas off of. Programming (for me) is always easier with someone to talk through ideas with, so I looked for an online support system. Sometimes you need to test drive a few different sites by reviewing the quality of answers that are generally given. In the end, I chose to become a member of the Dev Shed Forums.

While these forums will let you discuss your plans with people with a similar training as yourself, keep in mind that your staff may not understand programming jargon. Some of them may have worked with databases before, but they may not understand the inner workings of the systems, such as queries and conditionals. Try to explain in the simplest terms to eliminate miscommunication down the road. You’ll find that this language barrier will become less of a problem after you’ve worked on several applications.

Once you have an idea of how to implement your new application, come up with a sample to show to your staff. I always start by drawing a map of how the data will flow. Try doing this on a whiteboard so that you can easily make changes to the diagram as new ideas are presented. You’ll use this map to help you stay on track when you finally sit down at the computer.

Using the flowchart, mock up a simple form to show the staff the order in which the data will have to be entered. Don’t spend too much time worrying about the design of the interface at this point because things may need to be changed completely depending on what the staff says. When you do the same thing every day, the process becomes second nature. It’s hard for some people to verbalize how they do their work, which means that your interpretation may have been wrong.

This ability to start over because of simple misunderstandings is another important reason to have a programmer in-house. If a contractor were to misunderstand, that’s money wasted-your in-house programmers can just go back to their desks and start over. All it cost you was time.

While some of the planning for database applications is similar to designing a Web site, most Web designers don’t have all of their users sitting a few feet away. Remember to keep your staff involved every step of the way. You can always call impromptu meetings; sometimes the best ideas come from just talking to a colleague in the hallway on your way to lunch.


After you’re sure that your demo will work for your staff, it’s time to add functionality. You want to create a working application that can be tested by the users. Once again, things don’t have to be perfect; you may find that what looked correct in the mock-up doesn’t actually work in practice.

Some people don’t like to share their work with others until it’s done to their satisfaction. This can backfire. If you don’t show your users what you’re working on until the end, you may find that they are extremely unhappy with the final product. I always make sure to show the staff what I’m working on. This doesn’t have to be done in a formal setting. I just stop people as they walk by my desk and say, “Do you want to see what I have so far?” This method has two bonuses: First, you get early feedback before you’ve done too much work. Second, another set of eyes will quickly see something you may have missed or forgotten about.

Remember to refer to your notes and correspondences regarding the project. With big projects, it’s hard to keep track of everything you’ve learned; that’s why you took the notes. You’ll also find that reviewing your notes while in this developing phase will give you new ideas about how to tackle seemingly difficult problems.


When your first draft is done and ready for testing, always make sure to find people in your library who are great at breaking things. Have them poke at your new system. I also try to have people who aren’t going to work with my application on a daily basis participate in the testing. Bringing in outsiders quickly reveals how easy your application is to learn. These testers will also bring new ideas to the table that the current users didn’t think of because they were too close to the project.

During the testing phase, make sure that you’re available for minor tweaks. If you’ve followed your notes and understood everything that was asked of you, you’ll find that most of the problems the user finds will be simple to fix. For me, it’s usually moving a field on a form from one end of the screen to the other or fixing a calculation that I didn’t write quite properly.

While it is necessary to provide some training, it’s better to see if the staff can follow the application without pointers. Try to observe the staff while they test the new application so that you can find the areas that need work. If they have no problems picking up the new process, then you understood what they told you and designed a system that hasn’t caused too much change in their work flow.


If your application is something that will be used on a daily basis, you may want to find a slow time in your library to release it. For us, that time is August. By releasing your new system when things are slower at the library, there will be less stress on the staff that has to use it.

You’ll also want to make sure that you’ll be available during the first few days after the release. This is not a good time to go on vacation. Although your application has been through thorough testing, problems surface once the actual work flow begins.


That doesn’t sound too hard, does it? With a little bit of training and a lot of hard work, you can develop custom applications right in your own library.

Once you’ve started programming for your library, you’ll find that there is no shortage of projects to be done. After finishing something for one department, another will come to you and ask for something to make their lives easier. You’ll also start to see areas in which a database application would make things easier for the staff and maybe even for you. As I mentioned earlier, I was able to take my programming knowledge and apply it to making tedious updates to the library Web site simple.

You just have to remember one very important thing in order to be a successful library programmer: Always keep the user in mind. Your staff knows what they want and it’s now your job to give it to them. Remember: Your library has given you this responsibility because they haven’t been pleased with the results they have seen from outside programmers. It’s now up to you to design the perfect system for your library.


Outside programmers:

  • Will only spend a minimal amount of time with your staff
  • Will probably have one or two contacts within your library throughout the project
  • May be working with more than one organization at a time
  • Will want to finish your project quickly so as to move on to another paying gig

In-house programmers:

  • Know the staff
  • Have a vested interest in staff happiness
  • Understand the inner workings of your library
  • Can easily upgrade your applications without an appointment-or an extra charge


One day, my deputy director came to me and said she’d like me to help with a statistics problem. She led me into a meeting room where the conference table was covered in blue and yellow sheets of paper. She then informed me that I was looking at 2 years of handwritten invoices from our document delivery department.

The problem: Our accounting person now had to go through these invoices and enter all of the information into spreadsheets so that she could generate some stats for our annual board meeting. The first thought that popped into my head was, “Why are these invoices handwritten?” Next was, “I can fix this!”

Our accountant explained to me that this would be the second time she had to type some of this information. The process went like this.

  1. Patron calls document delivery.
  2. Document delivery writes up the patrons request on a scrap of paper.
  3. Document delivery searches customer database for information regarding member status and possible discounts.
  4. Document delivery fills patrons order and handwrites an invoice.
  5. Document delivery sends out order and one copy of the invoice.
  6. The other copy of the invoice goes to the accounting department where the sales codes and dollar amounts are entered into the accounting database and then filed.

I met with our document delivery department and told them my idea: an automated, Web-based invoicing system that linked into our customer database. This would give us the statistics we would need in the future and would streamline the processes for the department. Our accounting people wouldn’t have to key in the values from the invoices once a month; I wanted to make the data easy to import into our accounting system.

Over the next 2 months, I studied the work flow in the department, learned how data needed to be transferred from document delivery to an accounting system, and researched the types of stats our board wanted to see. At this point, everyone was excited to see the product.

I spent the following 2 months developing and testing. We had to make sure that the staff could still do their work effectively with the new system. We also needed to make sure that the system was calculating prices and discounts properly. Most importantly (to the library) was that the right accounting codes and dollar amounts were going into our billing system.

During development and testing, we hit a few roadblocks. The first concern was that this new process would actually take longer than the old way. The fact that information was going to be automatically sent to the accounting database was a scary prospect and led to hundreds of test invoices before I could get a final OK.

After 4 months of meetings, planning, and designing, we released our new system. We had eliminated a lot of double and triple entry, we had accurate stats on all areas of document delivery, and we had presentable, typed PDF invoices.

If I didn’t have the knowledge to develop this application, it would have never been done. This kind of internal project usually sits on the back burner because libraries can’t afford to hire an outside programmer for $80 per hour to automate a process that appears to work just fine the way it was.

Leave a Reply

Your email address will not be published. Required fields are marked *