Archive for the ‘SharePoint’ Category

Do you hate SharePoint? Part 4 of 4

If the answer is yes, could your hatred be caused by your local implementation? In this final post of our blog series we look at the last of four common problems with SharePoint implementations and how you can address them.

Once again, a huge thank you to Neil MacIsaac, SharePoint MCT, for putting this entire series together. Happy reading!

If you missed the earlier posts you can find them here

  1. Business Intelligence

This week we look at Business Intelligence.

4. Business Intelligence

Are there organizations out there that are really striving for Business Unintelligence? Wouldn’t everything that an organization does be in an effort to do something better? I love the term Business Intelligence (BI) mainly because of its massive overuse and its wide misunderstanding as ‘reporting’. So the question really becomes "How do we maximize our BI?" First, it is important to understand what BI really is. It is about making better decisions. If we have better data, and a better understanding of our data, it would be logical to conclude we would make better decisions right? Not necessarily. The theory is correct, but in practice most organizations fail to implement this properly by not focusing on the decision that they are trying to improve and instead only achieve in bombarding their key decision makers with an avalanche of reports. What is also surprising is that most of the decision makers in an organization are probably the ones asking for the reports in the first place. Let me give you an example. In a sales based business, you might see some monthly sales figures like this (overly simplified for the sake of discussion)

Sales Member

Monthly Sales (Units)

John

5,437

Mary

8,350

Bob

3,043

Jim

7,410

Why do we need to see these sales figures? The typical answer you will get will be "Because I need to know if there are any problems and to see if we are doing better or worse than last month or last year." So, with the above numbers, where is the problem? Most people would focus on Bob because his numbers are lower than the others. What isn’t shown with these numbers is that Bob is the newest of team and manages the smallest sales area. Can you still spot where the problem is in the above sales numbers? The typical failure in implementing a BI solution within SharePoint is usually in the disregard for a proper BI solution that focuses on those key decisions which strives to achieve a better decision by supplying as much data around the factors and drivers of the data as the data itself. Instead we see fancier reports of the above sales table and hope that our decision makers will ‘figure it out’. Another interesting point concerning SharePoint and BI integration is the potential for SharePoint to implement the decision. If our BI solution is focused on key decisions, a good solution should allow the user to implement the decision as quickly and easily as possible.

Conclusion

As you can see, SharePoint offers many challenges when deployed into an organization and requires due diligence to maximize your return. I hope that some of my tips may make their way into your organization and perhaps save you from some of the common pitfalls that have trapped others. There is good reason why SharePoint has become as popular as it has and hopefully you will be better able to get the most out of your implementation.

Advertisements

Do you hate SharePoint? Part 3 of 4

If the answer is yes, could your hatred be caused by your local implementation? In this blog series we look at four common problems with SharePoint implementations and how you can address them.

We continue our series by Neil McIsaac, SharePoint MCT, for putting this together. Happy reading! If you missed it you can still read Part 1 and Part 2 of the series

SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.

Why hate it?

It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:

SharePoint will amplify your problems.

So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;

  1. Information Security
  2. Business Intelligence

This week we look at Information Security.

3. Information Security

SharePoint has a confusing security architecture. A friend of mine continually jokes that you can do anything in SharePoint, as long as you know the 6 strategically placed security settings you need to set to allow users to interact with your content. I like to keep things simple. I always start addressing security by asking these 3 basic questions;

What are the requirements?

This question is pretty straight forward and we do it relatively well. Who gets access, and who doesn’t.

How do we know we meet the security requirements?

This is one area where SharePoint poses some difficulty, since it lacks any worthwhile reporting tools and has enough security layers that are hidden in the UI that it feels like finding an answer to this question is akin to finding the meaning of life itself. Paired with the products inability to properly handle security inheritance and the lack of a proper method to deny permissions and you are on a never ending hunt for individualized permissions. Yuck. Unfortunately the best security reporting tools are third party. Your team needs to sit down and address how your organization will address security reporting and auditing.

When is the last time we checked?

Security audits are often checked at implementation, but rarely checked afterwards. Permission elevation happens for various reasons such as troubleshooting, making it necessary to schedule our audits. If running an audit is painful because we haven’t properly addressed the above question, then scheduling it will hurt that much more. Again, get a good security tool.

