Java: Hotline

From time to time in the call center at work we track the types of incoming calls to determine what new information we need to be providing on our website and marketing material. In the past we've used sheets of paper and placed tick marks under headings to record this information. Then the marks are tallied up at the end of the month for reporting purposes. Obviously a very manual and time intensive process, but since it is done only one month at a time not a massive issue. However now we want to track a bit more consistently so a better process is needed.

And so Hotline was born. It is designed to be very user friendly and also extremely quick to utilize, as the call representatives don't have a lot of time to be entering any notes into the system in between calls. So this is a very high level tracking system to get a general feel for what types of calls are inbound. There are two parts to the system; the call tracking side and the reporting side. The call tracking side is simply a series of buttons, one for each possible call type. When a button is pressed a pop-up message appears confirming this fact, acting as a deterrent to any accidental double-clicking as only one option should be selected per call. This will then update a text file saved on the server named according to the value in the Representative JComboBox.

The reporting side of the system was a bit more difficult to setup. The information is saved in text files as strings, so updating the information due to an incoming call relies heavily on converting part of these strings to an integer, increasing the number then converting it back to a string to insert back into the text file. For a report run on a particular representative the process is straightforward. The month selected in the JComboBoxes is located and the particular representative's file in this location is opened and its text dumped into the JTextArea.

A report run containing information for all of the representatives is a bit more involved. Each representative's file is opened individually and the values for the number of calls taken are saved into an array of strings. This string array is then converted to an integer array. The process is then repeated for each representative's file and the new call value added to the current one in the integer array. Eventually all of the information is compiled. Then the array of integers is converted back into an array of strings and these strings appended together to create the output report in the JTextArea.

Originally I was going to make the reporting call a JMenuItem instead of its own JTabbedPane, however that was becoming a bit too cumbersome. Any changes needed in the future would be more difficult with all of the reporting code in the same java file as the button panel code. So they were split apart into separate JTabbedPanes for my peace of mind. Also, some of the values are hard coded into the program, specifically the representative's names and the month/year values. Any changes that are made would require the entire program to be compiled again and a replacement executable generated. Eventually I may make these values editable by anyone, but for now the program is ready to be pushed out to the call center.

Java: CME Log Date Decoder

At work we recently, as in the past two years, updated our CD-ROM application from being a 16-bit Toolbook program to purely Java based. Along with this massive change many features were updated and revised. One such feature is the CME (Continuing Medical Education) credit tracking system. Before the update, CME was tracked in a text file on the hard drive by date. Each article viewed in the program would have it's own line in this text file and a Gregorian date would be prominently displayed for that article.

Now with the upgrade to Java things have changed. No longer is a date available to the naked eye when reviewing the logs. While each article still does have a date attached, this date is in milliseconds. And to make things slightly more complicated these are milliseconds since January 1st, 1970. Why that date was chosen I do not know.

So for our Customer Service department this poses a bit of a dilemma. They are charged with receiving these CME logs in paper format and having to determine what date to assign the CME credit. Only recently has this problem come to light, and to combat it I created a small program to automatically calculate the Gregorian date from the given millisecond variable.

The CME Log Date Decoder program is a modified version of the Password of the Day program. It will take as input the time in milliseconds, which will be a string variable as far as the program is concerned. This variable first needs to be saved into an array of strings, one bucket for each character, then converted into an array of integers. As integers each array bucket is put through an algorithm and then summed together and added to a Calendar date of 1/1/1970 in order to obtain the correct CME log date in Gregorian format. This is then displayed to the user. The program requires almost zero memory so the calculations take less than a second to perform.