As part of a SharePoint project a custom event handler was needed that looked across two libraries to assign some metadata automatically. This required a farm level solution created in Visual Studio. (Such development is covered by our course, Programming SharePoint® 2010 Applications with .NET.) I don’t have administrative access to the Server where the code will be deployed, but I do have design rights on the Libraries. After testing locally the packages were sent to the administrator who was in a different time zone. He installed the code and enabled the feature on the appropriate site.

Sadly, on the first attempt at uploading a document the fields weren’t set correctly. Since I can’t use Visual Studio on their server or look at ULS logs to determine if any errors occurred and the admin had gone home, I needed another approach. There may be others but the following approach worked–and continues to work–for me and my client:

I changed the code to look for the presence of a column named ‘Debug’.

If found I wrote diagnostic (trace style) data to the column.

Once the code was deployed I created a new column on the library and uploaded a new document. From the information written to the Debug field I could quickly see that the problem and remedy take appropriate action.

Once fixed, simply delete the Debug column knowing that the facility is there should I need it again. There is a slight overhead here in that the column is looked for whenever the code runs, but this is a small price to pay for the flexibility I gained.

Try it out and let me know your comments or suggestions. I’d love to hear from you.

David Severn

If we examine:

What can we deduce?

It’s a word file, created 24/11/2011, 26 KB in size and based on the file name, it’s a performance review for employee 1244. All this information about the file is metadata. Do we care about this information? No, we don’t; we care about the performance review, what is inside the Word document. However, we need this information so we can find the performance review for employee 1244 which we want to read.

Metadata is also known as tags, descriptions, or properties. It labels basically any piece of data that helps us identify information we are looking for.

Okay, so what? Metadata is about identifying the content of a file; big deal. Well that is exactly the problem with the definition; it is the application of the metadata that is important.

Imagine you are running a company with 1000 employees and the company has been in business for 10 years. You would have about 10,000 employee reviews on file! All of a sudden, the labels identifying the content of files become much more important because you need this information to find the review you are looking for.

Continue to multiply this out again by the 10,000s of files a company has and 1,000s of employees and now we have 1,000,000s of files and the only possible way we can organize the files is by identifying them with tags. We really don’t care about the Meta data, we care about the stuff in inside the files, but the metadata helps us locate the content in the files so we need to apply the metadata to find the files.

Let’s take a look at traditional options we have to help us organize our files:

We can see folders for various years with multiple versions of performance reviews for various employees. We are creating metadata to organize files through folders and file names. Unfortunately, this is unmanaged information. There is no control over the folder structure, nor control over the file naming convention. Multiple these by 1,000,000s of files and you have an uncontrollable mess (look at the LAN drive in your company).

How can we fix this mess? We need a metadata manager.

One aspect of SharePoint allows you to define the metadata you want to maintain and then SharePoint provides tools which use the metadata so you can organize and find the information you are looking for.

In the employee review example, we can identify what we want to keep track of, for example, employee name, employee id, review date, and department. When we save the review for an employee in SharePoint, SharePoint will prompt us for the information to organize the file.

This is called managed information. In addition to the information we already had (file name, create date, and file size, in the example above) SharePoint manages and controls the data we need to keep track of, by using common, enforced terms, to help us to identify and organize our information.

So we have a cop enforcing file tagging, is that all SharePoint is?

That is one aspect of SharePoint and a major one. SharePoint enforces the use of metadata before saving a file so we can find it later, and uses Meta data in searching, for example:

• Find all documents tagged with Employee ID 1244
  
• Identify employee reviews by year, or department.
  

The application of metadata in SharePoint is also much more robust than a simply file name and folders. For example, if we want to keep track of an employee’s region but the employee can be in multiple regions SharePoint can easily allow for that

How can we use metadata to organize files?

Because we can define the information we need to organize our files and enforce its use, we can build content management solutions which are much more flexible than folders with deep nesting.

One approach would be to start with 3 major categories (but of course this can be more or less depending on organizational / information needs).

In each of the areas we can then identify the metadata that we need to help us manage our content. For example at the lower department level, we may need to know who is working on the files, but at the upper levels, we simply need to identify which department created the content, or what the content is for and identify its purpose.

SharePoint allows you to define metadata terms at the project level, department level and corporate / intranet level and to configure which terms are optional, mandatory or shared across the company. This aids in creating a common vocabulary across the organization.

There are tools in SharePoint that allow users to move files between the areas and which will then enforce the files having the correct metadata to organize the information in the new areas.

Can you deploy SharePoint without metadata?

Yes, you can; unfortunately, you won’t have a much better system than you would have with your LAN drive. The SharePoint tools that depend on metadata to identify your information would not have what they need to organize your content.

Do we need to identify all the metadata in our organization?