Information Security Tips

Here are a few tips on implementing security in SharePoint to help make things a little more manageable.

Libraries/Lists are for security

I am not a fan of the Shared Documents Library which comes as a default. If you have ever heard me talk on the subject, you know I get a bit worked up about it. I am a fan of lists/libraries in SharePoint and I completely understand Microsoft’s position in adding it. It was a necessary evil. The problem that I have with it is what most people put in it. It goes against pretty much every information management principal that we have. Many organizations use this library and why not? It says "Shared" and I want to share my stuff, so why not? The reasons are many, but at a simple level, you will end up with a folder structure that mimics your old file shares, and make it work by placing individual permissions on folders and files to compensate for your lack of proper architecture. If you think of lists and libraries as containers, which if you were paying attention in the previous blog post when I ranted about the importance of structure, you can shape these containers to better store its information. You can change the shape (think ‘content types’), and you can change the behaviour (think ‘workflows’ and ‘views’) to better aid the end user in the task they have at hand (think ‘Use Cases’). Coming back to permissions, if we have a container with similar information in it, we can control permissions to all of its content by controlling permissions to the container. In other words, permissions in SharePoint are best handled at the list and library level and not at the folder or file/item level. Which brings me to a solid point: If you are not sure how many libraries you should have, look at the common permissions to your content. If a group of people need read access to one type of content but not to another type of content, then the content should be in the same list/library and we can control permissions to the content by setting the permissions once on the list or library. So how many lists or libraries should you have? The answer is in how many groups of content with the same permissions you have. This is not always the answer, but it is a good starting point.

Use SharePoint groups as functional roles

SharePoint groups are best used to reflect functionality rather than entity. Since we typically use Active Directory groups, adding the AD groups to our SharePoint groups to reflect the same group would be redundant. For example, having a Sales group in AD, which we mimic and create a Sales group in SharePoint usually offers little benefit. Having a group in SharePoint that reflects their ability is preferred. For example, I can create a group in SharePoint called Sales Lead Generators that can better reflect what anyone in that group can ‘do’ rather than who they are. Not only does it simplify security administration, it makes audit reporting a lot easier to read and verify.

Use Information Rights Management

Information Rights Management has been around for some time now. Surprisingly, most organizations that want to secure documents rely on securing the folder or physical media where the file is stored. The problem is that this security simply doesn’t follow the document where ever it goes. IRM on the other hand, does! You just have to ask someone if their documents are just as secure after an employee that has proper permissions to the file copies it to a thumb drive, or inadvertently emails it to the wrong person. SharePoint and IRM integrate very well. You can check out more about IRM here.

Next week, part 4 business intelligence…

Do you hate SharePoint? Part 2 of 4

If the answer is yes, could your hatred be caused by your local implementation? In this second part of our blog series we continue to explore four common problems with SharePoint implementations and how you can address them.

Once again, a huge thank you to Neil McIsaac, SharePoint MCT, for putting this together. Happy reading! If you missed Part 1 – Information Management, you can read it here

SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.

Why hate it?

It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:

SharePoint will amplify your problems.

So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;

  1. Project Management
  2. Information Security
  3. Business Intelligence

Last week we looked at Information Management, this week let’s look at Project Management.

2. Project Management

There are some interesting numbers on the frequency in which SharePoint projects fail. I won’t bore you with numbers mainly because individually they succumb to a lot of subjectivity, but ask anyone that’s been around the block a few times and they will tell you that the majority of SharePoint projects fail. Why? Blaming SharePoint for a bad project is kind of like blaming a poor house design on the hammer in the carpenter’s hand. SharePoint is a tool, albeit a very complex one, but the result is always the result of its usage and rarely the tool itself. SharePoint has its quirks, the vast majority of products do, and part of a proper SharePoint implementation is to address those quirks as best we can. But that’s not where projects tend to fail. The common culprits are the following;

Scope management

This is a really tough one to control in a SharePoint project. When the decision has been made to use SharePoint and people soon realize that it has the potential to solve the majority of your organizations problems, many organizations attempt to solve everything at once or completely the opposite, choose to only solve a single problem with SharePoint.

