SharePoint Dev Tips & Tricks

Speaking at SharePoint Connections, and the MN SharePoint User Group

Phil Wicklund — Thu, 25 Sep 2008 14:04:00 GMT

Great news! I was just informed that I'll be speaking at next March's SharePoint Connections conference in Orlando Florida. I missed the deadline for November's conference in Vegas, but I am very pleased & excited that I was able to get my ideas submitted in time, and chosen, for March's conference. Plus, Minnesota spring weather is nasty and sloppy; what better place to go to than Orlando! Here are the topics I'm presenting on:

How to Effectively Manage your SharePoint Customizations, Deployments, and Environments with Solution Packages, Source Control, and Solid Governance
How to Build a "Hello World" SilverLight Web Part for a SharePoint Site in 10 Easy Steps
Development Ideas on how to make your SharePoint environment more SOX or HIPPA compliant

Connections Site:
http://www.devconnections.com/

Event Logistics:
March 21^st – 26^th, 2009
Orlando, Florida

Also, if March is too far away – I'll be speaking again at the Minnesota SharePoint User Group (MS Office Developer's Interest Group - MODIG) on October 28^th. I'll be talking about Code Access Security: what it is, why you care, and how to use it (this is both a developer and administrator topic). Time permitting; I'll build a workflow with visual studio, since a lot of people at our last group expressed interest in that topic as well. Thanks to Neil Iverson from Inetium for offering me a gracious welcome at the last MODIG, and for his offer to come back to speak again at the next meeting! It'll be a good time – and the pizza never fails to satisfy J

MODIG Site:
http://www.sharepointmn.com/modig/default.aspx

Event Logistics:
Tuesday October 28th
5:30 pm

Driving Directions

Talk to you then!

Phil