No, I think that would be a huge task. We can start by identifying common terms in the company; identify local terms used by departments and projects, apply metadata to shared information. The application of metadata will be different for each area of the company and will grow and morph over time as managed sites are created and files are migrated from unmanaged LAN drives.

Gord Maric

SharePoint and Business Intelligence

In earlier posts I gave some thoughts on information structure design which is just one part of the bigger process in implementing effective SharePoint solutions.

Getting feedback from users is a valuable way of determining if your designs are working or not

How to get Feedback – use a survey

Surveys can provide a quick and easy way of getting feedback

The following shows a single question survey

That presents the responder with a choice of pre-determined answers

The question is implemented as a column in the survey list. This can be seen from the survey settings page

Such a survey can be useful but if the answers you are receiving require a particular action a simple workflow can enhance the solution.

Shown below is the SharePoint designer workflow attached to this survey list

The End Result is an automatic conditional alert.

I.e. An email is sent to the service department who can take appropriate action ensuring customer care is maintained.

Simple SharePoint solutions made from built in functionality together with simple customisation such as this can make a real difference to your user community and often take little time to create. Consider how long this would take to build if you were starting from scratch without SharePoint using traditional web development (PHP, ASP) techniques.

More complex actions can be taken within the workflow such as creating items in helpdesk lists, creating tasks, building an audit trail etc.

For more information on SharePoint Designer we offer great courses for both SharePoint 2010 and 2007.

David Severn

Is it a course or a workshop?

On-Site courses are where we come to your location, set up our equipment and present a course. Often these courses are customised or tailored to a specific organisation’s requirements. Content from multiple courses can be incorporated. In order to make the most of this, organisations I have been involved with have sent members of many departments to such training. In a number of cases while presenting various SharePoint courses the technical aspects of SharePoint have had to be put to one side whilst the discussion during the class has turned to information structure. These discussions can include sites, site collections, applications and server farms. Interestingly the views of the more technical I.T people vary quite considerably from those of the end users. Often everyone gets along well and at other times the differences can be expressed in strongly vocal terms. In such cases instructors need to be diplomatic in addition to being technically knowledgeable.

Flexibility is key

In a course situation a good instructor will, instead of sticking rigidly to the syllabus, encourage such discussion–in effect, he or she will be running a mini-workshop. The value of this can be immense. The same applies to a great course facilitator. You need to be both direct and go with the flow.

Although it’s unlikely and unreasonable to expect an outsider to appreciate the requirements of a business on short notice they may prove their worth and encourage the group to consider alternative options based on their prior experience. The role is that of facilitator encouraging the group attendees to generate the ideas and develop solutions. Such a person should be confident in directing and involving a room full of people to share and disseminate information. In my totally unbiased way Learning Tree instructors immediately spring to mind as the ideal candidates for such rolesJ

Define the Purpose

Regardless of when the workshop happens the goal is to design a structure that encompasses both technical and non-technical requirements. Defining goals on a flipchart or whiteboard can keep them in focus during the workshop. For example (admittedly a very simple example) I.T are happy with the size and number of site collections that allow for fast backup and restore of their databases, end user champions are happy with an easy to use navigation structure. A key part to achieving this is to get each side to see the others point of view. Talking through scenarios is one technique I have found to be helpful. Seeing that everyone just wants to do their job can take away the emotional side of any disagreements. Doing this on the fly as part of the course can help but more time will usually be needed. Workshops can be carried out as mentioned in previous posts. Documenting discussions and ideas is crucial – dialog mapping, mind mapping, One Note, etc.

The other point of view

Some comments I have heard as a result of such inclusive workshops include the following:

1. I didn’t realise how important those automated emails were.
2. How many people rely on this? !
3. Now I understand why you need to access this site.
4. I never heard of that department before.
5. So that’s what they do.
6. Of course I am sure that library is backed up during the day but will check.

   And many more !

Sound familiar? Can you tell whether the comments came from (I.T, management or end user departments)?

To summarise, the following should be considered in an I.T. workshop:

• Involve technical and non-technical departments in the requirements gathering and planning process
• Consider using an experienced facilitator to run the workshop
• Document the results and store them centrally (SharePoint site?)

Dave Severn

In requirements gathering a facilitation process can be used with the facilitator guiding and documenting or mapping the discussions occurring as part of a workshop. After installation and starting compendium you will see the following:

This has lots of useful guidance accessible by clicking on the Quick Start node seen above.

Compendium uses nodes of various types. The starting point is a map node:

I have added a map node named DavesDemo and a question node asking, “What kinds of information do we use?” Now I would encourage my workshop attendees to answer the question and as they do I would add answer nodes linking them to the question. Some answers will generate more questions as can be seen in this very simple example.

