Make your InfoPath investment worthwhile- Part2 Integrate InfoPath with SharePoint

 

Here’re a few popular places where you can employ InfoPath forms for enterprise content management in SharePoint Server 2007:

·         Form Library

One of the ways you can use InfoPath with SharePoint is by creating a Form library on your SharePoint site. The InfoPath form library is the main integration point between WSS and InfoPath. All the documents stored within it are based on a specific InfoPath form template.

Pros:

Ø  Quick form development (reference part 1)

Ø  Property promotion and demotion - Not get schema validated though

Ø  User has the flexibility of working with documents in their native client application or online through browser interface. Properties easily bound into document and visible/editable offline.

Ø  Lookup data can be brought from simple xml file to any LOB applications and databases.

Cons:

Ø  Direct communication from a web form to a database is not supported. If you want the forms data to be saved to a database, the InfoPath client has to be installed on your computer. Or you’d have to construct a web service, which InfoPath can use indirectly communicate with the database.

Ø  The data source for lookup can’t be cross domain

Ø  Form service is hard to deploy a standard dev-test- production promotion deployment in an automated fashion. It is almost impossible to automatically publish the forms to a different environment without manual process

• Document Information Panel (DIP)

A document information panel is a form that is displayed within the client application, and contains fields for the document metadata. .

Pros:

Ø  Enable users to specify all the properties on a document at once, in one place, at any point when they are working without having to leave the Office client application

Ø  For SharePoint documents – 2007 Office client application auto generate the DIP based on the metadata schema of the content type assigned to the document

Ø  For document stored in WSS- the values are promoted back to the document library as columns. Users can edit document column values either at the Windows SharePoint Services 3.0 document library level, or from within the Office system client application for the document

Ø  User can have same DIP template for multiple office applications

Ø  User can either create DIP through MOSS 2007 interface or through InfoPath Client

Cons:

Ø  Office 2007 only (Word, Excel, PowerPoint)

Ø  InfoPath client need to be installed on the machine

Ø  DIP template with restricted security will not work. You have to provide Domain or Full Trust Security to DIP form template

Ø  Can have code behind DIP but the deployment process is not that straight forward

 

·         Workflow.

 Pros:

Ø  Browser enabled InfoPath form hosted in custom .aspx page

Ø  Custom workflow design in SPD or VSTO

Ø  Browser enabled view for mobile device

Ø  Driven by column value (Two way promotion, demotion)

Ø  Information Right Management. IRF protect for both form template and form content  (smart client only)

Ø  Digital Signature.

 Cons:

Ø  Hard to debug

Ø  Can’t handle very complex scenarios, need to incorporate with BizTalk

If you are putting together an enterprise content management solution in Office SharePoint Server, and you’d like your user to be able to interact with your custom forms in the client application and the browser, it might be worth your while to take a look at InfoPath 2007 and Office Forms Services.

 

 

 

Make your InfoPath investment worthwhile – Part 1 Why use InfoPath

In Microsoft office suite, the trend is:

·         Document-> word

·         Spreadsheet-> Excel

·         Forms-> InfoPath

InfoPath is designed for efficient forms management and becoming more mature. It is now a great idea for organizations to use InfoPath 2007 for their form development.

The strong points of InfoPath:

1.       Build on Xml, easy for organization to reuse data and connect to LOB

The data stored in InfoPath can be easily separated from the form and reformatted or reused in a variety of ways. This enables form designer to integrate form data into existing business process. For example, look at the use the form in SharePoint. InfoPath’s views and formatting elements are self-contained in the XSN file, which makes the InfoPath form very portable. On the other hand, if you use SP Designer to design a form in SharePoint library and submit it to a list item, the forms used here are very much tied to the lists they depend on, thus, are not very portable.

 

2.       Rapidly develop forms

InfoPath’s OOTB drag and drop support for form controls, table layouts etc allow the power user create a flexible form that is designed to accommodate the users. However, InfoPath does not support the following advanced scenarios like: tabs, custom AJAX/DHTML, multiple/nested forms. Meanwhile, InfoPath has a lot of features like rules, formulas, data validation, data connections, conditional formatting etc, which makes most form development does not need code. It out-weighted other form designing tools on this point.

As for developer experience, InfoPath2007 has strong capabilities allowing developers to efficiently develop and deploy form solutions. It has new object model which is based on .NET 2.0 and incorporate with System.xml. The code is written in common develop platforms (VSTO, VSTA). The coding experience is much more familiar and handy.

 

