Home > Articles > Home & Office Computing > Microsoft Applications

Steve Mann Talks SharePoint 2010 and InfoPath

  • Print
  • + Share This
Steve Mann, author of InfoPath with SharePoint 2010 How-To, and InformIT Senior Editor Dustin Sullivan discuss SharePoint 2010's integration with Visual Studio and InfoPath 2010, including the features these developments bring to the table and the skills that administrators and developers will need to leverage them.
From the author of

InformIT: It's traditionally been difficult to develop for SharePoint, to a large extent because of the inability to use Visual Studio tools. Now that SharePoint 2010 has development support in Visual Studio 2010, it's much easier for developers to get started. Do you think this support is the game-changer that will really set off a large amount of SharePoint development?

Steve Mann I think it's a step in the right direction and something that was expected within the new VS 2010 tool set. The full line of SharePoint 2010 project templates available in Visual Studio 2010 definitely makes life easier. Once MOSS 2007 was released, the development activity took off. I think we'll see that even increase with the adoption of SharePoint 2010 and Visual Studio 2010. Now that various SharePoint development aspects (web parts, content types, list definitions, etc.) are easier to create, we'll see more organizations and developers expanding their horizons and attempting to produce more complex business solutions.

IT: Is the integration between SharePoint 2010 and InfoPath 2010 as significant in the evolution of SharePoint as the integration between SharePoint 2010 and Visual Studio 2010?

Steve Mann The InfoPath product and form structure has been integrated more tightly into SharePoint 2010; providing the basis for list data entry and form rendering (ala the InfoPath Form Web Part). It is very significant since InfoPath 2010 is an Office product, and by bringing it to the forefront as a mechanism for customization we'll see more business users working with the tool versus Visual Studio where the main focus has been .NET developers.

IT: Can InfoPath 2010 be effectively used by endusers, or would you recommend that the SharePoint administrators retain those responsibilities?

SM InfoPath 2010 is an Office product and has always attempted to be incorporated into the toolset of business users. I believe that content managers, business analysts, power users, etc. should ramp-up on the product to easily produce business solutions without depending on IT development. While SharePoint admins may need to be involved in certain cases, with the proper training and skillsets, end users can become self-sufficient and thus more productive in customizing SharePoint and addressing business requirements.

IT: Does a SharePoint site have to be specifically designed to work with InfoPath, or is it modular enough for that to be added later? For instance, if an enduser builds some of his own solutions using InfoPath, is it easy to incorporate those features into existing SharePoint sites, or does this functionality have to be accounted for when the original site is being built?

SM From a content type perspective, a Form Library can be created under most sites and used to house InfoPath forms. As far as using InfoPath to modify the user interface for lists, that is specific to each individual list. Therefore, the best way to programmatically perform this customization on custom lists is to define the list definition using Visual Studio 2010. Then each time that particular type of list is generated, the custom user interface forms are included. Otherwise, it becomes a one-to-one situation where each customization is unique to a particular list or site.

IT: What are the coolest features, both within SharePoint 2010 as well as in InfoPath 2010, to benefit administrators? How about for users?

SM For administration, there are two features that stand out when asked that question: Health Analyzer and PowerShell. Previously, it was up to the administrator to keep track of logs and monitor the SharePoint farm and databases. Now the Health Analyzer will generate reports explaining potential risks or issues. Not only does it explain the problem but also presents possible solutions or remedies. In some cases these issues may be resolved automatically. The PowerShell integration allows for easy scripting of operations. Administrators can script out tasks and run the same script in multiple environments (or servers) if needed. This automates administrative tasks and reduces manual procedures (which can be tedious if they need to repeated again and again). Stay tuned for my How-To book on PowerShell with SharePoint 2010.

For users overall, the collaboration aspects within SharePoint 2010 have been sharpened. This sharpening involves the enhancements within the My Profiles and My Sites. While this is called Social Collaboration and may mimic functionality in social sites such as Facebook, it provides business value by understanding what people are working on, who they work with, what skills they have, contact information, and so on. The communicator functionality which is now available from Lync Server 2010 provides the collaborative glue between SharePoint and Office products and allows for live interaction between users and groups.

IT: How much SharePoint development expertise is required for a systems administrator in order to leverage SharePoint 2010 to its fullest capacity? Can a "traditional" sysadmin handle it?

SM It really depends on the roles and expectations of the administrator position. You can correlate this to databases. There are some DBAs that code stored procedures and perform development activities while others only manage the databases and the servers. If it is the system administrator's job to provide business solutions other than the out-of-the-box functionality, then yes they would need to be proficient in SharePoint development. If not, then I would hope that system administrators study the various topologies so they understand how to scale out their architecture based on increasing needs and usage. Also, they should be proficient in the myriad of service applications which ultimately provide business value (e.g. Excel Services, PerformancePoint Services, etc.) and understand how they should be configured and managed for optimal performance.

IT: Ideally, what skills should someone have prior to starting out as a SharePoint developer? What about for an administrator?

SM A SharePoint developer should have a solid .NET background and understanding. This is required to work with the SharePoint object models and provide solutions utilizing the SharePoint objects along with providing Visual Studio based solutions such as workflows. For visual aspects, solid ASP.Net experience helps build upon the presentation layer. The defacto .NET standard programming language is C#, although some IT shops take the VB.Net approach. Most bloggers provide solutions in C#.

IT: In closing, what can SharePoint users and administrators expect to gain from having your book as a resource?

SM I attempted to cover all aspects of using InfoPath 2010 within a SharePoint environment — even troubleshooting. The premise of this is creating web-based forms (which are essentially InfoPath forms that can be rendered within SharePoint). The end result is being able to fulfill business requirements by providing a user-friendly form-based interface. While there are technical solutions discussed, most of the tasks and solutions do not require code. If you read it from cover-to-cover you'll become very knowledgeable on how things may be accomplished. If you sit down with the book and go through the steps on your computer, you'll become acclimated with the product and probably come out with an Intermediate level skillset. Overall it provides a great tutorial and then as a reference when a user or administrator needs to perform certain tasks and asks themselves, "How do that I do that again?"

Be sure to check out Steve's book, InfoPath with SharePoint 2010 How-To, published by Sams.

  • + Share This
  • 🔖 Save To Your Account