If you have tried saving a Visio 2010 drawing as a web page and then displaying it in a Page Viewer web part in SharePoint then you will know that by default hyperlinks in the drawing will no longer work.

This is because the default output format for Visio 2010 drawings being saved as a web page is XAML. When you save the drawing as a web page a collection of files are generated one of which is called xaml_1.js. Opening the Visio drawing .htm file directly in the browser works as expected and hyperlinks are active. However, if you try to display the Visio drawing inside a Page Viewer web part you will see a JavaScript error that references the xaml_1.js file seemingly because there is conflict with DOM elements that exist in the standard SharePoint page.

I suspect that this didn't receive much attention during testing by Microsoft as the assumption could be that if you are using Visio 2010 you will also be using SharePoint 2010 and Visio Services to display your Visio drawings in the browser.

There is a way to work around this by changing the output format of Visio to VML (Vector Markup Language) instead of XAML. Unless you choose VML the first time you save as a web page then Visio remebers the XAML default and there is no setting in Visio (that I can find!) that allows you to change this default. The only option left is to crack open the registry and go searching for the relevant setting.

Open regedit and go to - HKEY_CURRENT_USER -> Software -> Microsoft -> Office -> 14.0 -> Visio -> Solution -> SaveAsWeb -> Settings then change "priformat" from XAML to VML

Save your Visio drawing as a web page again and this time it will be produced using the VML format which does not include the xaml_1.js file that causes the error and prevents links from working.

When you add the link to a Page Viewer you should now have working links.

SharePoint is a huge product with plenty of opportunities to make mistakes in lots of different ways. The infrastructure could be configured badly, the business may not have clearly defined what they hope to achieve with SharePoint or the information architecture is allowed to sprawl out of control.

Having worked with SharePoint for over 7 years there is one mistake that I see being repeated over and over again when SharePoint is introduced into an organisation.

Imagine the scene, SharePoint has just been installed and in this case the business do have a clear idea of what they expect from SharePoint. The first priority is to move several small legacy systems including some spreadsheets and a couple of Access database applications onto SharePoint.

The justification for this is that moving these apps to the SharePoint platform will make them easier to find and share, they will immediately fall under the SharePoint backup and disaster recovery regimes and using SharePoint as the interface will provide a more consistent user experience across all of these apps. In addition to that the business has heard all about how rapidly small applications can be developed and deployed using SharePoint and are excited to see this process in action.

Back in the IT department the .Net developers have just come back from a weeks intensive training and naturally they want to make a good impression by demonstrating their newly acquired SharePoint knowledge and showing the business what a great platform SharePoint is.

The requirements to migrate several spreadsheet based apps start to roll in and the team begin by putting together a few quick prototypes. The decision is made to move the spreadsheet contents across into SharePoint lists to take advantage of functionality like views and to be able to apply approval workflows to items.

The users of the apps take a look at the protoypes and start to provide feedback. Requests include things like:

• Can a row be highlighted in red if some field drops below a specific number?
• Could a link be added to the view item form that takes us straight to a specific view?
• We don't always really like seeing the Alert Me functionality, can this be hidden for some of the lists but left on for others?

The developers know that technically they can do all of these things and they want to say yes to the business. This is a mistake.

It is a mistake for a couple of reasons. The business has been promised rapid application development by whoever sold them SharePoint. They may even have been told that this assumes you use as much out of the box functionality as possible and avoid code customisation if you can. Understandably, what they don't realise is that the things they are asking for are customisations that will require code to be written, tested, deployed and maintained.

It is up to the developers or IT managers to explain this to the business users and make it very clear whether what is being asked for is out of the box or whether it is a code based customisation.

Another reason it is a mistake is that the requests to turn off alerts or add links in unusual places are significant changes to the standard interface. One of the benefits of using SharePoint is that it provides a consistent platform and each change to that platform chips away at this consistency. The benefit of a consistent interface is that once a user has mastered one application or area of SharePoint they should be able to open any other SharePoint site and feel immediately at home. The changes mentioned may sound small but over time can build up to mean that some areas of SharePoint become almost unrecognisable. This will lead to an increase in support calls and training costs as users will be confused by these inconsistencies and ultimately this can hurt user adoption of the platform as a whole.

