|P is for Practical|
(OT) Work flow in Web based applicationsby Ovid (Cardinal)
|on Nov 06, 2002 at 20:26 UTC||Need Help??|
Ovid has asked for the wisdom of the Perl Monks concerning the following question:
On my current project I am redesigning portions of an "administrative console" that allows users to update information that is displayed on the public portion of the Web site. Users log in, select the section they need to work on, select the single action that they want to perform, and then do it. The problem that I am facing is that this is not an "application", but instead is nothing more than a series of scripts that are barely more complicated than a simple form-to-email script. In order to allow the customers to use this product better, I need them to be able to follow a logical "work flow" of several steps.
For example, on this Web site, we have the concept of "products". Adding a product in the admin console is useless in and of itself. The product will not show up on the public side until contacts are assigned to the product. So, for this example, in order to make the admin console more user friendly, it should enable our customers to enter a product and assign a contact or multiple contacts to it. Currently, they add a product and then go back and add contacts. I want this to all be one nice, smooth, work flow.
Further, what if they are adding a product and assigning brand-new contacts? Currently, it works like this:
While it may not be clear from the above, the user must explicitly choose each section in the work flow rather than have the application walk the user through it (like a wizard). To make matters worse, if they want to add a product with only contacts that don't yet exist, they can't add the product. They have to add the contacts first and then add the product. That's miserable design (I should know, I "designed" it).
A Better User Experience
What I would like to do is create a work flow persistence mechanism that would understand the steps that the application user needs to take and walk them through those steps and be able to add new steps when necessary. For example, let's say that the user wants to add a new product. A simple work flow might be as follows (it's a rotten flowchart because I don't have the right symbols):
The Rotten Flowchart
+-----------------+ | Add new product | +-----------------+ | V +-----------------+ | Assign contact |<-. +-----------------+ | | | V | /-----------------\ | | More contacts? |--. yes \-----------------/ | V no: stop
I am trying to figure out the best way to model something like that. I want to create a work flow object that I can persist in the database that's tied to a user. My initial concept is to predefine work flows and walk through the steps. As each step is completed, move to the next step. That would be easy, but inflexible. In the example above, what happens if the contact to assign to a product doesn't exist? The user is still forced to create the contacts first because simply walking them through predefined steps doesn't allow for the unexpected.
A Better Solution?
If the contact doesn't exist, the workflow needs to take a detour to the "create contact" area and I think a stack based system would be more flexible. In our database, we have the concept of "people" and they are assigned roles, one of which is "contact". If I need to detour from assigning contacts to the "create contact" area, I push the "create contact" action onto the stack (which previously has "assign contact to product" on top). Then, I determine if I need to assign the contact role to a person or create a new person. Those involve pushing different actions onto a stack. Once done, I pop those items off the stack and proceed back to the top stack item. I think this is a more flexible approach, but I have never done anything quite like this before.
The Inevitable Cries for Help :)
Does anyone see any flaws with this plan, or do you have better ideas? Further, are there any Perl modules out there that already handle this for me? (I have no idea what to look for).
Incidentally, we don't use CGI::Application. I don't think it will handle something quite as complicated as this but I could be wrong. Also, we use Template Toolkit which CGI application does not support.