Barriers to Client Centric Design

As we could see in the last post, there are real advantages to using client centric design, as its priority is understanding and supporting a business process as opposed to focussing on technical requirements.

So why isn’t this approach adopted by all solution providers? Why do we still see technology centric design, and the resulting systems, being used in production level SharePoint Installations?

Let’s look at the barriers, their validity, and how to challenge them.

Barriers to Client Centric Design – Technical Expertise

This is a completely valid reason for not being able to create a system using client centric design. A strong technical team enables good design.

Barriers to Client Centric Design – Design Expertise

Without a good design team, you won’t see the benefits good design can provide.

Barriers to Client Centric Design – Undervaluing Design

If you have two systems side by side, both are technically robust and meet all requirements, one has client focussed design, and one based design decisions on mostly technical considerations, which one do you think the client is going to choose?

Good Client Centric Design. Every time.

Barrier’s to Client Centric Design – Cost

A SharePoint solution designed and developed using client centric design is definitely not the cheapest option. Except in the case of systems that use the built in pre-configured front end tools, such as team sites or the issue tracking list, custom solution support development in SharePoint is not going to be the cheapest option.

The first question therefore for someone who is focussed on cost is “Why are you using SharePoint?” If cost is the sole and highest priority factor, then any system with intermediate or higher complexity could probably be developed cheaper using a focussed platform isolated solution approach, such as .net or java development. SharePoint strength is in its ability to provide a wide variety of tools and supporting information to encapsulate much more of a business process.

SharePoint isn’t the cheapest application development platform, particularly once systems become intermediate or higher complexity. It is the best choice however due to the variety of tools and degree of support it can give a business process, it is the best choice because it can best support the majority of the business process, not provide the cheapest support of core components of that same business process.

But, in the long run, SharePoint can also save money.

And that leads to the second point. Even though initial development of more complex systems in SharePoint using the client centric approach costs more, the efficiencies the resulting system give savings over time.

Let’s take a more detailed look at that argument using the vacation request system. The following table shows all of the activities associated with a vacation request system covered in the last post, who is responsible for them, and how much time they take. The technological centric approach and the resulting time effort are contrasted with the client centric approach and end user effort. The first table covers the technology centric system:
 


We can see from that table that completing all tasks associated with the average vacation request takes 55 minutes, 20 minutes for the requestor, 15 for the manager, and 20 for human resources. Now let’s look at the same table, but this time for the client centric system:



As we can see, having all of the information necessary to process the vacation request residing in SharePoint increases efficiency considerably, moving from a total processing time of 55 minutes to a total processing time of 30 minutes.

If you have a company with 400 employees, you could expect an average of 800 vacation requests per year. In this environment, you are saving 25 minutes for each and every vacation request. For a total of over 2 months of savings in one year!

Properly designing SharePoint Solutions results in real and measurable improvement in efficiency. Because, long term, a system developed using a client centric model ends up costing less as less time is used to support the business process.

The cost barrier to client centric design can therefore be challenged by:

1. Finding out what the goals for the development of a SharePoint system are. If cost is the top priority, except in the case of simple systems, then perhaps SharePoint isn’t the best choice. If the ability to effectively support the majority of a business process with a diverse range of interconnected tools is more important, if the effectiveness of the system is more important than the cost, then SharePoint definitely is.

2. Proving that the amount of time necessary to complete the same business process using a client centric approach will be less. Demonstrating that the solutions provided using this focus will result in long term savings to the users of the system.

In the end, a carefully considered and designed system, using the client centric focus, results in a system with higher client satisfaction because it more effectively supports the process than one designed with a more technical focus.

Client VS Technology Centric System Design

Introduction - How We Got Here

When the first business systems were developed using computing technologies, the interfaces to those systems were very literal and direct interpretations of the underlying technology. Punch cards placed into a machine contained punches that represented the core of all computing technology, a bit, indicating a binary value. The way the user interfaced with the machine, and how the machine interpreted that information was very close. Punch cards were a literal interpretation of bit based computing.

Then we developed various software based layers that hide that complexity, so that the information the developers entered at that time was first interpreted or converted into language the machine could understand before being used. “Machine” language such as MASM with commands such as “push” and “pull” still closely reflected the way the underlying technologies functioned, moving bits, other programming languages were developed that were further abstracted from the machine layer.

Then in the late 70’s to 80’s along came various flavours BASIC, a language that was "so easy to program" that some programmers feared that development was so easy they would be out of work. The technical nature of programming meant that never happened of course, but even BASIC only provided a very basic interface and limited design options. The interface design was based on what was possible rather than best choice, and just getting software to function and meet requirements was the major challenge.