SharePoint projects are commonly either scoped too large, or too small. Too large a scope, and you are overwhelmed trying to coordinate a very complex solution. You get bogged down with the intricate under wirings of your organization to the point that your project will be stuck in the requirement gathering stages for years. I’ve seen it. I’ve seen organizations that have planned for a year and not really yielded any results. On the other hand, organizations that start too small usually create an inadequate solution for growth. So where is the happy medium?

To properly manage scope within a SharePoint project you need to understand a bit of the big picture of your environment and then focus on one problem at a time. The best place I have found to start is by establishing proper Use Cases for your organization, and not just the ones you think should go into SharePoint. Properly created Use Cases are one of the most powerful architecture tools that we have in IT and is something that every IT department should have on hand already. They truly help focus our solutions to be task oriented and not data oriented. By understanding what our people do or need to be able to do, we can create a better solution for them. After collecting Use Cases, we need to establish an overall vision for the SharePoint solution. This can be a little bit daunting to staff that are new to SharePoint structures. If we look to our Use Cases, we can group the cases that are shared by common roles with the idea being that those roles should be able to complete those tasks as easily as possible. By grouping them, we can establish areas in SharePoint where an employee in that role can go to and complete those tasks. We now have an idea as to the scope of our project – make an area in SharePoint do cases x, y and z. Many areas can be identified with their Use Cases bound to them, and realistic timelines could be better established for each area.

Requirements Gathering

Most organizations feel they are pretty good at requirements gathering because they’ve been doing it for so long. In my experience, they’ve just established that they don’t understand process improvement. It is the question "How can we do this better?" where we establish our daily pursuit of perfection and question our assumed excellence. There is a lot of information elsewhere on different approaches, so I will cut this down as simply as I can. If you are not using an iterative process in your IT projects, you are doing it wrong, plain and simple.

Have an Architect

I should expand on this a bit. You should have a qualified SharePoint architect or architecture committee. "We don’t have one, so where can we find one?" Good luck. There are a lot of lousy consultants out there for various reasons, but you really need to have a good architect in an IT project who understands the impact of various choices they make. When it comes to SharePoint, I offer this advice. Give your solution architect a business problem you wish them to solve in SharePoint, and ask for 3 different solutions and the pros and cons of each. If they can’t do it, RUN! They are obviously under-qualified to be supporting you. A really good architect should be able to rough out more than 3 different solutions.

Testing

Wow. This is one of my absolute worst pet peeves of the IT industry. If the only testing you are doing is User Acceptance Testing (UAT), and maybe some regression testing, you have really missed the boat. I have a whole spiel on this topic which I will save for another blog someday. When it comes to SharePoint, test your solutions including your code and go beyond the question of "Does it work", and ask "Does it work well?"

Use SharePoint to run SharePoint

This is one of my favourites mainly because it is one of the most overlooked. I often ask my clients how someone in their organization would go about creating a new site, say, to manage a project. The answer is typically that the person making the request would send an email to their manager, where it would eventually be forwarded to IT after a couple of emails going back and forth for approvals and information gathering, an IT staff member would then go and manually create a site for the requestor. My reply usually goes something along the lines of "So, you gather some required information, invoke a workflow with steps for approvals and further data collection, and create a site based on the data. Why isn’t that automated in SharePoint?" By using SharePoint to manage SharePoint, you can establish a more consistent structure and daily routine. In the above example, the data can be collected via a list. Workflows can be initiated for the approvals and further data collection and in the end a site could be created automatically as the final successful step in the workflow process. The result would allow IT staff to be involved less, the results more consistent since we reduce the amount of manual steps, and the process to flow much faster. Managing IT requests are also business procedures so don’t ignore them when developing your Use Cases for SharePoint.

Next week part 3 Information Security…

This blog is also on the Developer connection

Do you hate SharePoint? Part 1 of 4

If the answer is yes, could your hatred be caused by your local implementation? In this blog series we look at four common problems with SharePoint implementations and how you can address them.