3.       Form services  VS Smart Client

The core concept in 2007 release is “design once”. It means you only need to design one form and it will work on both the smart client and form services.  You only need to compile once, deploy once, and send customer one URL, and InfoPath will work for them whether or not they have InfoPath.

An InfoPath form can be opened in:

1) Any browser (e.g. IE, Firefox, Safar etc.)

2) Desktop App

 

Most of the features are still available in both smart client and form services like most controls, business logic (rules, data validation, conditional formatting), new object model etc.  However, you can optimize for Desktop, but you cannot optimize for a specific browser or an environment. This is a limitation with any form tools which support variety of tools. The choice of controls is limited as well. The following table is a comparison between form services & smart client

No	InfoPath Form Services	InfoPath 2007 Smart Client
1	It support cross platform like (Unix/Linux.)	It doesn’t support
2	Don’t require InfoPath Installed in all User Machine	Required to have InfoPath Installed in all User Machine
3	Form accessible through web browser.	Form accessible through Office InfoPath 2007
4	Browser form relies on the server for a variety of form processing operations, require more communication to exchange data between the browser and the form server	InfoPath client doesn’t need to communicate with the form server as frequently. This is because the InfoPath client processes most forms locally on the user’s computer.
6	Does not support all features of InfoPath2007 Like Design & Compatibility checker	It support full features
7	Does not support all the controls of InfoPath2007	it support full controls

 

As far as which method is best, it depends on your situation.  Is the InfoPath client readily deployed to all users?   If the client has Forms Server already, and they are unsure about the availability of the InfoPath client for all users, I would recommend browser forms. The biggest selling point to clients for using Forms Services is that it doesn’t require a client app to be installed on users’ machines. From a client’s perspective, despite the fact that you do lose some functionality using Form Services, allowing the end-user to view forms through a browser far out-weighs any Form Services limitations. I have found the limitations in Forms Services to be minimal. You still get the majority of the OOTB conditional formatting, field validation and submit functionality.

 

4.       Automate data-driven business process

InfoPath 2007 has a very deep integration with the rest of MS office suite, especially SharePoint and Outlook. For example, you can integrate forms in outlook and promote fields and properties in Outlook folder. As for SharePoint, InfoPath can be used in workflow, form library, publishing content type, archiving, document information panel etc. I will talk more about it in the second part.

Deploy Master Page and Page layout as a feature

 

The following is the detailed the instructions of how to deploy Master Page and Custom Page Layout together

 

1.       The following is the directory structure which I suggest when creating your own features

 

       2.       Under the PageLayouts folder you will see two files:

·         MoscowLayout.aspx: this page is the custom page layout you created

·         MoscowLayout.xml: this is the manifest files that identifies your custom page layout

 

               You can put as much as custom page layout pages as you want in this folder, but you only need

               one manifest file

 

3.       The content of MoscowLayout.xml should be looks like:

 

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/” >

                <Module Name =”MOSCOWPageLayouts” Url =”_catalogs/masterpage”

                                 Path =”PageLayouts” RootWebOnly =”TRUE”>

                                <File Url =”MoscowLayout.aspx” Type =”GhostableInLibrary”>

                                                <Property Name =”Title” Value=”XXX”/>

                                                <Property Name =”MasterPageDescription” Value=”XXX”/>

                                                <Property Name =”ContentType” Value =”$Resources:cmscore,contenttype_pagelayout_name;”/>

                                                <Property Name=”PublishingPreviewImage” Value =”~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLeft.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLeft.png”/>

                                </File>

                </Module>

</Elements>

 

 

 Module:   indicate to SharePoint the location of the aspx pages. MoscowLayout.aspx is part of your feature and must be copied along with all of the other parts to the features folder. During the activation of your feature, it will be dropped in the Master Page and Page Layout gallery.

 

File:  defines the path to your page and the type. GhostableInLibrary tells SharePoint to create a list item to go with your file when it is added to MasterPage and Page Layout gallery.  Ghostable  is used if you are provisioning a file outside a document library

 

Two important properties:

ContentType:  OOTB Master Page Gallery has two content type associated with it. The value will either be master page or page layout.

 

Publishing AssociationConetentType: Specify ContentType to which your custom page layout is associated. The value of this one is composed of the name of your content type and the ID of content type. If this value is omitted, by default your layout will be associated with the basic ‘Page’ content type from the publishing feature

 

