Monday, December 26, 2011

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.

Saturday, December 17, 2011

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.

Saturday, December 10, 2011

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.

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.


Friday, August 19, 2011

InfoPath development, schema first

Microsoft has some excellent documentation on InfoPath development for SharePoint, no need to repeat it here, the link is:

http://www.microsoft.com/download/en/details.aspx?id=1094

One of the development best practices that I would like to talk about however is the concept of schema first InfoPath development.

If you have come from a .net development background as I have, the normal process for creating a web form is to first drag and drop controls on to the form, do some formatting and look and feel changes, then work through and name each control so that it can be correctly bound to the data layer.

The same process can be used in InfoPath, and it is certainly not the wrong way. However, it may mean that, especially in the case where you have non flat data schemas associated with your form, that you have to revisit each control you added in the form to define both their appropriate binding names and their relationships.

Why not create the schema first? You can add the fields to InfoPath one by one in the right field window by right clicking and choosing add, you can group fields together related by function, and you can create one to many relationship definitions. Define your fields in Camel Case (FirstName, LastName).



Once you have finished defining the schema, you can drag and drop fields onto the form as you would from the top toolbar. If you have correctly used Camel Case, InfoPath will insert spaces correctly in the field descriptors. The advantage of this approach is:

1. By defining the data schema first, you are getting a deep understanding of the underlying data set first, negating complicated changes that may have to occur if you have created the form and all of its fields first and then perform changes necessary to match the data schema.
2. You do not have to go back and rename fields from the generic SharePoint field names, creates a streamlined process.
3. You avoid the generic flat data schema automatically created when you use the original method of form field data population.


After defining the data schema, you can drag the fields one by one onto the form for a specific design, or do as I did for the form below, and simply drag the folder to add all of the elements at once! Not only is the process streamlined for adding fields, but I have more faith in the underlying data structure as well simply because its pre-defined before the form is created.


Wednesday, July 20, 2011

Third Party SharePoint Tools

The recent increase in adoption of SharePoint 2010 in a wide variety of environments has led to the development of a number of third party tools, said to enhance or accelerate the abilities that exist natively within SharePoint.

How much value can these third party tools provide?

The first thing to understand is that, in most cases, third party tools are built on top of the SharePoint platform, they used code based and configuration based changes to perform tasks that SharePoint then completes itself. So the value the third party tool usually adds is not ADDITIONAL abilities to the platform itself, but instead:

1. It may have an interface or way of presenting data, such as workflow planning, that is more intuitive than that that comes with SharePoint. SharePoint designer is the primary development tool for SharePoint, but you do have to be a technical user to leverage its ability. One advantage may be a simplification of tasks within SharePoint through a more user friendly interface.
2. It may ACCELERATE the process of setting up specific areas of functionality. So, if you are planning an enterprise content management system through SharePoint, without third party tools, you have to create every repository, set up all content types, determine classifications, customize searches, as well as many other tasks needed for ECM. With third party tools, you can enter in taxonimical and classification information, and have the third party tool generate all of the necessary supporting structures, including content types and repositories, automatically.

The important point here is to see where the value of most third party tools lie. It does NOT typically increase the actual abilities of SharePoint, as the tools are themselves are actually built upon the SharePoint platform. The advantage lies in the way they present information and the acceleration of specific tasks within SharePoint.

If the barrier to using a new technology or setting up an environment in SharePoint is both bandwidth(available time) and ability to use the tools that come with SharePoint, then a third party tool, properly investigated, may be a good solution.

However, the abilities of SharePoint and SharePoint designer "out of the box" are extensive and deep. It is important to understand what those abilites are and how they function before making a third party tool decision, to ensure you are getting good value for the purchase and not simply replicating functionality that already exists and is readily available in SharePoint.

Monday, July 11, 2011

Records management and business process collaboration, two different needs?

In SharePoint 2010, we have a technology which completely supports Enterprise Content Management. From improvements to interface and configuration abilities to improvements on the server side such as:

Allowing servers dedicated to records storage, allowing the core SharePoint site to maintain its speed and reactiveness to user input even under heavy load.