This is now not the case. We have a wide variety of ways of presenting the same information to our end users, a great deal of flexibility in how we decide to support business processes, a wide variety of “development platforms” that remove most of the repetitive work involved in developing systems and allow you to focus on core logic and interface and system development. No longer are we limited by command line interfaces and restrictive toolsets, our freedom to design systems today means we can focus on how the user interacts with the system, as they move through a business process, and let this guide us in our toolset choices.

This means that there are a great variety of ways to achieve the same objectives, a large number of ways to support the same business processes, we are at the point where we assume the vast majority of the underlying technology is going to work, we spend more time assessing different technologies and approaches to see which one is the best fit for the current solution.

SharePoint 2010 represents an approach that has been tried before, a singular portal with a comprehensive set of tools supporting multiple business processes. Platforms such as Plumtree were portals that added an additional layer of functionality over isolated system development, allowing you to share identity and interface with multiple systems in a singular web portal. SharePoint 2010, in my opinion, is the first platform however that provides sufficient diversity in toolset and approach to truly support a wide variety of custom business processes. No longer are we simply replacing older systems with newer technology, through our architectural and toolset choices, we are actually increasing efficiency in the workplace and reducing the amount of time dedicated to each supported process. Measurable improvements in efficiency.

This has led to two focusses in systems development, one focusses on the technical components of the solution, the other focusses on the client side. The technical analysis of the system answers the questions “How are we going to make this work? What tools do we need and how are we going to configure them?” The client side of the system asks the question “How is the client going to most effectively be supported by the system? How can we improve the business process as a whole?”

The best way to understand the value of these two approaches is to look at the systems that result from a focus on each area.

We will take a look at a hypothetical internal Vacation Request System used by a company to support the employee vacation approval process. Fundamentally, the system requirements are:

1. Employee can fill out and submit form.
2. Manager can approve or deny request.
3. Human resources can approve or deny request.

We will first take a look at the system that results from a solely technological approach, and how each of the three user groups mentioned above interacts with the system. We will then contrast that with a system that uses the client centric approach, the tools available to the user, and how they interact with the system.

We will then look at a hybrid system that combines both approaches.

Technology Centric Design

The first SharePoint Vacation Request system that we are going to look at is one whose focus is on the technical solution. As soon as requirements are gathered, the tools needed to support the core system, a vacation request form, and their customization becomes the focus.

We will look at the way this system works by seeing how these three user types interact with the system:

1. Requestor
2. Manager
3. Human Resources

Requestor Actions

1. The requestor logs onto SharePoint, and locates the centralized Human Resources Forms Page:



2. The requestor clicks on the “Vacation Request” link. The vacation request InfoPath form opens up, the requestor fills the form out and clicks “submit”. A workflow notifies their manager that a request has been submitted. If the requestor has any questions about policy or upcoming projects that may affect availability, they email the appropriate person to get an answer.

Manager Actions

1. The manager receives an email notification from a workflow that the Vacation request form has been submitted. The manager clicks the link in the email to open the form.

2. The manager reviews the form information, cross references it with upcoming project plans and schedules, and can approve or deny the request. If the request is denied, the original requestor is informed. If the request is approved, a workflow sends an email to the HR group informing them of a manager approved vacation request.

Human Resources Actions

1. The Human Resources Department receives an email informing them that a manager approved Vacation Request has arrived.

2. The Human Resources person responsible for the Vacation Request assigns themselves the request.

3. That person then cross references the time tracking and payroll systems to confirm the requestor has vacation time available, and then approves or denies the request. A workflow informs both the manager and requestor of the final status.

4. If the request is approved, HR updates the time tracking and payroll systems to accurately reflect entitlement balance after approval.

Summary

What’s wrong with this system? Absolutely nothing. It meets the core requirements defined by the client, and it successfully supports the vacation request process.

The only question I would have for someone who approaches SharePoint development this way is “Why are you using SharePoint?” There are lots of development platforms, .net, Java, open source that allow you to develop isolated form based systems such as this. Why choose SharePoint?

You may point out that in SharePoint, you can experience rapid development since the security and so many other components are already flushed out. This is definitely true for simple systems, but, as anyone with real world experience in developing InfoPath based systems knows, as soon as you get to intermediate or higher complexity systems that require customization and complex workflows, you lose that time savings.