4.       You put your master page, css file into MoscowMasterPage. The wollongongmaster.xml manifest file should look like the following:

 

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>

                <Module Name=”MasterPages” List=”116″ Url=”_catalogs/masterpage”>

                                <File Url=”Moscow.master” Type=”GhostableInLibrary” />

                </Module>

                <Module Name=”WollongongStyles” Url=”Style Library” RootWebOnly =”TRUE”>

                                <File Url=”Moscow.css” Type =”GhostableInLibrary”/>

                </Module>

</Elements>

 

5.       Under the folder MoscowFeature, you will see Feature.xml, it will look similar to

<Feature Id=”{6EAA33DF-AD39-4a2c-B5AB-972A576D7CF4}”

                                 Title=”Moscow Branding”

                Description=”Master Page and page layouts for Moscow”

                Version=”1.0.0.0″

                Scope=”Site”

                Hidden=”FALSE” xmlns=”http://schemas.microsoft.com/sharepoint/“>

                <ElementManifests>

                                <ElementFile Location=”PageLayouts\MoscowLayout.aspx”/>

                                <ElementManifest Location=”PageLayouts\MoscowLayout.xml” />

                                <ElementManifest Location =”MoscowMasterPage\wollongongmaster.xml”/>

                </ElementManifests>

</Feature>

 

It contains ElementManifest files for master page and page layout.

 

This is just an example to give you a general idea of how custom page layout should be deployed. It depends on how individual elements are structured. And install.bat file is important as well because you need to copy the files to the right location in your 12 hives.

 

Farewell to Patrick Tisseghem

It is extremely sad for the passing of my dearest friend and mentor Patrick Tisseghem. I am still in shock and couldn’t believe this is real.

Patrick and I met in the sharepoint training course in Canberra and became good friends immediately since then. We talked about everything: dreams, beers, cars, lifes.. and of course SharePoint. He is charming, inspiring and down to earth. A man with integrity and true characters. He leads me not only in the adventurer of SharePoint but also in the journey of life.

He encouraged me to start this blog and also named it. (We had a couple of “disputes” about the name :) ) And today, when I am writing his farewell here, I looked back fondly on those time. Patrick, thank YOU for making my journey in Sharepoint such a memorable experience and always be there for me during my highs and lows in life. No word can describe how deeply I will miss you, my dearest friend, may God be with you and may you rest in peace.

SharePoint development tools

Just a show-off of my SharePoint development tool set

Must have:

·         Visual Studio 2008 + Visual Studio 2008 Extensions version 1.2

Before we use Visual Studio 2005 + Extension for WSS3.0 is because the development of Custom Web Parts, Site and list definitions etc for SharePoint is not readily available in Visual Studio 2008. Since the new WSS extension for 2008 released in June 2008 and fully support various SharePoint custom development templates, I think we can call it a day for VS2005

·         SharePoint Designer 2007

Visual Studio is great to develop custom features in SharePoint. But have you ever tried to modify a SharePoint pages in Visual Studio? SPD is great when comes to the issue of branding. It gives you great preview and all the controls SharePoint controls in a menu ready to drag & drop and use. The DataView Web Part is another great feature of SPD. It takes a short time to get a DataView Web Part on your page and linked up to a data source. Creating custom views and filtering information from/around the site simple using this feature.

·         IE Developer Toolbar

Inspect HTML source, style usage, IFRAME content, image location etc. Definitely play an important role when you have to start changing the CSS in SharePoint or need to address accessibility in your website

·         Lutz Roeder’s Reflector for .NET

No need to explain. Most developers in .NET world know this tool.

·         U2U CAML Query Builder

From U2U. A great tool for writing and firing CAML queries.  It helps you decipher CAML and do queries against your lists to see if your CAML will work. You can also save your queries in XML format and launch from your application or web parts.

Optional:

·         WSPBuilder

A SharePoint Solution Package creation tool for WSS and MOSS.  The manual process of packaging our solution is: we create your own manifest.xml and DDF file and use makecab.exe for nice granular control. With this tool, WSPBuilder will automatically traverse a “12″ folder structure and creates a SharePoint solution manifest.xml and the wsp file based on the files it finds. It makes SP deploying and packaging very easily.

·          Fiddler HTTP Debugger