Allowing dedicated search and index servers to handle the job of indexing and allowing rapid searching of up to millions of records.

we now have a toolset that can truly handle both physically and through configuration abilities the enterprise level records management process.

The first steps to planning a content management solution is deciding upon classification and key data schemes for the various types of documents in your organization. This results in setting up site collections to support the classification scheme and contain the document repositories, including archive areas for documents that are retired either manually or by a rule or set of rules (such as age, document type).

One advantage of this classification scheme is that it allows configurable searches, so that searches can be restricted to specific document types, such as meeting minutes or quarterly report powerpoint presentations.

These are the core tasks of setting up SharePoint Enterprise Content Management.

But there is another need for these documents, beyond having them in a single location properly categorized with routing and archiving routines.

And that need is in collaborative business processes. On the one hand, you have all of these documents carefully organized into categories each represented with a document library. This means all related documents are typically found together, such as meeting minutes, or departmental processes or policies. But a collaborative business process probably requires documents from DIFFERENT areas or categorizations to support that process.

So, a quarterly report may require prior quarterly reports, departmental report templates, board or stakeholder input, key project documents, etc. If the user had to search for each of these documents in support of the quarterly report, they would have to search different areas in the Records management scheme.

Fortunately, SharePoint supports exposing the same documents in multiple locations, meaning that, just because a document resides in the 11-077C document classification document repository, doesn't mean it can't also be exposed to a team site set up to support the quarterly report. The team site can have a one time set up that links to all documents through its document repository to the team site. These document links are used as regular documents, to the user, there is no difference in abilities.

Any updates to the documents in either area, document classification repository or team site repository are reflected in the other, and new docouments added to the team site can be auto routed to the correct location in the classification system as well.

The seemingly opposing needs of enterprise records classification, and the need for collaborative local document areas can be effectively countered by exposing documents in the classification scheme to other document repositories associated directly with specific business processes.

Wednesday, July 6, 2011

Is SharePoint the right choice?

The recent interest in SharePoint shown by many areas of both public and private sector organizations has led to an increase in attempted solution development both within and contracted out to solution providers, both managed and ad-hock.

But is SharePoint the right choice?

Are the business processes you are interested in managing suitable for the SharePoint Environment? SharePoint is a highly configurable set of business support tools, but they do have a focus and certain things that it does very well.

SharePoint is considerably more configurable and flexible than most proprietary enterprise level solutions available, such as large scale financial or health systems. But it certainly isn't a replacement for any of these systems. You can expose specific areas of these systems through SharePoint to inform or participate in a business process, but SharePoint is not suited to the specific, enterprise level complexity that these systems have.

The other end of the solutioning scale involves custom development tailored to a specific business or organizational area, there is a great deal of control over interface and data management, the toolset is custom built to a specific set of requirements provided by the client. This type of solution development is appropriate for an organization with very specific needs and the ability to support large scale development. .NET being one flavour. It may be the only solution for a company with large scale highly specific data intensive needs.

SharePoint is a hybrid of these two approaches. It is certainly more flexible than most proprietary solutions, and contains toolsets and abilities that would be too labour intensive to reproduce using custom development.

This decreases the range of projects that are suitable for SharePoint right away, obviously highly complex systems such as accounting systems, transportation tracking systems, student information systems, and many others are not good candidates for SharePoint. And highly complex custom systems still require custom development.

So what is SharePoint good at? One big area of course is information management.

"living documents" are created, stored, and all updates and changes are managed and tracked, anything from HR policy documents to custom company templates. Automatic archiving, the retrieval of last versions and rolling back changes, all surrounding document management.

Of course, information isn't limited to documents, data coming from infopath forms, stored in SharePoint lists, can come from many sources. From vacation requests to issue tracking, from a client list exposed from your CRM through SharePoint to tracking attendees at a conference.

This information, in addition to the built in versioning and other tools, can also be routed and updated through the use of Workflows.

A vacation request system automatically informs appropriate approvers of new requests, tracks the progress of the request through the system, and provides information from time tracking or resource planning systems to ensure that there is sufficient vacation earned and that major projects or other organizational events have backup plans for missing employees.