So for medium to high complexity systems, there is no development speed advantage over using isolated development approaches for form management. So what advantage can SharePoint provide? Let’s take a look at a system developed using client centric design to find out.

Client Centric Design

The client centric system differs from the technology centric system as the focus is different. Client centric systems focus on how the client currently completes their job, the entire business process, from start to end. It considers what tools and information a client needs to be able to complete their task, not just the core toolset needed to meet requirements, but supporting tools that increase the user’s efficiency when interacting with the system.

Let’s see how this affects the user experience:

Requestor Actions

1. The requestor logs onto SharePoint, goes to the HR Forms page, and sees the following:



The HR Page has the most common forms and documents on the front page of their site for quick access:



The HR Page has a web part that filters on the current user, and displays the current users banked and vacation hours balance:



The HR Page has a view of a centralized project calendar that allows the requestor to quickly see what upcoming projects they are assigned to:



All of this information is in a centralized area to allow quick access to all of the information the requestor needs to fill out the vacation request form. No need to email the project manager for upcoming assignments, no need to log into the time tracking system to find out banked hours balances, no need to email HR for any other questions.

Already, we start to see some of the increases in efficiency this approach can have, with a requestor not needed to spend time sending a question, and the supporting resource doesn’t have to spend time researching and responding (project manager or HR person).

2. The requestor fills out the Vacation request form after cross checking their availability and submits. A workflow informs their manager of the request.
 
Manager Actions

1. The manager receives a workflow notification that a vacation request has been submitted. The email they receive has two links. One directly to the form, and one to the HR forms site. When they click the link to the HR Forms Site, they see a view very similar to the Requestor. The difference is the "Person Selector" on the banked hours web part:



This allows them to select the requestor who has submitted the vacation request to them, and both view the banked and other hours for that person. It also updates the Project Calendar to only include that requestors projects. The project manager does not have to log into any other systems to determine if they can approve this request, the information is all available on the HR screen.

2. Based on this information, the manager approves or denies the vacation request. If it is denied, the requestor is informed by workflow. If it is approved a workflow informs the HR Group.

Human Resources Actions

1. Human Resources receives a workflow based email that has two links. One is directly to the form submitted by the requestor and approved by the manager. The other is a link to the “Human Resources Vacation Center”. Here is what they see:



The items that appear in the Vacation Requests section are vacation requests that are either unassigned, or assigned to the current Human Resources Person. This gives them immediate access to the two form types they are concerned with:



They can also cross reference the Vacation Calendar, that has ALL vacations listed for employees so they can be sure their are no conflicts for key resources:



And they have the gadget we are already familiar with to cross reference banked and other hours:



2. The Human Resources Person first opens an unassigned form and assigns the request to themselves. They can open the form from the workflow email or they can open the form from the “Vacation Requests” section of the page shown above.

3. They then cross reference with the vacation calendar and the entitlement hours to determine if they can approve the vacation request. They click "approve" or "deny" on the vacation request.

4. Both the manager and the original requestor are then informed by workflow of the success or failure of their vacation request.

Summary

Just as the technology centric system did, this one meets all of the original system requirements. By having a client centric approach however, more effort was made, right from the design stage to consider the following:

1. What tools does the current user need to finish their job?

2. What information does the current user need to finish their job?

By using this approach, we not only create a core system that meets requirements, we are measurably improving the efficiency of the Vacation Request process, removing the need to use external tools or communicate with other team members in order to be able to complete the request.

This system is certainly a better system from the solely technology focussed approach, but is it the best we can do? And it definitely leverages more of SharePoint’s abilities, along with effective solution design, to measurably increase the efficiency of the Vacation Request Process. But are we at an end point?

What if we were able to combine the two focusses? What if we spent an equal amount of time on BOTH the client centric analysis and THEN the technical components? In other words, we complete client centric design and then present that design to the technical team for further improvements? Let’s take a look.

Client AND Technologically Focussed Design

The first focus discussed in this post was the technology centric design, showing how considering the technical solution early and consistently throughout the design and development process can lead to a specific resulting system. One that technically meets requirements (it works) but is not really an improvement on existing systems when considering efficiency, and certainly doesn’t leverage SharePoint abilities and tools.

The second approach showed how understanding and defining the business processes first, then asking the client not just how the current system works, but also how they complete the entire Vacation Request process from start to finish improves system design. What information do they need? What works? What doesn’t? This information is then used to design the system based on a client centric model, obeying the key tenants of good system design:

1. Give the user all of the information they need to support the process.
2. Give the user all of the tools they need to support the process.
3. Don’t give them any information they don’t need to complete the process.
4. Don’t give them any tools not related to the process.

This system results in real measurable differences in efficiency in the Vacation Request process. But we can take it further. Once the system architecture and design has been determined, the architecture can be reviewed by the technical team for further improvements.

So, a technical team reviewing the client centric system design may say:

1. We have a few read only connections to external systems to allow information review. Why don’t we replace them with read/write connections and automate some of the manual tasks?

2. We can provide the information supplied by the Available Hours web part and the Payroll details web part right on the infopath form. That way, the user doesn’t have to refer back to the web parts for information, its right in the form as you fill it out.

3. We can automate the HR Vacation Approval tasks using these read/write external system connections, so that when an HR person approves the form, both the time tracking and payroll systems are appropriately updated as soon as the HR person clicks “approve”.

4. We can create a vacation trending chart that uses real time data to show vacation request history:




These are all great technical ideas that further increase efficiency and reduce the amount of effort needed to approve a vacation request.

So, this final approach based on completing client centric design first, THEN having an expert technical team provide recommendations and suggestions gives us the best of both worlds, effective client centric design that leads to improvements in processes and higher client satisfaction, along with technical solutions to key areas to further enhance those goals.

So why isn't this development model followed by more SharePoint solution providers? There are some outstanding examples of client centric design being built right now. Why isn't client centric design being used more often throughout the SharePoint development industry? Why do we still see production level SharePoint systems that resemble the first Vacation Request system example more than the second? The next post will examine where those barriers came from, and how to challenge them.

InfoPath Development Process using best practices

InfoPath 2010 is a powerful form creation tool, from web enabled forms that can be accessed from anywhere to internal company forms that manage HR process, InfoPath is an important part of any form based SharePoint solution.

Just as in any development, there are best practices that can be followed when developing InfoPath forms. Note that development here means developing the form within InfoPath 2010, not writing a code based form using Visual Studio. Coding best practices are well covered here.

This best practices document covers best practices for use with InfoPath 2010. This post is intended to be "living", that is, I will update and improve as these processes are repeated in a professional development environment and refinements or updates are made.
The steps for form design and development, with associated recommendations, are in order as follows:
• Form Types
• The Form Design Process
• Form Design
• Form Development

Form Types
The first decision that has to be made when designing and InfoPath based form solution is which type of form to use?*

List Forms store all of their data in an associated SharePoint list. As a SharePoint list has a flat data schema, the data schema associated with the form will be flat as well. The form is generally bound to a single list and the data associated with that form typically remains in that list. List Forms are a good choice where the various fields associated with the form area also needed in reporting and other internal data retrieval processes. Since all of the data associated with a list form is in a SharePoint list, all of the functions related to SharePoint lists, such as building reports directly against the list using report builder are supported. List form data is typically not mobile (moved from one list to another).

You can create a master/details scenario for repeating data using list forms, using two lists linked together with a lookup field, or you can simulate a one to many relationship by adding columns to the flat schema to hold all repeated data, generally the cap on this approach is 10 columns max, use a linked list if the you require a larger number of detail columns. Using an InfoPath filler based form template provides you with master details data support by default (see “InfoPath Filler Form” section below).
Generally, List forms are simpler non code modified forms that directly attach to SharePoint lists.

Form Library Forms store all related data as an xml file. This gives the potential for nesting data schema’s, as the restriction on schema type is limited to what can be produced in XML, rather than a flat list.

As form libraries store the data as xml, the amount of steps to extract data for other purposes (binding to workflows, reporting, shared data with other forms) is higher than List forms, as you not only create the field to hold the data, you have to promote each piece of data that needs further interaction as a site column.

This additional effort to expose values stored in form library forms may be required if other features of the form library only available using that form type. It also adds a small inefficiency to the design of the forms, as data from the forms that needs to bind to workflows or be reported on is now in two places, the xml behind the form, and the site column in the SharePoint database. And also consider whether you wish site columns to be part of the content crawled by SharePoint Search (they are not by default).

The other feature of Form Library Forms is the ability to turn them into site content types. This allows additional functionality, such as the ability to MOVE FORMS between any SharePoint Library that has that form added as a content type, and using RECORDS MANAGEMENT rules to move form data if necessary, as well as binding workflows directly to the content type so that the workflow fires regardless of where the form is stored.