[this post was cross-posted from http://philwicklund.com]

The SharePoint Product Manager: Get Yourself a Pit Bull

Phil Wicklund — Mon, 15 Sep 2008 09:05:00 GMT

Every SharePoint deployment needs clear leadership and accountability in order to be "successful". Success is a loose term with SharePoint, but I like to define it as follows: A state in which the SharePoint deployment has continued to provide tangible business value over a long period of time, with minimal cost and maximum corporate adoption.

There are a lot of obstacles that hinder achieving this status of "success". Obstacles like ballooning cost, lack of compelling features, and lack of company adoption. You may start off with a bang, but find it harder and harder to keep the momentum up as time goes by. I've seen this so called stagnation in few companies, and I've really come to appreciate the role of Product Manger because of it. I've seen some companies that spin up a SharePoint site, and almost haphazardly put it on cruise control and expect great things to happen. The problem with this is that if it isn't someone's job to make things happen, nothing will happen and your initial "momentum" will come to a halt. Now, before you think I'm trying to make a sweeping statement here, even if you have a great Product Manager but don't have a budget, or executive by-in, you're going to have a hard time. However, there's a lot this person can and should be doing.

[this post was cross-posted from http://philwicklund.com]

What to do when your DLL needs to be in the GAC…

Phil Wicklund — Mon, 15 Sep 2008 09:02:00 GMT

Code Access Security (CAS) is a hot topic these days, and for good reasons. CAS is an important thing to have an understanding of if you work in a security conscious company, or if you're striving to understand best practices. If you're new to CAS, there are many articles, but I like to describe it with an analogy that we all can identify with. Think of "User Access Security". It's not a coined phrase like CAS is, but essentially it is a conglomerate of rules and measures that enable a given user or person the ability to do something on their computer/network/domain. CAS is the same thing, except with code. If we say John Doe user doesn't have access to crawl files in a sensitive network share, why would we say that third party DLLs (code) can? CAS says "this code can only do X, and nothing more" – much like "John Doe can only do X, and nothing more". CAS is just as important as user access security.

[this post was cross-posted from http://philwicklund.com]

Consolidating Master Pages Customized By SharePoint Designer

Phil Wicklund — Mon, 08 Sep 2008 16:44:00 GMT

I hate Designer for SharePoint Master page development. My biggest issue is that after you start customizing master pages with Designer, 6-12 months later you realize you have a huge mess on your hands. You end up maintaining hundreds of copies of the same file. Say you need to make a minor change to a master page, you'd have to go back and crack open every site, one at a time. This could take hours. Also, you may not even know the places that need the change, or you think you changed them all, but turns out you missed some. Designer means inconsistency and costliness in the long run.

So, off the soap box, what if you're down this road and want to get back to a better practice? Here are the steps:

[this post was cross posted from http://philwicklund.com]

A Picture is worth 1,000 Words: Achieving Good SharePoint Usability

Phil Wicklund — Fri, 22 Aug 2008 16:47:00 GMT

One common situation I see with many clients I interact with is that their SharePoint sites are loaded down with wordiness. It's my opinion that sites that are overly wordy can kill usability fast, and it seems to me that SharePoint lends itself easily to be an extremely wordy application. This to me is the biggest issue that faces the SharePoint user interface (UI). Why don't people like SharePoint's UI? Too Wordy!

When you start dragging those ListViewWebParts on your pages, you quickly become a very textual site. For example, a few months ago I wrote a blog post about implementing a better Announcements web part because the one that comes out of box is SOOOO wordy and takes up a ton of real estate. See below:

Out of box look and feel:

Customized Look and Feel:

I think the difference is striking. The out of box one is so wordy, you don't know where to start, whereas the bottom is clear and articulate, allowing for the user to quickly scan through the information. Most of the out of box SharePoint web parts are overly wordy like this in my opinion, that is why I suggest you don't clutter your pages with too many web parts! This is especially true for things like calendars, documents, and discussion boards. As soon as you start dropping those on the page, end users are lost in a wordy mess and will have a harder time finding information. The trick is that you NEED to make it EASY for them to find stuff.

Instead, I suggest a approach that leverages the left navigation to drive users to content, especially for calendars, documents, and discussion boards and other built in lists/libraries. Those three especially should never be on main landing pages. Rather, link the user straight to the library or list itself. The user is less likely to glaze over information because there's only one type of information on the page and that makes it easier to know what they are looking at.

Another big area that people need to pay attention to is using graphics, not words, to drive users to the main areas of the site. Like I said earlier, people glaze over text and it is rarely ever even read! So don't rely on it! However, people's eyes connect well with graphics, which draw their attention much more easily. Use graphics, not words to drive navigation and highlight main areas/features of your sites.

The image below features a site I put together for a company (logo and name of company removed) that uses graphics to help drive end users to the main areas of the site. Rather than cram a ton of info on one page, I'm using the left nav to link to all the activities and content, as well as using graphics in the main area to call out "featured activities". This is a much more usable approach because users are drawn to the graphics to tell them what they can do, and are not bogged down with a wordy page that they won't read (in which case they'll feel lost and get mad).

(click image for full size)

With just a few seconds of looking, a user can quickly identify the value of the site and what they can do with it. If you have an overly wordy and overly crowded SharePoint site, it won't be used or adopted, and it will leave a bad taste in your end user's mouths. This is because they can't quickly find what they want and they give up. Do you remember what first attracted people to Google, amidst notable competition? Less is more.

I believe the same is true for your SharePoint sites. However, that is "just my 2 cents" J.

Phil

[this post was cross-posted from http://philwicklund.com]

Displaying SQL Data in SharePoint? DataFormWebPart vs. SPGridView

Phil Wicklund — Fri, 15 Aug 2008 16:46:00 GMT

When it comes to displaying SQL data (really any data set), there are two main approaches to take to get that data in your SharePoint Sites. The first is the SPGridView, and the Second is the DataFormWebPart. Both approaches have very clear strengths and weaknesses, and this is what I intend to discuss in this post. Here's a summary of my findings (otherwise click here to view the full article):

DataFormWebPart

Advantages

Very Flexible Presentation – With XSL you can do almost anything. The base GridView control, conversely, is rather limited in how the DataSet that is bound to the control can be rendered. With a DataFormWebPart, all that data comes back as XML and can be transformed any way you like. See the Approaches in Action section to view some examples.
Sorting, Filtering, and Grouping with the DataFormWebPart is a no-brainer, it is all done for you, automatically! The only drawback is that it forces a post back, so if your requirements need AJAX, you're out of luck.

Disadvantages

A lot of overhead required to get a DataFormWebPart to connect to a SQL resource. However, this "overhead" is about the same as the other approach, so it is more of a mute point. I point it out though, just to say it is not your typical SharePoint Designer experience that you may be used to.
No debugging. You can't debug XSL (step through XSL), so this leaves you needing to take the Pac-Man approach to development. Build a little. Test a lot. Rinse, lather, and repeat.

Main Business Driver

Your usability requirements will usually cause you to choose the DataFormWebPart over the SPGridView. The XSL is INCREDIBLY flexible, allowing you to do all kinds of cool things that you may not be able to do with a GridView control, for example.

SPGridView

Advantages

Familiarity. Most people are familiar with how to use a GridView, so it wouldn't take much to upgrade to an SPGridView.
Typical debugging experience. You debug the SPGridView just like you would any .NET code. This is a BIG advantage over the DataFormWebPart.

Disadvantages

Not a very flexible user interface. If you have complicated usability requirements or UI Mock-ups, the SPGridView may not be flexible enough for you.
A lot more overhead is required for sorting, filtering, and grouping, whereas the DataFormWebPart is seamless in this regard.

Main Business Driver

The relative ease of use of a SPGridView is a large bonus, and what is even bigger is the ability to debug and step through your code. People without a lot of XSL experience will want to go this route as well.

READ FULL POST...

[this post was cross-posted from http://philwicklund.com]

Business Intelligence webparts via Dundas OLAP Services

Phil Wicklund — Thu, 07 Aug 2008 13:40:00 GMT

Hey All! I’ve been REALLY heads down lately, putting in big hours at a company, and I haven’t had much free time to blog over the past couple weeks. Sorry for that! However, I’ve been keeping busy with some really cool stuff!

I’m on a Business Intelligence (BI) project right now, and I’m writing some web parts that present data via Dundas OLAP Services from some SQL Analysis Services cubes. Tangent – BI work rocks! It’s been my most fun project to work on, to date!

Here are some screen shots of my web parts:

Dundas is a great tool to leverage. They have inherit SharePoint web parts, right out of box. Unfortunately, my business requirements were too complicated to leverage these, but they also publish the base OLAP services charting that can be leveraged programmatically via any ASP.NET application. In my case, I simply dropped the Dundas chart on a CONTROL TEMPLATE, and loaded that template via my web part. So easy! Notice the red box, you can load many reports into one chart, and the end users can toggle between them. Also, you through that toolbar, the end user can toggle chart colors as well as chart type (bar, line, area, etc.). Very slick indeed.

Here’s a sample of some averages plotted with a column chart:

What’s REALLY SWEET is that you can drill into the data. For example, if you click on a date or a column, you can see how that metric is composed. For me, when the user clicks the column, they get an hourly breakdown for that day’s data (it’s in military time – gotta fix that J):

So, to summarize, Microsoft is getting it right with the track they’re taking on business intelligence – and I totally see why they bought out Dundas, it’s an impressive tool!

Good luck!

Phil

[cross posted from http://philwicklund.com]

Governance Strategy for SharePoint Development

Phil Wicklund — Mon, 21 Jul 2008 12:00:00 GMT

I'm a big fan of delegation and accountability when it comes to governance strategies, and the SharePoint development lifecycle stands for no exception. If any of you remember, I lead a large SharePoint team at a fortune 500 company for a few years, and I have some battle wounds to prove it. Fortunately for me, the IT department had great senior management, who valued environment isolation which saved us a lot of pain in the end, and I was able to glean some great wisdom from their experiences. However, looking back to those days I can't help but to wish I had done a few things differently. I can't help but to think that more accountability and even more environment isolation would've been a great asset to us, despite what could've been perceived as an inconvenience.

Many companies I see don't even have a development lifecycle governance plan, and those that do typically structure it so that Production servers are locked down, but everything else is fair game. Developers, testers, business analysts, and all their moms are all poking around in the various environments and before you know it, you have a mess to clean up and you're always crossing your fingers when you make a production change. I definitely know from experience that when I was working in a test environment, I would often get frustrated because my web front end's configurations are not consistent and didn't know why, or something was working a few days ago, but for some reason it is not now. The of the root problem always goes back to there are just "too many hens in the kitchen". You can spend a lot of wasted time fighting fires in environments, and a little more governance can save you a lot of money when you think of how much that time is costing you.

The figure below is my White Ivory Tower model of how I would structure the deployment process in a medium or large server farm. Much of this article isn't necessary SharePoint specific, but I am often surprised as how often people ask me how I would go about this, so it seemed like a relevant "brain dump" for a SharePoint blog nevertheless.

You'll notice the three recommended farms for any one production farm, as well as the different "gates" where I will later be describing the roles of the different gate keepers and how those individuals will fit into the proposed governance model.

[this post was cross posted from http://philwicklund.com]

Application Pools and Memory Best Practices for SharePoint Front Ends

Phil Wicklund — Mon, 21 Jul 2008 11:57:00 GMT

Have you ever gotten an out of memory exception on your SharePoint web front ends and wondered why? Or how to prevent it? I started getting this error periodically, and through such experiences have drawn several conclusion on how to manage the memory on your SharePoint web front ends.

Best Practices:

1. Don't have too many Application Pools

2. Set Memory Capacities on Each App Pool

3. For serious traffic, plant a garden

Using Delegate Controls to Implement Minor Brand Variations in SharePoint

Phil Wicklund — Fri, 11 Jul 2008 15:19:00 GMT

The Problem

A problem that I have often seen in the SharePoint world is the common request to have a consistent brand across your entire farm, but therein it is required to have minor variations of that brand for various sites within the farm. A frequent use case for this is the banner image/logo. Maybe the main landing page for the intranet has a certain logo, but as you start drilling into the sub-sites, the logo should change (or other brand variations). Logos for different departments like IT, HR, Sales, etc. are often requested. Now, typically inside the master page would the HTML image tags for these logos be found, however, it can be extremely cumbersome to maintain multiple instances of a given master page, especially when the differences between these master pages is small. Also, you as the developer may not know when when/where these variations need to be implemented, thus you need something intuitive for end users to be able to customize the look and feel of these sites. So what other options are available to you when you need these small brand variations in your SharePoint sites?

The Solution

A good solution for this is the use of delegate controls. You can place these controls within your master page, and at design time (via activating/deactivating features), replace them with actual controls that live in the LAYOUTS directory. What will be demonstrated in this post is using a feature to toggle the banner image on the SharePoint Site.