Letting non-technical clients design forms and workflows

[Elaine_Schmitz]

Some individuals in my organization are under the impression that our clients, who are very non-technical, will be able to design forms / workflows, etc.



The impression is that the developers are to create a set of standard schemas, fragment libraries, and workflows, and then the (non-technical) client can build their own forms, select a predefined Task Manager endpoint, and hit the ground running with their new form, in production. Yes you heard me correctly. In production. That means no DEV, no QA, no passing Go.



In other words, they are putting LiveCycle on the same playing field as Vignette (Content management in production).



I disagree with their approach and am seeking feedback. Thanks! ;-)

[Former Community Member]

There was a similar thought process here, although just with Forms. It also was not business customer, but just less technical people. The biggest issue was the thought that it could be anyone at any time. Basically the misconception is that there is no learning curve.



At a recent user conference in Chicago, one group there was non-technical and creating forms. Their Forms were for printing only. They did not have script in them. Even so, the group of people creating the Forms were dedicated. It was not the case where anyone who needed a form created one from scratch. Specific people with experience did.

[neptas]

Hi,



Same situation here. In my opinion, to change/create forms should be trivial. Where the forms will be kept? In the content repository or in workbench repository? In what concerns to processes, I dont think a good idea to change them directly in a production environment.

[Former Community Member]

If the form is bound to a schema, at least when they move form elements around, most of the time it will still work. If normal binding, moving stuff around will screw up the data merge.



The biggest problem I see with the changes being made directly in production is that I save my forms to the repository in order to test. The preview tab quite often does not represent true functionality. So if they had Workbench pointing right at prod, the form cannot be tested without releasing it.



I don't know what you mean between content repository and Workbench repository. The way my implementation works, if I save in Workbench, I can immediately reload the page to get the changes. They are the same repository. I am using the API call (off the top of my head) renderFormWithUSageRights. I specify a repository URL for the template location. All my forms render through the same servlet parsing the form name out of the request URL. There is an XDP in the repository with the same name as each pdf URL. There is also a corresponding JSP which renders the XML that is merged in at render.



I saw a reference somewhere that the repository URL could contain a version at the end. I have not tried this. If true, it would not be difficult for me to update my code to get the version number out of my properties database table. Then also allow an override version number in the URL for the final form. So http://mycompany.com/myform.pdf renders the 'released' version and http://mycompany.com/myform.pdf?version=2.7 returns that specific version. http://mycompany.com/myform.pdf?version=latest would work like it does now where no version number is specific in the repository URL. This would mean they could save the form, access in production to test, but not affect normal users. Once tested, the database could be updated to reflect the new released version. It would be really slick to have a workflow approval process around it. The workflow would have a link to the new version for each approver to review. After the last person signs, the workflow would update the database to the new version. The next time it is rendered will be the latest version.



Thinking about this, I like that idea even if a developer makes the changes. There are times when customers won't sign off on their own requested changes because they won't make the effort to test it before it goes into production. They would rather let the changes go in then report anything they don't like as a bug. They feel if they don't sign, then they cannot be held accountable. Sometimes the same people or others will get angry if an item is not put into production based on not getting sign off. Now, the deployment would be tied directly to the sign off procedure rather than manually by someone in IT. All approvers would be able to look at the audit trail to see who has not signed off and therefore the direct cause of an item not being released.

[_Antoine_de_Ker]

Elaine

You can probably satisfy your clients by letting them design the forms and since you're in charge of operating the forms (I assume), you can impose that you will check the forms, the scripts and run your QA processes before moving the forms online.

This approach would give a positive answer to your "non-technical" clients and yet allow you to maintain the level of quality that you need to maintain.

I would suggest creating a test environment (or just a category with restricted access) for those "pseudo" form developpers and letting them play with the tool. Once they've played once or twice but the GUI, they will understand that there's indeed a learning curve and that they're much better off letting trained people do the work.