How to prevent your SharePoint implementation from failing

December 5, 2012

Rupert Murdoch once said, “The world is changing very fast. Big will not beat small anymore. It will be the fast beating the slow.” If you believe that statement, being able to deliver products and services faster becomes exceptionally important.

However, a fast delivery of your products and services is only possible if your business is efficient and productive. A lack of productivity can have a big impact on your business, and an increase in costs is one of the most common effects. Down the track, you also run the risk of losing customers.

One important element to improving your productivity is effective collaboration. Experts agree that when we collaborate well, speed goes up and costs come down. Improving collaboration and teamwork within your organisation breaks down the barriers that create information silos and inefficiencies. Not only do you need to collaborate with team members, but also with customers, suppliers and stakeholders.

To improve collaboration, and as a result productivity, companies seek help from SharePoint, one of the fastest-growing server products in Microsoft’s history. But due to a lack of understanding of the package, many organisations become overwhelmed with the software and give up, declaring that the problem is with SharePoint. They simply fail to grasp everything that SharePoint has to offer. Many organisations think that they can just install the product and start using it, like any other piece of Microsoft software. But SharePoint isn’t just another piece of software; it is a fully featured business collaboration platform that fulfils a variety of business needs within an organisation.

It used to be that as soon as an organisation installed SAP, that was it, because “SAP can do everything” or so highly-paid SAP consultants would like us to believe. The reality is that SAP and many other ERP systems are often not friendly pieces of software. Many do not support collaboration well; if at all. They do not provide a user experience that underpins the culture that organisations are trying to build.

SharePoint is a very popular product in the Enterprise space. While it is a web-based platform, it has a user interface that is different to most web-based applications you may have previously used. That’s because it’s comprehensive, with some complicated but strategically-advantageous functionality. Have no doubts about it, it is likely that staff will need to be provided with some training to be able to do more than just use the document management features. This alone has been a point that some organisations cannot get past. Sure, there’s some overheads associated with SharePoint, but the benefits and return on investment outweigh those overheads significantly. So what exactly goes wrong with organisations that have a bad experience with SharePoint? Here are a few common problems that we see:

1. Lack of planning

2. A failure to recognise that the investment in SharePoint doesn’t stop the moment you purchase the software

3. A failure to accept that new user interface paradigms are necessary to achieve many tasks, some of which are quite complicated

4. Giving up because the first attempt, or a previous edition, was a failure

5. A failure to recognise that staff may need to be trained to use many of the features that support collaboration

6. A failure to invest in the right skills, whether you train people in-house, hire people that are already skilled, or hire outside consultants

7. Failure to invest in creating the right Information architecture for your organisation

8. Failure to use it for anything other than document management

9. Failure to use the workflow functionality

10. Failure to create team sites, allowing individual blogging on various topics of interest within the business

11. Failure to invest in maintenance

Much of this falls within the scope of corporate governance. While both small and large organisations will benefit from support with SharePoint implementation, in particular it’s large organisations with multiple branches and thousands of people that require a clear management process for SharePoint deployment.

SharePoint is a great tool to improve collaboration and productivity within your organisation, but to reap the full benefits its complexity should not be underestimated.


Sharepoint, AjaxControlToolkit, ModalPopup and DocType problems

May 4, 2009

I am currently integrating a Sharepoint web site with an ASP.Net web site. A Sharepoint web site is essentially an ASP.Net web site too, and Microsoft have provided a way to integrate exiting web sites into that, essentially by inheriting a Sharepoint master page.

My ASP.Net web site uses the AjaxControlToolkit. The problem is, the AjaxControlToolkit by default uses the XHTML DocType. Sharepoint doesn’t actually have a DocType specified, which means it defaults to HTML 4.0 transitional. That mode is ok. There are a number of reasons why you might want to use HTML 4.0 transitional. Most of the component libraries out there still use the old DocTypes because they offered a richer set of functionality. Recently I used the Intersoft control suite. These operates very strangely under  XHTML, and in fact they don’t support that mode.

But back to Sharepoint and the AjaxControlToolkit. I was trying to use the modal popup extender, so that I can have one of my forms displayed on clicking a button on the page. Without the DocType of XHTML, every time I clicked on the button, it would display the bottom-right hand corner of the dialog in the upper left-hand corner of my form, effectively clipping the control and making the control otherwise useless.

There are workarounds. You can go into the Modal Popup Extender and set the X and Y co-ordinates. The problem with that is that often you don’t know the exact co-ordinates where you want the popup to be displayed. Part of the desire to use the modal popup is because it centres on the page and will move with the page when you scroll. It also repositions itself when you adjust the form.

The answer to this is to obtain a re-write of the getClientBounds javascript function that goes into the AjaxControlToolkit source code, common.js file. This re-write may be obtained from here: http://forums.asp.net/t/1002123.aspx?PageIndex=1 and was put together by Umer Farooq of Islamabad.

Here it is repeated below:


getClientBounds : function() {
        /// <summary>
        /// Gets the width and height of the browser client window (excluding scrollbars)
        /// </summary>
        /// <returns type="Sys.UI.Bounds">
        /// Browser's client width and height
        /// </returns>

        var clientWidth;
        var clientHeight;
        switch(Sys.Browser.agent) {
            case Sys.Browser.InternetExplorer:
                if (document.documentElement && document.documentElement.clientWidth)
                    clientWidth = document.documentElement.clientWidth;
                else if (document.body)
                    clientWidth = document.body.clientWidth;
                //clientWidth = document.documentElement.clientWidth;
                if (document.documentElement && document.documentElement.clientHeight)
                    clientHeight = document.documentElement.clientHeight;
                else if (document.body)
                    clientHeight = document.body.clientHeight;
                //clientHeight = document.documentElement.clientHeight;               
                break;
            case Sys.Browser.Safari:
                clientWidth = window.innerWidth;
                clientHeight = window.innerHeight;
                break;
            case Sys.Browser.Opera:
                clientWidth = Math.min(window.innerWidth, document.body.clientWidth);
                clientHeight = Math.min(window.innerHeight, document.body.clientHeight);
                break;
            default:  // Sys.Browser.Firefox, etc.
                clientWidth = Math.min(window.innerWidth, document.documentElement.clientWidth);
                clientHeight = Math.min(window.innerHeight, document.documentElement.clientHeight);
                break;
        }
        return new Sys.UI.Bounds(0, 0, clientWidth, clientHeight);
    },

Basically, it works by detecting various instances of objects on the client in the Internet Explorer part of th code. If XHTML is present, document.documentElement.clientWidth exists, otherwise it will use the default document.body.clientWidth.

There is a second issue, that is to do with the positioning of the modal background. Basically, because the modal popup defaults to position:fixed, the background positions itself within the content part of the page. This is not desirable, as we want it to make the entire page inoperable while our dialog is showing. I actually don’t like the use of position:fixed, because it is unavailable in IE6. To solve this problem, simply find references to ‘fixed’ in the ModalPopupBehavior.js file in the AjaxControlToolkit and change them to ‘absolute’. You might want to alter the left and top values for the background element in this file too. I changed mine from zero (0) to minus 1 (-1).