This use of a dialog map just identifies information. At some point decisions will need to be made and for this pro and con nodes can be added. Another example is in which we ask the question, “What kind of taxonomy should we use?”

Summary

Dialog mapping is a useful tool to have in your SharePoint design toolbox. Give it a try and let me know what you think.

Dave Severn

The image above was created using FreeMind, an open source mind mapping tool available on sourceforge. This shows an easy starting point based on departments. Most taxonomy designers will immediately be concerned over the above as departmental designs can quickly become limited. For example, where would you store documents that are accessed by both sales and marketing departments?

The key to good taxonomy design is to carry out meaningful requirements analysis. Holding a workshop with a representative cross section of users can be an excellent way of achieving this. I suggest ensuring an I.T representative is included in this group as often I.T and end users perceptions of what is required are vastly different. In essence, these are brain storming sessions where attendees contribute their ideas.

Requirements workshop facilitators can use mind mapping software to document the requirements and ideas as they occur. A departmental design as shown above would be easily created from such a workshop. There is nothing wrong with this approach; however, such meetings can result in consideration only of structure. This is only one part of taxonomy design.

The facilitator should also encourage attendees to consider information and its usage. Consider the following:

1. What information do we need?
2. Who needs access to it and who should be prevented from seeing it (security)?
3. How should it be found (navigation)?
4. What processes are needed within SharePoint?
5. What processes are needed within your external systems?
6. What processes are needed within human interaction?

These topic questions can be broken down further as shown below:

Information needed

1. What documents are produced?
2. What appointments need to be made?
3. What user information is needed?
4. What does your business need to do its job?

Access

Identify basic categories to start with then sub divide and reorganise these as you build the picture of what is needed:  Confidential, Public, Internal use only, Available on the web or other common location.

Locating information

Do you need a home page for the company, departments or projects?

Decide where hyperlinks and other navigation controls should be placed.

Processes

Is the information you store static? If not, what processes are needed? Who carries them out? How does this fit with your initially mapped structure (taxonomy design)? Where does input come from? SharePoint Data (lists, libraries), Databases or Remote systems? These are all questions to ask yourself as you determine your processes.

When are we finished?

Working through this process can take several iterations initially and again over time as requirements change. At some point a prototype needs to be created. Users can be invited to try this out and provide feedback. Are we ever finished? Possibly not. It’s an on-going process, but we will at least get to a usable design in time for the next organisational change!

Dave Severn

The list of names is actual data from a production system that my company is working with (no we did not write it, but we need to extract data from it). Carefully take a look at how many variations of spelling (and misspellings). This system has the user entering a location in a textbox and we can obviously see the problems that can occur because the user can enter anything they want.

This list is not from a SharePoint site but it got me thinking. We are asking SharePoint site owners to categorize content with columns and often the poor site owner is not a developer but someone just trying to work with SharePoint. The column create screen has many choices and the first on is a text box and often chosen because it’s the default. A textbox, where users, can enter anything! SharePoint search can’t find all the documents and the reports are wrong. The system does not work. Blame Microsoft!

Let that a look at the option to create columns:

1. Use Single line of text, multiple lines text when you truly expect variable data to be entered, such as a description, or comment.
2. Choice should be used to categorize information. That way everybody choose from the same pick list, no misspelling and user don’t need to guess how to categorize
3. Number, currency, data and time, yes / No, person group, hyperlink: Use those to limit type of values should be entered
4. Lookup (information already on this site): This is like a Choice column but the list of choices is already on a list on the site. Use this to centralize a list of value on the site. This allows you to share the list across multiple lists guaranteeing consistency
5. Managed Metadata: Is like a lookup list but it can be used by any site in the company. The pick list values centrally maintained by someone in your company (probably a content manager). If a list already exists, definitely use this list options. Someone else maintains the values!
6. External data: This is similar to the Managed Meta data, globally available to your sites. However, the list of values is not maintained in SharePoint but rather is extracted from existing systems in your company such as a payroll of manufacturing system. Same as before, if this exists, why duplicate what is already created.

With a little care about how we categorized information we will get much better results when looking for information.

To learn more about SharePoint, try one of Learning Tree’s SharePoint courses.

Gord Maric

SharePoint and Business Intelligence Consulting

Learning Tree instructor Charlene Banks discusses how SharePoint® allows organizations that have already invested in Microsoft office products to move everything to the web for faster collaboration. Charlene is an experienced consultant who uses SharePoint herself to host many of her own clients, enabling her to provide participants with real-world examples for organizing a site to best support their organizations.

Charlene’s experience as a Learning Tree instructor has given her an insider’s view of the reasons Learning Tree stands out from other IT & Management training providers. She talks about Learning Tree’s winning combination of the most expert, talented instructors, the most up-to-date equipment and classrooms and why she loves being a Learning Tree instructor.