SharePoint is one of those tools where the line blurs between the developer and the administrator, much like SQL Server and much like SQL Server, SharePoint is everywhere! So even though this post is not about coding for SharePoint, I thought it had some great information that many of us could use when dealing with SharePoint implementations, either as a developer supporting an implementation, or even as an end user (did I mention I use SharePoint at work? Hey boss, you reading this?).  A huge thank you to Neil McIsaac, SharePoint trainer extraordinaire, (bio at the end of the blog) for putting this together. Happy reading!

SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.

Why hate it?

It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:

SharePoint will amplify your problems.

So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;

  1. Information Management
  2. Project Management
  3. Information Security
  4. Business Intelligence

Without a doubt, this is not a definitive list of problem areas, but from my experience, these are the key ones that help make or break your experience with SharePoint. So let’s take a look at them.

1. Information Management

In my mind, this is the biggest problem area and by a considerable margin. Why? Well, if you think about information management, it really encompasses all of the other areas. It is a really broad topic. What is surprising is as an industry whose core revolves around titles such as Information Management and Information Technology; you would think that we’d be better at it. Let’s look at an example: The shared documents library within the default team site is fairly widely used by organizations. At face value it seems like a perfect solution for the sharing of documents. After all, it is called the ‘shared documents’ library.

When I was a kid, I remember going to the library. I am talking about the real one that had shelves and shelves of books that you couldn’t carry around in your pocket. I won’t refer to those times as ‘the good old days’ because they simply weren’t. What fascinated me was the organization. I had the power as a kid, to walk in to the library and find various books on a topic that interested me, and to browse some additional information about each book before ever finding the book on the shelf. You might be thinking that I am referring to the ability to sit down in front of a computer and search, but I’m older than that. I’m referring to the cataloguing system called the Dewey Decimal system.

That’s right, no computers. Yet I could search amongst a huge amount of material systematically and rapidly (for the times). 135 years later, and I’m watching organizations fumble with taxonomy and metadata like new borns driving a car.

So what’s the problem?

If we look at the shared documents library like a real library and a document like a book, if you let your employees simply start saving their document in the library it becomes almost the equivalent of having a library where you open up the front door, and chuck your book into the building. Imagine trying to find that book a week later. For the first hundred books or so, you might be ok, but what about the first thousand? Every time you see the default shared documents library being used, you should picture a real library, with nothing more than a mound of books in the middle of the room and people frantically trying to find things in the pile. The first thing that might come to many peoples mind is that "Well that is what we have Search for!" No we don’t. Well, not exactly. Search doesn’t organize our data for us; it makes the retrieval faster in larger systems. If you don’t believe me, do an internet search for a topic such as Shakespeare and tell me what the most current and correct material is on the subject. So how do we go from a pile of books on the floor, to nicely organized books on the proper shelves? The answer is 2/3rds metadata, and 1/3rd taxonomy.

Metadata is data that describes data. In the case of the Dewey Decimal system, that data helped to organize books into categories such as fiction or non-fiction, and provide additional tags such as animals, psychology, religion etc. so that you could much more easily identify basic keywords that described the material. In the library system, that information is collected, identified, and then recorded when the book is first brought into the library so that the material can be properly placed as well as be identified within a cataloguing system to be more easily retrieved. Do your SharePoint libraries behave like that?

Taxonomy is the organization of metadata. In the example of the library, who determined that fiction and non-fiction should be one of the primary organizational metadata to categorize books? Why not hard cover and soft cover? Within your own organization, the determination of metadata and the taxonomy surrounding it is purely yours. It needs to reflect your organizational goals, which is why companies like Microsoft can’t exactly make that an out of the box feature. YOU have to address it, and unless you like sorting through a million books, you need to address it yesterday.

If you haven’t already addressed it, let me help you with a few tips.

Focus on process

Data is a byproduct of process. Data simply wouldn’t exist if it didn’t have somewhere to go or something to be done to it. Knowing and understanding the key processes in your organization is a must. What can be more difficult is the identification of key areas where your processes will likely change, or where you would like to change in the future. The reason we need to identify this as best as we can is so that we can better lay the ground work now. In other words, after we know what the current process is, we need to ask "What is likely to change? What additional information might be needed to identify problems or opportunities that we could leverage to further improve the process?" As an example, if we examine a simple project management site where we record change requests and have their statuses updated, could you easily identify the total amount of time it took to go from request to resolution? Could I easily identify the chain of events that happened after receiving a change request? And is either of those 2 details important to me or will be important to me in the future? Questions such as those will help take you beyond simply recording a change request and marking it as ‘resolved’. Better metadata = better taxonomy = better processes.