In summary , use a list based form if you wish to interact extensively with the data and do not need the features of the Form Library forms. Form Library Forms are more advanced forms that allow coding, digital signing, and can be used in sandboxed solutions.
InfoPath Filler Forms can be either List Forms or Form Library forms, the difference with these forms is that they can only be filled out using InfoPath filler, as opposed to being a web enabled form viewed from within SharePoint. All users who use this form must have InfoPath form filler installed locally on their machine.

The advantage of InfoPath filler forms over web enabled forms is specific functionality is available that is not available in web enabled forms, such as the supported display of master detail type data. A complete list of differences in functionality is listed here.*

* See the deployment section for further considerations around list based forms.

**One "gotcha" with web enabled forms that aren't present in InfoPath filler forms is are the oddities around tab order and the people picker. Basically, an InfoPath filler form correctly obeys tab order including people picker, the people picker on a web form doesn't.

The Form Design Process

The first step with any InfoPath project is to design the form and work through a design approval process with the client. At this time, no functionality or data connections are configured, the sole focus is on creating a form design that meets the clients requirements. This means creating a prototype form that doesn’t have any functionality or data connections, it’s simply the form created in InfoPath with the proposed look and feel of the final form as well as any fields associated with the form.

This version of the form is then provided to the client, usually the first version is a demonstration directly with the client to allow feedback and questions. The form then goes through a number of design phases and iterations as the client finalizes the look, feel, and functionality of the form.

While some show/hide rules may be associated with the form at this time to demonstrate specific functionality to the client, most of the logic and development is not completed at this time, as the form is in a state of change. The final design of the form may differ significantly from the original proposed design, so any development work may have to be re-edited and changed for each iteration. Saving the development work for after design approval is more efficient.

Challenging areas of form functionality can be tackled at this time however, see the “Proof of Concept” section in this document to cover this area.

Form Design
Form design refers to the look and feel of the form, the way that fields are placed, the information located on tabs or views, and the color and font scheme.

The first step in creating a new form, after determining the form template type, is to add all of the fields to the form. The fields should be named in Camel Case to speed up form development, if you name a control UserName for example, if you drag the field on to the form, InfoPath will automatically separate the field on the capital letter, so that the field descriptor looks like “User Name”.
Many of the InfoPath form design best practices are also web best practices, such as creating a clean interface and limiting each page to a maximum of 40 fields. This document does not go into detailed interface or web design best practices, but does make the following recommendations:

1. First do a sketch or wireframe model of the general form appearance. If the number of fields exceeds 40, use multiple tabs or show hide sections to hide additional fields. Plan the form design before opening InfoPath.

2. Create your fields first using a clear naming scheme that describes the data held in the field, name your fields in Camel Case. If you are using tabs, name the folders that contain the fields the same name as the tabs, so that it is obvious and intuitive when working on one tab which fields are associated with that tab.
3. Use tables to ensure field alignment in your forms. Don’t hard code colors or fonts, use the built in themes or font styles instead.

4. Use views to separate data groups. So, if you have a form that has employee information, request information, and manager approval information, create three views, one for each. Related data should remain in a single view. You can navigate to a view directly from the URL with the parameter ‘defaultView=[ViewName]’. Views can also be used in wizard like interfaces, where each view corresponds to a step in the form filling process. This type of more involved form development can occur in this phase as it may be important to demonstrate to the client how this functionality works and looks.

5. Name similary or same controls on different views with a view descriptor as well.  If you have a save button on each view of the form, ensure each one is named with a view as well, ie Save_Employee, Save_Manager, etc.  This will avoid confusion between similar controls when configurating rules and interactions.

6. Create a read only view on forms where the initial form user needs to be able to review their form information after submit, but not edit it.

The general rule for form design is to keep the form simple, and to avoid as much development work as possible on the form at this time to prevent needing to rework the same areas multiple times. You may however have to add some functionality in order to demonstrate show/hide or other functionality that is key for the client to understand.

Proof of Concept Work

As you review the form requirements and complete the design work, you may run across one or more functional areas that are either new areas of knowledge for you or complex. Make note of any functionality that looks challenging, and, during the design approval process, use this time to perform Proof of Concept work.

Proof of concept work is solving a technical challenge in isolation, with the intention of duplicating the solution on the client form once defined.

So, for example, if you have a form that has a number of statuses associated, each status indicates a step in the approval process of the form. One way to limit which statuses the end user can select is by creating a list with the status values associated, and then using SharePoint permissions on that list, limiting which list values will load into the form based on current user permissions. If you are also triggering workflows off of this status, the workflow that detects this status will have to be developed using the status ID value from the list, not the text value.

