What is a "User Changeable Application"? Why would a person want one and why would a developer make one?
Simple basics questions but with profound effects on the user and the environment. The answers to these questions in themselves are quite basic as well. The problem occurs once the application is set into motion.
Before I get ahead of myself let´s go back and look at each question individually. So onto the first question. "What is a user changeable application?"; in short this is a program that has it´s displays and functions controlled by the users who use the application. OK, before you ask is it smart to leave this in the hands of a user, let´s move on to the next two questions. "Why would a person want one?"; this is also answered very simply. A user wants one because they don´t have the time or money to keep a developer busy with this one application. Perhaps they need the developer to create several applications and their budget only allows them a short period for each application. All in all, everything sounds logical so far, right? Our third question, "Why would a developer make one?", quite simply put, he has no choice, he is hired to do an application and therefore he has to make it. As a developer we all hate to work like that because we feel as though our experience is being pushed aside for the sake of a few dollars.
Ok, now we have the basis for problem. Yes this becomes a problem and not a solution very quickly, if the developer is not careful. The most obvious problem is a conflict of interest and the developer is let go. The not so obvious problem however, is still the biggest. Let me now lay the ground-work for the application.
Task: Database application with email notification
Timeline: 2 weeks
Requirments:
Web interface
Database creation
Database entry
Email notification of new entry
Database viewing
Database Report viewing
Goal: Single application for multiple reports with multiple masks
So as you can see, the developer now has a difficult task. How to provide a simple application in two weeks and still make it expandable for multiple different masks. The developer is given instructions that the masks will be created by the users and maintained by them, their task is only the backend system.
As a developer I know that is hard to take, some of us like to see quality work when our name is attached to it. In this case though there is no choice but to tackle the problem full steam ahead. So what points to do first? What plans do we have to make in order to give the customer exactly what he wants?
Task 1: Database selection, perhaps the customer has a standard perhaps not
Task 2: Programming environment (let´s assume Java for the sake of arguement)
Task 3: What masks are neccessary
Task 1
We have chosen our database, MySQL, it´s free and easy to setup and configure. Luckily the customer has provided support for the setup of the applications and databases. Since you have also chosen a out of the box database solution there are plenty of Report writers available for viewing the data and exporting it to different tools.
Task 2
You have already defined this to be Java.
Task 3
We lay out the masks as follows:
Input
Email acknowledgement
View
Edit
Now how to handle the "generic" side of the application? The easiest way would be to have multiple "hidden" form fields within the HTML masks that control the way the database is accessed and which fields are used, etc.
It is the "generic" side of this application in which lies the problem. You have just now setup and created a completely user driven application. The user can create a new set of HTML masks with a different look and feel and different databases. So at this point you are probably confused about this problem I keep mentioning.
The Problem
I´ll break it down for you. You have several sets of HTML masks all doing something completely independently of each other. You have perhaps 10 user groups now using this system in their daily business and are now depending on it. You have 2 user groups step forward 2 months later and now want changes to the backend for more features. You have 1 user group that has 90 sets of masks and now want to have them interact! As the developer who originally created the application and provided the company with "such power" you are now responsible for getting things back under control.
Now granted, how many of you have come across this problem? I for one have, and therefore I have decided to share my problem and the finding of a solution with all of you in hopes that maybe one of you will benefit from it.
The Solution
The first thing to consider when building a "User Changeable Application" is what technology to use. You have to make the solution changeable and comfortable for your user but the key is to make it "hard" to change. Ok, now I am not saying that you have make it impossible, only that it should not be so easy that the user can run away with it. By making it only HTML based you take the chance that the user will have enough knowledge to let the system get out of hand. I would recommend adding XML files to the mix. Make all of your configuration and settings in XML files. Do not make such a complicated structure with your XML that the user is unable to work with it, but do make one that the user will have to consider their actions before moving forward. The idea is to make the user realize that they have a lot of power at their fingertips and that power has to be used in an appropriate way.
One way to use your XML files is create an accompanying TAG library for using the data. Or if you are not too familiar with TAG libraries I would recommend creating a "replacer" method which will replace a defined tag (i.e. $$dbfield$$) with actual data or text upon loading the page. Now when the user wants to make a new set of forms to go with the application they have to really consider their activities. In short, it is now very easy to work with the data but the user will have more set-up and install time. I also recommend a configuration file the user has to add the new files to, something that requires a restart of the JSP engine in order to take effect. This will eliminate those random creations of the user because they think something might be useful but have no real reason for it. With a restart, the user has to then seriously consider his or her actions before stopping their now running system for a few minutes.
System Task Plain HTML files & XML Configuration files
Effect to User Harder to use
Effect to Developer More effort for Developer
Effect to System Integrity More chance that the system will remain stable and in control
—
System Task Tag libraries
Effect to User Easier to use and implement
Effect to Developer More effort for Developer
Effect to System Integrity More versitle system
—
System Task "replacer" method
Effect to User Easier to use and implement
Effect to Developer More effort for Developer
Effect to System Integrity More versitle system
—
System Task Configuration requiring restart of JSP engine
Effect to User More difficult to update system with new elements
Effect to Developer No real effect on developer beyond the inital routines needed to add this feature
Effect to System Integrity More structured system
By setting some or all of these safeguards in place it would then be possible for a developer to create a "User Changeable" application with less fear of it turning into a monster. Unfortunately, the only sure way for maintaining such a system is to simply not make one. However, as we all know what the customer wants is what the customer gets.
© Copyright 2003, Craig S. Cmehil