The workflow integrates these tools together along with the office suite. So you can take a process formerly managed in excel, such as tracking orders or event contributors, import that information into SharePoint, and automate many of the processes surrounding that information. Informing the appropriate people that an order has come in, having that order tracked through to product completion gathering the appropriate information at each step along the way and allowing easy access to the overall status of all orders in the system.

More complex workflows can also manage processes such as:

- Course Development
- Thesis Tracking
- Case Tracking
- Collaborative Publication, such as multi-person legal documents

So information management means gathering, tracking and manipulating that information as it supports the associated business process from start through to completion. Informing the correct people at each stage, allowing reporting on the status of that information in the system.

If you job involves creating, updating, or approving information through a known process then SharePoint can probably help manage that process. Business Analysis, who typically collect information concerning data collection and management in a business process from clients or stakeholders, and document and organize that information into requirements, can manage that information very well in SharePoint. Many positions at an organization can benefit from those capabilities, from CEOs to project managers, from Business Development users to administrative assistants.

These core abilities of SharePoint are expanded greatly with some powerful data manipulation abilities such as excel services and performance point, to allow analysis of data and inform decision making. In combination with the other abilities also covered, you can see how the development of items such as quarterly reports could be made easier, quick access to company health data exposed through SharePoint, all documents that support that information stored and tracked in SharePoint, meeting schedules and attendees quickly available all in one place.

Other tools expand the abilities of SharePoint as well, from the comprehensive "my sites" social collaboration tools to blogging, discussion group and wiki tools, these tools can also support a business process or be dynamic content of their own.

Exposing all of that information and combining it with more typical web toolsets, such as wikis and blogs, allows the generation of dynamic content that can be both internally and externally exposed, CONTENT management is the other key ability of SharePoint. Some institutions have even used SharePoint as an online course delivery platform, it is certainly well suited to creating a web presence with non-complex out of the box access to many common web tools.

The range of tools and configuration options in SharePoint is vast, and the ability to custom code areas provides further flexibility. However, these abilities are still focused on business processes that can use the suit of tools provided by SharePoint, highly customized systems or customers that require specific interfaces or deep complex data schemas are not good candidates for SharePoint.


The core of professional analysis to determine suitability is a simple question:

How compatible is the current or proposed business process with the SharePoint Solution toolset?

Determining what the client or stakeholder needs are in detail, and seeing if the technical abilities of SharePoint can meet those needs, THAT is the first key stage to determining if SharePoint is the right choice.

Wednesday, March 30, 2011

Embedding a link to a printable list item in a workflow email.

When you create a workflow based on a list item, such as sending an email after an item has changed, it is useful to have a link within that email that links back to the list item. It would be even better to have a link back to a printable version of that list item.

The default link creation tool in SharePoint Designer workflows however doesn't work. If you attempt to add a link using the SharePoint designer field created for that purpose, you will end up with a link that connects do nothing and doesn't work.
So how do you create a link back to the list item that does work, with a printable version of the list item?

Open your existing workflow or create a new one.

Set up all of your conditions as necessary, and then set up the "Send Email To" action, filling out fields as appropriate.

In the body of the email, to link to the original list item, do the following:

1. Type in the text in your email that will be the link to your item, such as "View Test Case" or "View List Item". Highlight the text and click the hyperlink button.

2. "Text to display" will already be filled out if you highlighted your text, if not, fill out the text you wish your link to be associated with. Then, in the address section, click the String Builder button (3 dots).

3. Build the link in the following way:
- Start with the URL of your SharePoint server, egs. https://yoursite.gov.bc.ca. Note the lack of trailing slash.
- Click "Add or Change Lookup"
- In the data source field, choose "current item".
- in the field from source field, choose "Path"
- Leave the "return field as" field to its default, "As String"
- Click ok to build the first part of the url
- Append the following text to the URL "/DispForm.aspx?ID=" This must be EXACT including the beginning slash
- Click "Add change or lookup"
- Data source is current item
- Field from source is "ID"
- Click OK.