This specific functional challenge is outlined here.
This complex piece of functionality can be isolated and programmed into a new form, one that only has the minimum fields necessary to support the functionality. Then the process of extracting the status, based on permissions, and having a workflow detect that status are added to the form and workflow. Once the functionality is working and proven, the process can be documented for repeating later.
By documenting the solution, you allow future challenges similar to this one to be troubleshot faster, and you share the solution so that others in your team will not have to spend the same amount of time getting that functionality working.
This is one of the key tenants of best practices, repeatability. Finding an answer to a complex problem once is challenge, having to find the same answer again is a waste of time.
Proof of concept work completed during the design phase allows development to continue while waiting for final client approval, and allows complex technical areas to be resolved in isolation without having other areas of functionality potentially causing confusion.

Form Development

Once the client has approved the design of the form, and you have completed and documented any proof of concept work, you can start on form development.

Form development is the addition of the functionality and tools associated with the form. This includes:
1. Data validation
2. Formatting (show/hide, colors)
3. Actions
4. Default Values
5. Data Connections
6. Associated supporting tools (lists containing populating data, list that holds form data)

If your form has complex functionality or multiple stages, you may wish to create a debug view associated with a debug page that shows key values for that form. If you have a form with a number of hidden variables that manage state and appearance, then create a debug view with those fields for quick reference during preview.

Preview your form often, particularly after each new area of functionality is complete, to ensure any bugs or issues are trapped as they occur.
Name any rules appropriately by function, so that the purpose of the rule can be extracted by the name of the rule, ie “Show Hide Submit Button”. Adopt a consistent naming convention for all fields or rules to enable rapid troubleshooting and maintenance of the form.

Keep the data structure associated with the form as simple as possible, nested and repeating data adds significantly to the amount of effort necessary to bind the form to its data connections. Ideally keep the schema flat, where one to many relationships are simulated using multiple columns instead of a separate table. There may be a functional requirement for using complex data schemas, this is fine, the general rule however is to keep it as simple as possible.

Consider form load times for media and data. An infopath form can embed images within the form template (as opposed to having a link to an image), this can be useful in situations where the users of the forms don’t have permissions to the original images, but need to view the form with the images intact. It will add significantly to the size of the form however, so only use if necessary.

The “automatically retrieve data when the form is opened” on data connections can significantly slow the form load. It is better to delay the data load to on demand.
Filtering data before it is used in the InfoPath form is another way of effectively reducing load times.

As you develop the form, be sure to stay on top of maintenance, not just removing a control from the form but ensuring any fields and rules associated with that control are also removed. This also prevents unexpected behaviour caused by orphaned rules.
As in proof of concept work, any tough areas of functionality should be documented so that the time spent researching the solution does not have to occur again. Documentation may seem like a time drag at the time of creation, but being able to quickly refer to it again when encountering the same or similar issues more than makes up for that initial investment. And having other developers able to refer to that documentation instead of researching issues themselves is a further time saver.

Overall, form development that matches best practices does not simply produce a form that works for the client needs (meets requirements), it creates a robust form with reliable functionality, with a design that is easy to maintain. Using a documented approach to technical challenges also creates a knowledge base within your organization, so that new developers or team members can more quickly be converted into value producing resources.

Deployment

Once design work has been completed, if you are deploying your form straight to production (using InfoPath Designer's Publish ability) then you can start development immediately using the front end tools (InfoPath Designer, SharePoint Designer, Other Office tools).

If however you are following a more traditional Software Development Lifecycle where different environments have been created for each stage, such as development, testing, and production, then deployment influences your form type choice as well.

A SharePoint list based form cannot be deployed using the same techniques as a library based form, due to its specific functionality.  When you add or remove a field from the associated list, the form itself needs to be updated and published manually.

http://social.msdn.microsoft.com/Forums/en/sharepointinfopath/thread/8d31489c-5c31-4f3f-9ae3-5e59ccb4228a

In this situation, you may determine that a form library is the best solution, as the only way to script and have the forms deploy automatically through multiple environments is by using a form library based form.

This comes with a cost to the client however, as the amount of effort needed to modify a form library form with a new field, and have that field then exposed for reporting or workflow usage is considerably more than simply adding a field to the list and then editing the associated InfoPath form by adding that field and publishing.

If you are deploying your InfoPath forms based solutions through multiple environments then Form Library based forms may be your only practical solution.

If however you are deploying straight to production, then choose the best form type for the business application using best practices as outlined in this document.