I'm not saying that you shouldn't use code based customisations or alter the user interface in any way but these customisations do come with an overhead that needs to be understood by the business. The danger is that if this is not clearly explained the original expectations of rapid application development and the benefits of a consistent platform are not met and the business starts to question whether these claims were ever true or even worse, whether any claim made about SharePoint is true!

An informed choice needs to be made by the business on a per application basis as to whether they are prepared to invest the extra time and effort to get an application that meets 100% of requirements. Or, decide that it is better to have something delivered far more rapidly that meets ~80% of the requirements and loses some of the nice to have elements. In addition, there also needs to be someone in the business taking an overall view of what customisations are acceptable across the platform to preserve interface consistency for the benefit of all applications.

This is clearly not an all or nothing choice and there is a sliding scale of just how much customisation the business is prepared to take on. Once people come to terms with and fully understand these choices and trade offs they usually feel much happier about SharePoint and the best way to deliver applications for their business. Ultimately SharePoint is about giving the business the tools to do a job in the most effective and efficient way possible and sometimes this means having to say no to some requirements.

What do you think? Is this something you have seen happening at companies you work with? Are there other mistakes that you see happening more frequently?

TSG is teaming up with SUGUK to present the next user group session in the north east.

Tony Hughes from Microsoft Partner TSG who will lead us through methods to exploit Sharepoint functionality in the small to medium Sharepoint Enterprise.
 
This session bridging the technical, development and business audience will be both interactive and enlightening.  It will cover how list enhancements in Sharepoint 2010 can be deployed to allow integrated data solutions,  dip into the exploitation of Excel to create Business Intelligence, show us how to take advantage of Key performance Indicators and dashboards in Sharepoint, delve into how we can use Sharepoint Designer to create valuable data views and step into the critical realm of document management to show the importance of and approaches to document Version Control and Approval Routing.

For more information and to sign up follow this link.

@joyknows has posed an interesting SharePoint question via Twitter -

What would you say are the primary strengths and weaknesses of OOTB customisation vs. SPD vs custom code?

This one is definitely going to take more than 140 characters so here goes...

Out of the box (OOTB) customisation allows any end user familiar with SharePoint to create sites, lists and web parts through the user interface to produce something that meets their specific requirements.

Strengths -

• Very quick to create customisations
• Anybody with basic SharePoint knowledge can do it
• Forces users to create solutions in a "SharePoint way" which encourages consistency

Weaknesses -

• Doesn't provide much flexibility - compromises have to be made with requirements
• If you want to repeat the same customisations again then options for recreating the solution are limited - manual repetition of creation steps or templates

SharePoint Designer (SPD) customisation allows power users to get a bit more creative and make use of some of the more advanced options in SharePoint such as custom workflows and connecting to differnt data sources.

Strengths -

• More options for customisation - will fulfill more of the original requirements
• Make changes to master pages and page layouts - create a completely new look and feel

Weaknesses -

• Difficult to deploy customisations made using SPD to other sites - eg. A custom workflow created in SPD is applied to a specific list and cannot be resused on another list. The only option is to manually recreate the workflow again for the next list.
• It is possible to do a lot of damage very quickly if put into untrained hands
• Once files are customised by SPD they cannot be changed by custom code

Custom code requires a SharePoint developer to write it but it is the most powerful option that opens up the full SharePoint API, web services and any other code you want to use to customise your solutions.

Strengths -

• Provides the most options for customisation
• Customisations can be packaged up as features that are easily deployed and reused in multiple solutions
• Deployment can be controlled and governed more easily as customisations can only be deployed by people with SharePoint admin permissions

Weaknesses -

• Requires a SharePoint developer
• Takes longer to achieve the same results

The above lists are a very brief summary of the pros and cons for each option. In reality it would be possible to have lengthy discussions about each but I think these lists provide a fair summary that should help as a primer for the more important discussion - which option should I choose?

As with most decisions like this the short answer is - it depends. In this case it depends largely on the trade off that you are prepared to make between speed of solution develoment and flexibility/meeting the original requrements exactly.

If you need something fast and are prepared to compromise by not meeting the original requirements 100% perfectly then OOTB is the way to go.