Have Multiple Taxonomies

Taxonomy is fairly simple in concept in that it is leveraged metadata. I think I’ve already established the importance of having some type of taxonomy. Although what I am about to say is really two versions of the same thing, for the sake of the SharePoint argument I am going to separate the taxonomies into 2 types; Navigational taxonomies and categorical taxonomies. The reason for the separation is so they can be planned according to their primary usage in that users are either finding the data they need, or working with the data to make decisions. By focusing on their usage, we can hopefully make a better taxonomy.

With navigational taxonomies our focus should be on the Use Cases that you have established for the project. By focusing on what people do with the site, we can streamline their access to their data. You won’t be able to establish that unless you understand what people do with your site, and Use Cases are the best way to establish that.

You should also support more than one navigational taxonomy since there isn’t only one way to complete a task. The goal of the menu navigation should be task focused, so how do we add a second navigational taxonomy? By adding more menus? No. In SharePoint, we can add these extra navigational taxonomies through the introduction of a Site Directory focused site, and/or through the use of custom search pages and results. Both of these options are relatively easy to implement and will allow your users a second and or third way to find a location in your growing architecture.

Categorical taxonomy can be a bit harder to implement since it deals directly with content. We need to collect metadata on content to better describe it, but what should that metadata be? How should it be best structured? Great questions and the first answer lies within understanding the various processes surrounding your data. How it will be used, what decisions need to be made on it, etc. The metadata from this is typically well understood and most organizations have little trouble in establishing what the metadata is rather they have trouble in establishing how to best implement it within SharePoint.

Let me give you some tips in establishing categorical taxonomies;

Use Content Types

Content types are a way of establishing a common structure that can be shared amongst lists and libraries. Use them if you want to establish some consistency.

Use the Managed Metadata Service (MMS)

You can think of the MMS as a place to store the common vocabulary for your organization which can be used and shared in a number of ways. Another advantage is that you can disseminate the administration of the terms to the people that use them and not IT. Be aware that the MMS interface within the Document Information Panel is only supported within Office 2010.

Support Views

Views are a great way to change to look and organization of a list or library. They work by changing the display of the data, such as sort order, which columns are shown etc. Good views require good metadata.

Support Soft Metadata

Hard metadata is metadata that directly fulfills a business requirement. In other words, it really needs to be there and usually in a very structured way where we control the terms and their usage. Soft metadata on the other hand is metadata that doesn’t have a direct business relationship but can offer some insight to the content. A good example would be in the way that we tag photos. Quite often we will need some hard metadata such as the date that the photo was taken and the location, but we want to support soft metadata so that users are able to tag the photo with open terms, such as ‘wildlife’ or ‘Christmas Party’. But why do we want to support this? To which my answer is ‘Do we really want to turn away free information?’ Granted there is a minimal support cost to this. In the end, we have content that is simply more usable, and with any luck, could be leveraged one day, so I often tout that the support costs are minimal with a potential for much gain, so why not. SharePoint 2010 can implement this many ways including using keywords, and/or open MMS term stores.

Archive

This has been a thorn in my side almost wherever I go. We work in the information age and are so-called masters of information technologies, so why are we so bad at archiving strategies? A common dialog I often have with my clients goes something like this: "Our data retrieval is slow because we have a lot of it, over a million rows.", "Why do you have over a million rows in your table?", "We need to keep our data for X years.", "Did anyone say you need to keep it in the same storage medium as the daily production data?", "Ummm, no.". Archiving data does not have to be offline, it can be online and accessible, it simply has a different purpose than your live, day to day, data, most importantly it should be separated. Every time you create a new location where users can add content, whether it be a list, or a library, or a database, or a file share, you should ask yourself "How does this content retire?" and "When does it change its purpose?" After that, automate the process. Without an archival strategy you are setup for failure, you just don’t know when. By accumulating data over time, you cause the live, day to day, data to slowly become harder to use when it is left in the same storage medium. Retrieving data will be slow, and it will often get in the way of users trying to find the correct content while they are trying to accomplish their day to day tasks.