Inspected and manipulate HTTP traffic between your browser and the server, handy for debugging web services

·         Power Shell

Write scripts to automate administration and configuration tasks. A small tip here, the next version of SharePoint STSADM will be based on Power Shell.

·         BDC Metaman

Generate BDC XML from SQL data source. The commercial version also builds definitions for web services. An alternative is baked into the MOSS SDK, but BDC Metaman will continue to be the gold standard

·         SmartPart

Another great community tool by U2U. A SmartPart is a SharePoint web part that can host any ASP.NET control. You can create your own web parts using VS.NET designer instead of coding everything by hand.

Custom Site Definition

Try to answer some questions regarding custom site definition in my company. Thought maybe it is worth sharing here.

1 – Can we make changes in an already created site, by making some changes to the Site Definition, or will the change be applied only to sites which will be newly created thereon?

 There is no easy way to modify site definitions once they are deployed. There is always the possibility of breaking existing deployed sites derived from the site definition once you modify an existing site definition. The best practice is always copy from one of the existing site definitions, rename it and modify it and then add to the site definitions.  The most popular one to start with is STS (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\). I  start with BLANKINTERNET, a bit tricky, don’t recommend. Alternatively, you can start from scratch (not recommended either).

 

2 – What are the basic advantages of creating a Site Definition?

Well there are pros and cons regarding the custom site def and I think you should know both sides

Pros:

·         The biggest one will be the performance as the pages are cached on the file system instead of in the database. You might want to go over the ghosted /unghosted concept if you are not familiar with it.

·         Higher level of customization by directly editing all the schema files and not depending on the existing site definition as a site template does.

·         Activate the features (especially site columns and page layout) during the site creation

·         Upgrade independent. Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.

·         Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu.

Cons:

·         Relative complex process, require access to the file system of the front-end Web Server (need to get an admin involved for deployment)

·         User cannot apply a SharePoint theme through a site definition

·         Editing a site definition after deployment is difficult

 

3 – How maintainable and flexible a site definition is from the perspective of making any changes to it, if required in future.

 

A combination of site definition and features is the best approach although MOSS versioning is still a pain.

 

4 – How can we make changes to the site definition? Feature Stapling is one option I have heard of.

 

Yes, when you want to activate a feature on a site definition that is already in production, or to add it to a OOTB site definition, you need to use feature stapling.  It is bad practice (and not supported) to change the site definition after it is being used in production.  Therefore, the feature stapling is a good option to go.

 

5 – Do we have any document on best practices that we can follow while creating a Site Definition?

There is a good article on MSDN regarding working with Site Templates and Site Definition. Worth to have a look.

http://msdn.microsoft.com/en-us/library/ms434313.aspx

 

 

Planing your SharePont WCE Site – Part 2 Solution Deployment

All right, time to resume our journey of branding SharePoint Internet site and I will talk about packaging this time (my bad for taking such a long time to update the blog, I guess the cold weather in Canberra plays a part)

As we all know, SharePoint development has two streams: artifacts and assembly based development. Although Microsoft advocates that Content Deployment should be used in artifacts development instead of feature/solution development. I can’t really totally agree with that. The way of deploying these artifacts is NOT simple “Copy and Paste” or “Reject or Approve”, at least not at the first place.  Content deployment should be used when the authoring environment and production environment are established and relatively stable.  (And you really need to think of if it worth doing so, as the process is not simple, especially when your site is mostly static pages and is not going to change very often )

SharePoint development is an integrated process. We can’t really draw a clear line and mark black and white between assembly and artifacts development.  There are a lot of dependencies between artifacts and assembly development. Although SharePoint Branding involved most of the artifacts development like Master Pages, Page Layout, CSS, Themes, Customizing Navigation, etc, in my point of view, you are still expected at the very least, to package your work into a feature so it can be deployed in a relative decent way.  And of course, the best way is always packaging all your stuff into a solution package.

Why? Because deploy as a solution package provide you the ability to

·         Deploy assembly DLLs to the Global Assembly Cache (GAC)

·         Register features with the WSS runtime

·         Update web.config file with SafeControl entries required in Web Part deployment

·         Install features to all web front end server in a farm at one time

The solution package itself is a compressed CAB file with a .wsp extension, and it contains one or more WSS components along with any dependent files that need to be deployed on each front-end Web Server.