If, on the other hand, you need to have a solution that ticks off every requirement perfectly, that can be easily reproduced across lots of sites and you are prepared to wait a bit longer for delivery then custom code is the answer.

SharePoint Designer is a middle ground that combines the best and worst of all the options. In my opinion it should only be used to quickly prototype something that you later turn into a well packaged custom code solution or where you have to customise to meet a requirement but do not have SharePoint development resources available.

In the interests of full disclosure I am from a SharePoint development background and have also spent a significant amount of time working with SharePoint whilst being constrained to only using OOTB customisations. As a result I am not what I would describe as a typical SharePoint dev - ie. Reach for Visual Studio first and ask questions later!

This may sound like a betrayal of my SharePoint developer brothers and sisters but I would argue that custom code should only be used once you are sure that what is being asked for cannot be achieved using OOTB customisation. That may sound obvious but it is easy to take requirements on face value and assume that what the end user is asking for cannot be compromised on which makes it look as though custom code is the only option. In reality if the end user understands that they can have a solution that meets 80% of the requirements delivered in 2 days using OOTB or a solution that meets 100% of the the requirements in 10 days using custom code those requirements that were previously set in stone suddenly become a bit more flexible.

So in summary, and just to be clear so I don't get flamed by all the SharePoint devs, custom code is great. It provides the most number of customisation options that can be deployed to your SharePoint farm in a repeatable and controlled way. However, I would choose OOTB wherever possible in the interests of speed of delivery and productivity even if that means using your powers of persuasion to talk the end user into settling for a solution that doesn't tick off 100% of the original requirements but does meet the core ones, they will thank you in the end!

I have created a number of small utility console applications and web parts that are useful for quickly completing a few fairly common tasks - well if you are a SharePoint dev anyway. They are all fairly rough and ready but the project code can be downloaded from the link below if you want to make your own additions/improvements.

These applicatons all have the power to make lots of changes to your site collection very quickly so use them at your own risk - backup your site and always test them in a non-production environment first, you have been warned!

Download projects here

Modify Workflows

Update the properties on approval workflows. This is particularly useful for WCM sites where each subsite has it's own Pages library and workflow by default. This means that once you have a decent sized site collection hierarchy it could take a very long time to go through every site and change the workflows. This app allows you to quickly update properties such as whether users can change who the approver is when submitting a page for approval and whether a single task is assigned to a group. This is a console application so settings are changed through the app.config.

Uncustomize Files

Customized files are the plague of any SharePoint developer who wants to be able to update page layouts, master pages or any other file that makes up a SharePoint site. A customized file is a file that has been modified in SharePoint Designer and is therefore different to the original site definition file that was used when the site was created. A customized file stores it's customizations in SQL so the file on disk is no longer used which means your update of the file on disk is ignored. If you are wondering why your updates are not overwriting the files on your site then it is worth checking to see if the file has been customized. If it has then you will probably want to find out why and what the customization is and then maybe revert it to it's uncustomized state. The UncustomizeFiles console application allows you to do just that.

WCM Control Panel

Quite a grand title for something that at the moment only does two things - if anyone has any ideas for what else they would like to see on a WCM control panel please leave a comment. This web part will tell you how many pages there are in a WCM site collection, something I had hoped CQWP would do but unfortunately not (if anyone knows of a better OOB way of getting this information please let me know in the comments). It will also list out the number of pages in each individual subsite if you modify the web part settings.

The second function this web part has is to Update All Pages which simply checks out every page and then checks it back in then publishes and approves the page. This is a bit of a cheat for people who want to make their content look more up to date than it is for Internet sites where a last updated date is displayed on each page. In reality this is actually quite useful for launch day to be able to create the right impression for users - especially if you have had a particularly long content creation cycle before going live.

These projects can be downloaded here

Trying to open some pages in a SharePoint WCM site gave a 404 error.

A quick Google search led to this explanation but this was not the exact issue for me. In my case there was a reference to a user control .ascx file in the page layout that had not been deployed to the bin folder of the web application. Once this resource was deployed to the path the page layout expected to see it in the page loaded without a problem.

Update - another reason for this error is if your page layout has become customized. This will happen if you edit the page layout using SharePoint Designer.

I recently wrote a post that included a .wsp file. In the comments a reader asked for more information on how to deploy this to their SharePoint environment.