Next week Part 2. Project management…

NeilMcIssacNeil McIsaac (MCPD, MCITP, MCTS, MCSD, MCDBA, MCSE, MCSA, MCT) is an accomplished educator, consultant, and developer who specializes in enterprise application development and integration, application architecture, and business intelligence. As an instructor, Neil shares his knowledge and years of experience with students on a wide range of topics including SharePoint, BizTalk, SQL, .NET development, and PowerShell. He recently did an interview about SharePoint in the Cloud with .NET Rocks

Neil is an owner of BlueGreen Information Technologies Inc., and has over 18 years experience working in the IT industry in both the private and public sectors. His focus on large scale application development and integration keeps Neil involved almost exclusively with enterprise level companies. However, he also works in every level of government.

Neil lives in Moncton, New Brunswick Canada. In his spare time, Neil enjoys downhill skiing, golf and a new motorcycle.

This blog is also posted on the Canadian Developer Connection

Ask a Trainer: Free resources to help you learn SharePoint

FAST university has free webcasts on Enterprise Search and other SharePoint topics

At the MCT Summit in October, I had a chance to chat with Larry Kaye, a Microsoft Certified Trainer. Larry works with FAST University. I hadn’t heard of that organization before, so I asked Larry to fill me in on what they do. I’ll summarize the key offerings here, but if you don’t feel like reading, just watch my interview with Larry below (apologies for the camera shake, I am prone to that, I think I should get a tripod)

FAST University offers training and resources on SharePoint for administrators and developers. Although they cover other topics as well, they offer a lot of training on search features. They have classroom training, and just in case there are no classroom dates or locations convenient for you, they also offer virtual and e-learning courses.

If you register at their website, you can see a full list of the resources, and access a number of free webcasts! Including the following which I thought might be of interest to SharePoint developers:

  • Architecture of Search in SharePoint 2010 – learn the architecture of search in Microsoft SharePoint 2010 and FAST Search Server 2010 for SharePoint.
  • Business Connectivity Services – Creating a .NET Connectivity Assembly in Visual Studio – learn how to connect SharePoint to external data sources such as SQL Server databases, SAP applications and Web services.
  • FAST Search for SharePoint 2010 – Property Extraction – Learn about the property extraction feature that identifies information such as person names, company names, and geographic names and locations in documents. These properties help you find the “who”, “what”,”when”, and “where” of each document.
  • Fast Search Server for Internet Sites (FSIS) with Content Transformation Services (CTS) – Learn about Content Transformation Services, how to build flows and sub-flows and tips and techniques for building flows in Visual Studio.
  • Search Reporting and Analytics with FAST Search Server – An introduction to Search Reporting and the Search administration tools.

Here’s Larry talking about FAST University and their courses.

This blog is also posted on the Canadian Solution Developer

Improving the SharePoint User Experience with Custom Web Part Editors

ChrisWeb03Today’s blog comes courtesy of Christopher Harrison (@GeekTrainer), a Microsoft Certified Trainer (MCT), teaching mainly SharePoint and SQL Server and the owner and Head Geek at GeekTrainer Inc. Christopher has been training for the past 12+ years, with a couple of breaks in the middle to take on full time jobs. These days he focuses mainly on training, presenting at conferences, and consulting. I had the pleasure of attending a SharePoint Developer session presented by Christopher in Ottawa, and he agreed to share some insight on a SharePoint developer feature. Christopher even included his own My 5 in this blog post, in fact to give credit where credit is due, it was actually one of his posts where I first saw the My 5 concept. So a big thank you for a great blog, complete with a link at the end so you can download the code Smile. Enjoy! Now, take it away Christopher…

Custom Web Part Editors

One of the most critical aspects to any successful SharePoint deployment is achieving a high level of user adoption. There are many factors that will aid in driving people to SharePoint, but one of the biggest is ensuring users have access to their data in their desired format and structure. This is where web parts come into play.

Web parts are of course little boxes, applets, gadgets, widgets, or whatever you like to call them, that perform some action or display some bit of data. Users love web parts because it allows them to easily create and edit pages without having to actually write any code.