A simple solution package might contain just the files needed to deploy a single feature. A more complex package could contain the files for multiple features, page layouts, web parts, list definitions, event handlers, and a site definition. You decide what goes into a solution package according to what set of components it makes sense to deploy as a single unit. The following diagram is a basic solution package for a SharePoint Branding site:

 

Planning your SharePoint WCM site – Part 1

Many organizations build their public-facing Internet sites using MOSS 2007 because of its WCM features. It has a lot of improvement over MCMS like: rapid site creation, caching, web-based management interface, new content deployment architecture, extensible workflow and search etc.. Recently I am building a MOSS Internet site for my company, a couple of thoughts I would like to share here:

1. Hosting Environment:  Ideally we will have two server farms. One for internal farm (for intranet) dedicated to the content authors/editors/designers and a second farm (in the internet- facing network) that hosts our production site. Our internal farm is read/write, while our production farm is most likely read-only. This way we could have business owners setup to edit the content on the site and have it published through a proper approval and content deployed process.  The environment we should be aiming for should look something like this:

 

 

2. Looks and feels: Personally, I don’t think you need to be a SharePoint expert to design your internet site. SharePoint is build on top of ASP.NET 2.0, so basically, whatever you can design in an ASP.NET website, you can always implement it in SharePoint (just a matter of money and effort. ) Therefore, don’t confine your creativity at the first place just because it is a SharePoint site, you will be amazed at what SharePoint can do. However, it is always good to have an understanding of SharePoint, as it does have a few things special. Heather Soloman’s blog is a good place to check out.

·         Design:

Tools: I am using Microsoft Expression Web for prototyping.  It is so cool.

               A couple of things need to take consideration when you are prototyping

Ø  SharePoint OOTB Controls:  what SharePoint interface features do you want to keep in the new design? Like breadcrumb, welcome menu, site action, page titles, site titles, page images, navigation menus, etc. Make sure your master page still incorporate these items even though you are not going to implement them.

Ø  Navigation:  Do you want top bar navigation, left/right hand side navigation? Do you want to modify the SharePoint OOTB navigation control or do you want to create your own custom user control? You may want to check this site

Ø  Toolbar: there are several toolbars used in SharePoint on various screens, plus form field background

Ø  Content areas: page layout, web part zones etc.

·         Implementation

Tools:  SharePoint Designer

The bulk of the customization and branding was done in a master page. You can either start from the minimal master page or OOTB blueband/blackband master page. I don’t recommend start with default. master as you will get more kudos for the road less travelled.

 

To make your SharePoint site not look so SharePointy, CSS is the key .All the looks and feels are controlled by CSS. You do need to be good at CSS or at least have one CSS expert on your team.  There are 26 OOTB CSS files shipped with SharePoint. However, you don’t need to know all of them, but it is important that you understand the mechanism of how Core.css works with SharePoint. Here is a blog give a detailed explanation of how CSS works with master page.

 

3. Usability: Like an old saying said: if you don’t know what your destination is, it doesn’t matter if you take a bus or take a taxi.  Designing a website, you need to know who your audience is. As a technical person, we tend to design the web site to show off the best technologies instead of paying attention to the end user. For example, if the Internet site is built for government, then accessibility is the priority. You may want to give up Silverlight or flash etc and try to keep the site neat and clean. Make sure you take your end user into consideration when you make decision of what technology to use; what the site will be look like? Keep in mind that technology is meant to adjust to people’s need, not the opposite. Make sure you work closely with your customer on the Information Architecture and Taxonomy.

Well, have to stop here. Shopping time now, don’t want to miss Myer’s midyear sale. I will continue this in part 2, talking about deployment and packaging.

 

 

 

 

 

 

Silverlighting with SharePoint

Silverlight is so cool. I can forsee a great future of building RIA for the next generation using Silverlight, especially in Sharepoint. As we all know, sharepoint looks and feels is very sharepointy. It takes great effort to “sexy it up”. Integration with Silverlight will be a good potential solution, specially in BI area such as dashboard. Microsoft is really pushing it as well. They provide “Silverlight for SharePoint BluePrint” with six demo samples to get you a jump start. I have been playing with it last couple of weeks. Honestly, the configuration is not easy, but it worth the effort! I normally don’t want to get too technical in my blog, but this time is exception. Here is the detailed checklist to configure your SharePoint environment to run silverlight webpart.

Assumption:

• We are using Silverlight 2 beta 1 instead of Silverlight 1
• Have a read on my good friend Patrick’s blog. He has also a step to step configuration guide on that. It is really helpful.

Enviroment requirement:

• WSS 3.0 + SP1 or MOSS 2007 + SP1
• VS 2008 or VS2005 + .NET 3.5
• ASP.NET 2.0 AJAX Extension 1.0
• Microsoft Silverlight Tools Beta 1 for VS 2008. This download will also automately install Silverlight 2 Beta 1, Silverlight 2 SDK Beta 1 and KB949325 for VS 2008 for you. Make sure you uninstall all the previous silverlight versions before you install this one
• Drag system.web. silverlight.dll into GAC after the installation

Configuration:

• Change the web.config (Follow legendary Patrick’s screencast). Besides that, you need to add an extra safe control in the web. config in order to run the script manager if AJAX technology has been used (Like Navigation Control Demo in the blue print)

<SafeControl Assembly=”System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ Namespace=”System.Web.UI” TypeName=”*” Safe=”True” />

•  Register .xap extension as a MIME type (application/x-silverliget-2-b1) for IIS (This one also demostrates in Patrick’s screencast)
• If the web part is blank, recompile the project which will automatically produce a solution file. The new .xap file normally 2k bigger than the old one. Repalce the new .xap file for the old ones (Intpub/wss/virtual directory/site name/clientbin and Intpub/development/)
• By the way, if you are trying to make the navigation control work, you will get a error message saying unable to load the assembly SL.Controls.Navigation.Dll. Don’t panick, as this is because the assembly’s publich key token is wrong.  All you need to do is:

1. open the blueprint.master. 
2. Locate the line <%@ Register TagPrefix = “SL” Namespace = “SL.Controls.Navigation” Assembly=”SL.Controls.Navigation, Version=1.0.0.0, Culture = neutral, PublicKeyToken=”4aec304184eb9a69″%>.
3. Change the PublicKeyToken 4aec304184eb9a69 to bb99f30c0098259c.

Then it goes live!!!!

Although silverlight has some drawbacks and not very mature and stable at this stage, remeber it only starts and has a long but very promising future ahead of it.  Microsoft is putting a lot of effort on improving it. Give it a go and you will love it!

Say no to SharePoint Customization

I am going to start this controversial article to my blog. The purpose of this article is to provide some reflections on the adoption and utilization of SharePoint in the organzation. Patrick Tisseghem mentioned “SharePoint is about build or buy” in his famous blog “SharePoint is not a holy grail“. Well, I quite agree with that as SharePoint is not a solution for everything. It is how you apply it in order to aid you in the solution. However, from my own experience, SharePoint development experience isn’t as friction-free as it could be. Therefore, my formula is simple:  Effective sharepoint solution = OOTB SharePoint + third party tools + minimal customization. Yes, if you still think you need heavy customization after leveraging OOTB SharePoint and evaluate the existing off the shelf sharepoint application, then forget about Sharepoint

1. Customizing SharePoint costs money and takes time. I am sure any .NET developers can skill up and be productive and happy working with SharePoint, but it takes time. There is a steep learning curve and new development conceptes to adjust. The current situation is people pay $XXX for SharePoint Developers and they still can’t get decent ones. Oh, don’t forget these PM/business owners who have been nurtured in SharePoint OOTB syndrome, they won’t be happy to see developers spending too much time on learning and training.

2. Poor supportability.To say SharePoint is a development platform, well, it is partially true. It is a development platform for Microsoft and its partners. It should be a product for the ordinary companies who wish to use SharePoint to solve their daily problems. Why? First of all, customized SP is hard to support. You get some funky contractors write some funky custom code and after a couple of months something goes wrong and their successors have to dig into these code to investigate what is going on. Secondly, Microsoft has three year dev cycle for SharePoint. You will expecting your application to upgrade with Microsoft’s new release. But remember, Microsoft doesn’t support custom code. You messed up, bad luck.
3. There are a lot of community supports for SharePoint, but looks like most people is still learning the concepts and exploraing the best practises. Again, a good place to go maybe Codeplex. It has a lot of community tools. It is free and it has version controls as well. At least it will give you some code block to start with for customization. But, like I say, they are community tools, so don’t be too fuzzy.

Looking forward, we are expecting Microsoft and its partners to develop more useful web parts and features just like what they do in MOSS 2007. And organizations only need to subscribe to what they need and configure it according to business requirements.