Learn more about why Learning Tree instructors are the best in the world.

First of all SharePoint is not a common single purpose application, it is an application for developing web site based applications. So here is the kicker: the web applications are not intended to be developed by the IT departments but rather by information workers and this is why the historical deployment model does not work. IT is not deploying an application; they are deploying a platform to create application and that is why you can’t just roll out SharePoint.

So if we follow IT’s traditional deployment model, they just deployed an application that allows users to create other applications (web sites) as easily as creating a new file folder. What issues will this cause?

• Users will figure this out and create web sites. There will be no management of how many web sites are created and soon we will have the same mess in SharePoint as we had in the LAN drive. I thought SP was going to solve these issues?
• Most users will see SharePoint as only the team site (the most commonly deployed template) and wonder, “This is SharePoint? What the big deal? My LAN drive and email work better.”

So how do fix this?

• First of all DON’T let your IT department deploy SharePoint as if it is a traditional application. Have them build the server infrastructure and create a solid platform where users can build web sites.
• Create a SharePoint deployment team that will come up with usage scenarios, information architecture and governance (guidance and enforcement) for how to use the SharePoint infrastructure IT has deployed.
• Roll out SharePoint slowly to various departments, showing them how various sites (templates) can be created and customized to solve their business problems. Users who are used to working with email and LAN drives build procedures around the limitations of email and LAN drives, and don’t at first see the solutions that are available in SharePoint that are superior.
• Identify power users that you can further train on other SharePoint features, so they sites they build can solve more departmental issues.

If you deploy SharePoint this way instead of following the traditional method you will find greater adoption, reduction of information silos and increased efficiently in the organization.

Gord Maric

SharePoint and Business Intelligence Consultant

At the risk of getting lynched, let me say that the majority of people responding and vehemently saying that SharePoint sucks are developers and technical administrators (The IT Crowd). You guys are very smart and talented but I think your focus is wrong and that’s why you don’t like SharePoint.

The IT crowd is used to working with ultimate control. I can’t do this exactly the way I want so the product sucks.

The IT crowd gets bored easily and is not interested in the easy solution. A wizard? Real developers code applications by hand. Besides, a wizard does not give me ultimate control.

The IT crowd are engineers who focus on speed and performance and are obsessed with stats. If it is not perfect, they are not happy. We can run the query 200 milliseconds faster if….

The IT crowd has no business deploying SharePoint to users! Traditionally, deployment is done by the IT crowd, because traditional systems required talented engineers to deploy applications. SharePoint does not.

The IT crowd needs to focus on SharePoint as a platform. Set up the platform so it works fast, scales, is maintainable and searchable. SharePoint is a platform for developing business applications.

The application development can be done without the IT crowd. SharePoint wizards, ready-made templates, and out-of-the-box functionality can satisfy the majority of the most common business requirements. Here lies the reason why SharePoint sucks. The IT crowd still wants to develop applications. “That’s the way it’s always been done, and we can make it faster and better!” But that is not what we need! A new breed of developers evolves with SharePoint. This group–let’s call them site owners, site collection owners–builds applications on the platform using less flexible tools but achieve incredible speed to market due to the limited flexibility. Websites can be created in seconds or days without code. Gasp! No code development? What’s this world coming to?

Development done without code changes everything! Applications that can be built in seconds require development of practices for managing these applications. That is called Governance, and the IT crowd does not care about governance because it has nothing to do with technology. SharePoint ultimately is more about content management and less about technology after the platform is deployed.

Arguing that users don’t need to be trained because it’s just a web site is rubbish. Users are savvy people and will find ways to build their own “applications”. I have seen entire divisions run on email, and Excel spreadsheets. That is wrong, for so many reasons. The users and IT crowd both know this. However, the users don’t have time or knowledge to build the platform, and the IT crowd is complaining about the platform because they don’t like the way it was built and they believe they can do a better job.

SharePoint sucks because not enough attention is paid to the business application of SharePoint even before the platform is created and after to measure whether the platform was created as per the business needs. You can’t give users a platform and wish them luck. You have to give them a solution to a problem they are experiencing. You can’t just tell them to stop using email and the LAN drive without giving them a compelling reason to change.

I have yet to meet a user who complains when I give them an application that solves a problem they are having. They don’t care which version of the browser we are using. All they can see is “Wow! I don’t have do manage this anymore; the application manages it for me.” If the users are using a bicycle to move product and we give them a car to do the same thing, they will be happy. The IT crowd is arguing over the engine efficiency between car 1 or car 2. The user is just happy to get a car!

SharePoint sucks because not enough attention is paid to the business application of SharePoint after the platform is created.

There. I said it. Now let the arrows fly.

Gord Maric

SharePoint and Business Intelligence consultant

Note: The IT Crowd is a hilarious comedy about IT and Business.