The URL that you have created should now look something like:
https://yoursite.gov.bc.ca[%Current Item:Path%]/DispForm.aspx?ID=[%Current Item:ID%]
Ensure all slashes and naming of the DispForm part are IDENTICAL.
Click "ok" then "ok" again.

Your workflow email will now have a link that links to a printable version of the list item.

Thursday, March 3, 2011

Triggering workflows on lookup fields

When you create a "choice" item associated with a SharePoint list, it is relatively easy to associate that choice with a workflow. You simple create the workflow, and in the condition portion, you select the choice field you created, and in the value column, you can select the choice that you wish to trigger the workflow on, for example:

If Current Item:Status equals (1) ready
Email steveburgess10@gmail.com

This is nice and easy. But what about the case where a lookup is used to populate the choice dropdown menu? If I have a seperate list that I wish the lookup to use, as shown below, then the approach needs to be different.



Comparing the lookup field value with either the ID of that field or the text of the field both fail, for example:

If Current Item:Dynamic Status equals (1) ready
Email steveburgess10@gmail.com

does not work. Even using the ID of the field (retrieved from the lookup list) does not work, for example:

If Current Item:Dynamic Status equals 1
Email steveburgess10@gmail.com

But we are close. The ID is the key. Here are the steps for correctly creating a lookup field that can trigger a workflow.


1. Within you SharePoint environment, navigate to the list you wish to associate the workflow to.
2. Click the "list" tab and then the "list settings" button in the office ribbon.

3. Click the link to your lookup field listed in the "Columns" section of the list settings page.

4. KEY STEP. As shown in the below screenshot, in the section titled "Add a column to show each of these additional fields", put a checkmark beside the ID value. This value is what will be tested against in our workflow.





















5. Open SharePoint designer and open the site that hosts the list you wish to associate the workflow to.

6. Choose the "Workflows" selection in the site objects collection, and select "List Workflow" from the choices provided.

7. Name and describe your workflow.

8. KEY STEP. Click the "condition" button at the top of the workflow page and select "if any value = value". NOT "If current item = value". While they result in identical looking code, using the second choice WILL NOT WORK. This will create your condition logic:

If field equals value

9. In the "field" selection that you wish to match against, choose the lookup list name:ID field. In my example, I am looking at the status field, so I am looking for the field value "Status:ID".

10. For the value, enter in the ID value that corresponds to the value of the lookup item you wish to trigger the workflow from. So, in my example, I know that the status ID of the status I am interested in is 4, so my condition looks like this:

If CurrentItem:Status:ID equals 4

Email steveburgess10@gmail.com

11. Add any fields or other information to the email that is generated, save and publish your workflow.

Associating workflows with lookup fields is not done in the same way as choice fields, as you cannot compare the selected values in the same way (such as a string compare). By extracting the ID value from the source list and including it in the destination list, you can compare that ID value to an integer value to successfully trigger the workflow.


Wednesday, March 2, 2011

Creating Default Values for lookup fields in InfoPath 2010

Creating a default value for a lookup field in SharePoint/InfoPath 2010 is not intuitive. When you initially create the lookup, there is no place for default value (as there is for non lookup selections) and when you open the form in infopath, and right click the lookup field, there is no option there to display a default value either.

This solution selects the default value on the creation of a new form record. It does not update existing records with no value selected to the default value.


Here is how to set a default value for a lookup:

Open the form in infopath.
Click the "File" tab ->
Click the "Form options" button in the "Advanced Form Options" section ->
Select the "Advanced" category (see screenshot 1) ->
Click the button "Edit Default Values" ->
Click the "+" on "myFields" ->
Click the "+" on "dataFields" ->
Select the lookup field you wish to set a default value for by clicking on it (see screenshot 2)->
Enter in the default value for the lookup field. Remember that the default value here is the ID of the record, not the name. See screen shots below ->
Click "OK" then "OK" again and first test functionality using "preview" button in infopath ->
Verify your lookup is now populating with a default value ->
Publish the form.

Screenshot 1, Advanced Form Options from file tab













Screen shot 2, Setting ID of default value