InfoPath Dev

After reading numerous books, including "Developing Solutions with Microsoft Infopath", "Programming Microsoft Infopath DevGuide (2nd edition)" and "Microsoft Office Infopath 2003: Kick Start", I still have a lot of questions regarding best practices and design patterns in general.

One specific area is the usage of 'views'.

I'm in the progress of planning a solution. About 50 paper forms are being converted to Infopath (2003). Most of these paper forms are 'connected'. For example, for a few topics there is a form that starts it and a form thats stop it (for example, using our company fitness facilities).

Now, under what circumstances should I combine those two paper forms into one Infopath form? And if I combine those two, should I use two 'views' or should I use a "choice group" with two sections? I'd like to add some basic 'approve'/'reject' feature for the management. To combine this, I can think of several options:

1. One Infopath form per paper form. View 1 for the end-user, view 2 for the manager for "approve/reject".
   
2. One Infopath form per paper form. One view. Per-default hidden "manager" controls for "approve/reject".
3. One Infopath form for both forms. Two views. View 1 for "apply/start". View 2 for "discontinue/stop". Per view (per-default hidden) "manager" controls.
4. One Infopath form for both forms. Two views. View 1 with a 'choice group' with two sections: section 1 for "apply/start", section 2 for "discontinue/stop".  View 2 for the manager.
   

What questions should I ask myself to guide the conversion? I'd like to keep things simple...

Could someone recommend a good read about Infopath design patterns and best practices, apart from those mentioned above?

Tnx, Marc. 

Great Questions Marc.

 You will reap a lot of benefits doing the research up front and planning this out rather than diving in directly.

There is some preference and flexibility in what you have laid out but I will give you my take on this.

What I look at is the data source. If a form uses the same base data, than it should probably all be one form with multiple views.

As much as possible reduce complexity by having fewer forms, for the user and for the admin.

As far as view vs. hidden sections. This mostly comes down to development time and possibly performance.  And I think you have to look at each scenario.

If the manager would look at the data in the same layout as the user, but then have an additional section, use one view with an added section.

If they want to see it in a summary view or some other way than have a second view.

Beyond that, I would recommend a couple other tools for your solution.

To link multiple forms together you need a central data source such as SQL. This gives you the ability to have supplemental forms and pull data from a central database or other forms into new forms. A scenario is often the content is somewhat dynamic. This will allow say questions to be managed in one form and then utilized in a second form so that the form is not hardcoded and needs no IT involvment to update or change.

You also will need a way to identify users and get their email, and manager details. I would recommend the Active Directory Web Service from Qdabra.

I would check out the Database Accelerator Architecture from www.qdabra.com.  Especially with IP 2003, it can give a very powerful tool set and allow you to do the most with InfoPath right from the beginning.  If I was going to get started on what you are describing that would be the most critical piece.

Hope that helps.

Clay,

Thank you so much for your reply. Those guidelines you presented really makes sense to me.

There are a lot of other aspects of Infopath for which I'm looking for best practices and/or design patterns. Apart from the fact that I could not find a specific forum for that on this site (feature request for the site I guess? :-) ), maybe, as a MVP, you can help me with those as well? ;-)

For example, do you know of any practices/patterns regarding implementing Infopath development using a Design/Develop/Deploy model? I'd like to separate the visual design of the templates from the code-behind stuff. It seems logical to me that our branch departments themselves will design the templates, possibly without IT help. Consequently, JScript/VBScript would not be something our branch departments should cope with.

However, I know for a fact that every form will contain some code-behind, although it seems to me that you should keep it as small as possible. So, I was thinking about a model where the IT department would come up with a form template template, containing all needed generic code-behind JScript. This would be a baseline for the branch departments to start with. When the branches have finished designing their needed form template(s), the template gets 'connected' with the code-behind. That might be done by the developer/deployer, glueing the visual form together with the (already present) code, and who will also digitally sign the template for full trust and actually deploy it.

So, the goal here is, to create a situation in which (educated) branches are able to create there own form templates without the IT department.  

Is this doable or, even better, common practice? It might require some sort of 'contract' between the 'design' part and the 'develop' part, like, you know, MVC, model-view-controller, as a design pattern.

Or... am I just babbling here...

(Dear moderator: sorry for getting slightly off-topic here.)

Marc.