But in order for a web part’s true potential to be realized, it needs to be easily edited by the user. You can basically add any property and configure it as editable by the user by adding a couple of simple attributes to a property. Consider the following web part[1]:

[WebBrowsable(true)]

[Category("Configuration")]

[WebDisplayName("Sales Person ID")]

[WebDescription("ID of the desired sales person’s orders")]

[Personalizable(PersonalizationScope.User)]

public Int32 SalesPersonId { get; set; }

 

private GridView gvRecentOrders;

private String connectionString = //AdventureWorks connection string

private String sql = @"SELECT TOP 10 OrderDate

                         , TotalDue

                    FROM Sales.SalesOrderHeader

                    WHERE SalesPersonID = @SalesPersonID

                    ORDER BY OrderDate DESC";

             

protected override void  OnPreRender(EventArgs e)

{

    if(SalesPersonId == 0) {

        DisplayEditLink();

    } else {

        DisplayRecentOrders();

    }

}

 

private void DisplayEditLink()

{

    HyperLink editLink = new HyperLink();

    editLink.NavigateUrl = String.Format(

            "javascript:ShowToolPane2Wrapper(‘Edit’,’129′,'{0}’);"

               , this.ID);

    editLink.ID = String.Format("MsoFrameworkToolpartDefmsg_{0}"

                   , this.ID);

    editLink.Text = "Click here to edit web part";

    this.Controls.Add(editLink);

}

 

private void DisplayRecentOrders()

{

    gvRecentOrders = new GridView();

    using (SqlConnection connection =

               new SqlConnection(connectionString))

    using (SqlCommand command = new SqlCommand(sql, connection)) {

        connection.Open();

        command.Parameters.AddWithValue

            ("@SalesPersonID", SalesPersonId);

        using (SqlDataReader reader = command.ExecuteReader()) {

            gvRecentOrders.DataSource = reader;

            gvRecentOrders.DataBind();

        }

    }

    Controls.Add(gvRecentOrders);

}

 

A Couple of quick notes:

  • First – there’s nothing overly fancy about what I’m doing. I have a property (SalesPersonID) that I want to use to filter the orders. DisplayRecentOrders() executes the query and binds the data to the GridView.
  • Second – I’ve taken a couple of short cuts, hard coding my SQL and my connection string. Not a good idea for production, but just fine for blog posts. 🙂
  • Third – I’ve included a cool little bit of boiler plate code in DisplayEditLink. This will check to see if a value has been set on SalesPersonID, and if not provide a link the user can click on to open the tool pane. That’s much more intuitive for users new to SharePoint than having to click on the little drop down arrow on the upper right corner of the web part.

Here’s the problem. When the tool pane is created, it’s going to use a default editor for SalesPersonID. Because SalesPersonId is an integer, the default editor is going to be a textbox, which would require the user to type in the ID of the desired sales person. That’s obviously not ideal. While I could create a connected web part, and allow the user to choose the sales person from there, that would mean I’d have to add another web part to the page and configure the connection, which is a bit more than I really need for a simple one value property.

The solution? Customize the editor.

SharePoint allows you to create your own editor for a web part if you are not happy with the one created for you. The first step is to create a new class that inherits from EditorPart. EditorPart is similar to a normal web control, except it has two methods that need to be implemented:

  • ApplyChanges() – Responsible for updating the web part with the chosen set through the editor
  • SyncChanges() – Responsible for updating the editor with the values from the web part

Creating the EditorPart involves overriding CreateChildControls() (like a normal control), and then overriding those two methods. The end result looks a bit like the following:

private String connectionString = //AdventureWorks connection string

private String sql = 

          @"SELECT c.FirstName + ‘ ‘ + c.LastName AS Name

                 , sp.SalesPersonId

             FROM Person.Contact c

             INNER JOIN HumanResources.Employee e

                   ON c.ContactID = e.ContactID

             INNER JOIN Sales.SalesPerson sp

                   ON e.EmployeeID = sp.SalesPersonID

                       ORDER BY Name";

 

private DropDownList ddlSalesPeople;

private Label lblSalesPeople;

 

protected override void CreateChildControls()