I suppose it is a sign that I have been developing SharePoint solutions for too long when I start to assume that this is basic knowledge that everybody has! To try and make amends for this assumption here is a quick guide to deploying a wsp using stsadm and central admin. The first part is generic to all .wsp solutions and the second part is specific to the deployment of a web part that has been added using a SharePoint solution.

First we need to use STSADM.exe to add the .wsp file to the SharePoint farm.

To find STSADM.exe navigate to the bin folder in the 12 hive - here C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

Open a command window and drag stsadm.exe onto it and use the following command to add the solution to the solution store.

stsadm -o addsolution -filename c:\solution.wsp

You can also use stsadm to deploy the solution but here I am going to describe the point and click method using SharePoint Central Admin which does the same thing.

Open SharePoint Central Admin and select the Operations tab.

Select Solution Management.

Click the link to the .wsp solution you just added.

Click Deploy Solution - If the solution is not globally deployed select the web applications you want to deploy to.

Click OK.

The solution is now deployed to the web applications you selected or to all web applications if it deployed globally. This is not the end of the deployment process though. If the solution contains a web part there are still a few steps to go before it will be displayed on your site. To add the web part to a page on your site do the following:

Navigate to the site collection where you want to place the web part and go to Site Settings and Site Collection Features (this assumes that the feature is scoped at the site collection level, sorry for making more assumptions that you understand scopes but that is another post and something that other people have already written plenty about if you want to find out more).

Activate the feature that contains the web part that has been deployed in the solution.

Next, go to Site Settings and Web Parts and click New.

Select the web part to add it to the wbe aprt gallery for that site collection.

The web part is now ready to be added to a page in the usual way - edit page, add web part to zone, browse to web part.

Hope that helps somebody...

** Update June 2010 - new Twitter web part using OAuth rather than Basic Auth **

When I mentioned that I was developing a Twitter web part to Mirjam van Olst she asked if it would be possible to work on it with me. So thanks to Mirjam, in the true spirit of international collaboration, we are now able to bring you an updated version of the web part which is more secure and easier to deploy.

Improvements include -

• The password input now uses a password textbox to protect the Twitter credentials
• TwitterLib.dll has been added to the wsp for easier deployment

Download the new and improved Dutch/British/Euro version here: TwitterPublicTimeline.wsp (24.25 kb)

** Update June 2010 - new Twitter web part using OAuth rather than Basic Auth **

Original post with deployment instructions

 The Twitter public timeline web part has now been updated with the following:

• URLs in Tweets are displayed as active links
• The user's screename links to their Twitter page
• If @screename appears in the Tweet it is displayed as a link to the user's Twitter page

TwitterPublicTimeline.wsp (24.25kb)

** Update June 2010 - new Twitter web part using OAuth rather than Basic Auth **

I thought I would have a go at creating a web part to display a Twitter public timeline within SharePoint. The reason for creating this web part is so that it can be used by project teams that are spread over several offices/countries to stay in touch and feel more connected without having to invest a lot of time emailing each other or talking on the phone. Twitter is ideal for this kind of light weight communication as it restricts the user to sending short, to the point messages.

Before starting I had a quick look on the web to see if I was reinventing the wheel. Michael Gannotti suggests this solution using javascript and the CEWP but I wanted something that we would have a little more control over in terms of html markup and branding and that wasn't limited to the CEWP being available. I also wanted to have the possibility of extending the web part to include other functionality in the future such as not just being able to display tweets but to also send them.

The web part is configurable using two custom attributes - username and password. This allows you to display any users public timeline assuming you have the password. To set it up for use with a project team public timeline you should create a Twitter account for the project and then follow the members of the team to see a timeline that displays tweets from each of the members. 

At the bottom of this post there are links to the .wsp file which can be deployed to SharePoint using stsadm.exe and a .css file so that you can see how I chose to style the web part but obviously you could brand it any way you want.

**Update by request - more detail on deploying solutions

My solution uses Twitterlib.dll which is an open source .Net wrapper for the Twitter API and was created by the developers at Witty. This is a link to the Witty project on Google code. 

Download the wsp for the Twitter web part: TwitterPublicTimeline.wsp (24 kb)

For a styling suggestion try this css: twitter.css (302.00 bytes)