Making a data entry application look like a real website

Dulcian was tasked with creating a very complex data entry application (filling out the entire application for entrance into the military) that a senior in high school could use with no training whatsoever. The application needed to be attractive, easy to use, helpful, and engaging.

There are about 3000 different pieces of information required in order to apply for a position in the military. The data structure is complex.  In some places, there are multiple levels of master-detail relationships in the data.

We have been building pretty nice applications since the early days of client/server systems. Our applications are efficient, but utilitarian. We have always had a limited number of users that we could count on providing training for.  We never had to build a gigantic application that was only going to be accessed once by each user.

Since we had already built the same system for the recruiters, we thought that adapting it for direct use by applicants would not be very difficult. You cannot image how wrong we were.

We partnered with “TEN” (formerly AgencyNet), an award winning web design team for the creative side of the project.  They came up with excellent wire frames and some really beautiful user experience design screens.

When we started implementing the designs, we encountered issues that had not arisen during the creative design phase. There are two examples which illustrate how much fun this all was.

A) Consider a basic multi-record block (called ALIASES for our example). Any normal application, would show a grid with Edit and Delete buttons on each row, and an Add Object button at the bottom.  For this application, we did not want users to see a grid unless they needed to, so we started with the question: “Have you ever used an alias?” If the answer was “Yes”, then we let them tell us about the alias.  Once there is more than one record, then the grid becomes visibile but the user no longer sees the “Have you ever…?” question.  Then, where do you show the Edit panel? At the bottom or next to the grid row you are editing?  On and on, the questions piled up….

We had some internal design meetings and made decisions that, when implemented, looked silly. We eventually drew a full process flow with 7 states just to model all of the screen permutations and behavior:

1. Show question only “Do you have an alias?”
2. Show question “Do you have alias?” with Y selected and a blank row of data.
3. Show question only with N selected.
4. Show grid with no question.
5. Show grid with selected row expanded, no question.
6. Show grid with blank row at bottom with “Fill out fields below” on grid row.
7. Any other screen

etc.

This is probably not complete, but it gives you an idea of the exercise required prior to coding the grid.

B) A single text entry field needed about a page of code to implement.  It included the field, a label, help text, potential error text, and various image icons that were used to show whether the field were locked, had an error, etc.

When we finished, the bad news was that the entire application needed to be rewritten.  The good news was that there were only a few different kinds of data elements.  Therefore, we were able to create a repository to store all of the field information and then write a code generator to build the entire system.  The REALLY good news is that now we have a machine that can build very pretty, very complex data entry applications just by populating a simple repository and hitting the Generate button.