{

    this.Title = "Recent Sales Properties";

 

    lblSalesPeople = new Label();

    lblSalesPeople.Text = "<b>Sales Person:</b>";

    Controls.Add(lblSalesPeople);

 

    ddlSalesPeople = new DropDownList();

    ddlSalesPeople.DataValueField = "SalesPersonId";

    ddlSalesPeople.DataTextField = "Name";

 

    using(SqlConnection connection =

               new SqlConnection(connectionString))

    using(SqlCommand command = new SqlCommand(sql, connection)) {

        connection.Open();

        using(SqlDataReader reader = command.ExecuteReader()) {

            ddlSalesPeople.DataSource = reader;

            ddlSalesPeople.DataBind();

        }

    }

    Controls.Add(ddlSalesPeople);

 

    base.CreateChildControls();

    ChildControlsCreated = true;

}

 

// Save settings to web part

public override bool ApplyChanges()

{

    EnsureChildControls();

    RecentSales webPart = (RecentSales) this.WebPartToEdit;

    webPart.SalesPersonId =

        Int32.Parse(ddlSalesPeople.SelectedValue);

    return true;

}

 

// Retrieve settings from web part

public override void SyncChanges()

{

    EnsureChildControls();

    RecentSales webPart = (RecentSales) this.WebPartToEdit;

    ddlSalesPeople.SelectedValue = webPart.SalesPersonId.ToString();

}

 

A Couple of notes about my new editor:

  • Once again I’ve hardcoded my connection string and SQL query. I’m ok with that here. 🙂
  • CreateChildControls() is relatively straight forward, adding in the label for display purposes, and then the drop down list.
  • ApplyChanges() and SyncChanges() work just as prescribed, reading the WebPartToEdit property to access the web part.

After creating the EditorPart, the last step is to configure the web part to use the new editor. This is done by performing the following actions:

 

1. Update the web part to implement IWebEditable. IWebEditable has two methods:

  • CreateEditorParts() – used to create an instance of the desired editor web part
  • WebBrowsableObject() – used to return the current instance of the web part for access in the editor

For our example an implementation would look like this:

 

EditorPartCollection IWebEditable.CreateEditorParts()

{

    List<EditorPart> editors = new List<EditorPart>();

    RecentSalesEditor editor = new RecentSalesEditor();

    editor.ID = this.ID + "EditorPart";

    editors.Add(editor);

    return new EditorPartCollection(editors);

}

 

object IWebEditable.WebBrowsableObject

{

    get { return this; }

}

2.  Remove every attribute from the property except Personalizable. Or more specifically, make sure that WebBrowsable is gone. While having the other ones left behind won’t hurt anything, they’re superfluous since we won’t be counting on SharePoint to create the editor for us. The resultant property looks like this:

[Personalizable(PersonalizationScope.User)]

public Int32 SalesPersonId { get; set; }

The end result in the editor will look a little like this:

RecentSalesEditor

Creating usable web parts will go a long way to ensuring reuse and adoption of your SharePoint implementation. With that, here’s today’s My 5.

My 5 components to a good web part

  1. Configurable – A good web part should be configurable by the user. Each user will have different needs for certain web parts, and by allowing users the ability to configure them they’ll become more valuable.
  2. Self-documenting – Users may or may not actually read any documentation that’s separate from the web part. Make sure your properties are clearly named, and provide any supporting documentation on the editor.
  3. Connectable – When appropriate, take advantage of the ability to connect web parts. This allows your users to create parent/child views with ease.
  4. Validates User Input – Either implicitly through controls like drop down lists, or explicitly by using validation controls, make sure you validate every value to ensure it is acceptable.
  5. Provide Custom Error Messages – Unhandled exceptions in a web part will crash the entire page. Make sure you catch all exceptions and display friendly error messages.

Oh – and before I forget. You can download the source code!

[1] In my example, I’m using a custom web part. I did this merely for simplicity of the blog post. I generally favour visual web parts, but adding properties to a visual web part requires a couple of additional steps. The steps I walked through above can be implemented with a visual web part using the same techniques, remembering that the property needs to be added to the web part class, and the user control will be responsible for reading and using the value. If you’re interested, I wrote a blog post on adding properties to visual web parts.

This blog is also posted to the Canadian Solution Developer blog