The Controversy

SharePoint 2007 brought us great improvements to how we think about storing and viewing information. With powerful options such as extensive metadata options, content types, and countless numbers of lists and libraries there were many options available to us. The folder paradigm to storing information was still present in SharePoint mostly to ease the transition from a file share to a web-based application, and it led to a debate amongst information architects on whether folders were a best practice for storing information in SharePoint.

There were people on different sides such as Paul Culmsee who see the issue differently than myself, but the good news is that SharePoint 2010 adds functionality to alleviate some of my concerns in using folders.

Setting Metadata with Folders

One of the things I was concerned about was that folders would remove the desire to create custom content types and metadata and instead use the folder paradigm that they were used to from the file share. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders.

Setting metadata with folders

Views Without Folders

In SharePoint 2007 was an explicit option to not include folders within a view. This seems to me to be the best balance between those who prefer a folder view to those, like myself, who prefer views that are grouped. I always disliked folders (inside or outside of SharePoint), because I felt it an impediment to optimal findability (have you ever tried to navigate someone else’s document folder?). This strikes the balance between those who like folder views and those like myself who prefer grouped views.

Folder settings for views.

Metadata Navigation

Now navigation can be modified out-of-the-box in SharePoint to allow navigation by metadata and content types. Now I don’t have to mess with the terrible tree view, but now instead I can focus on utilizing metadata to optimize the navigation experience. This adds quite a bit of versatility in constructing the user experience for your end users.

Metadata navigation in 2010

Conclusion

The SharePoint team has improved the use of folders in SharePoint 2010, and they’ve also improved the experience to not use folders if you so choose such as large list throttling so folders don’t become a necessity. I hope you get a chance to play with the next version of this exciting platform.

Unlike the author’s recommendation in this post I would venture on the side of over-architecting then under architecting. Let me justify it by the following reasons.

Necessary Granularity

Creating content types that are generic work very well as parent content types that you can leverage the power of metadata inheritance on the children, but it doesn’t do justice to the variety of content most SharePoint instances contain. For instance, associating a content type entitled “News Story” to all sub-sites where a department can have their own content greatly increases content query complexity. You could add a metadata column specifying the department or query the library, but what if HR decides they want a custom expiration policy that the other departments don’t need? A new content type is necessary to support this.

Content Types for Each List/Library

Stephanie questions Shawn Shell in the article on a few points one of which being limiting a list/library to a single content type to avoid confusion to the user. First, it needs to be established that every list comes OOTB with at least two content types which are a folder content type and the generic content type for the content (document, item, etc). While you want to not associate a lot of content types to a library I see no reason a single content type to a library is a bad solution. I would be careful about creating 20 content types and then by apparent necessity creating 20 document libraries, because SharePoint provides us the ability to attach multiple content types. Shawn warns against this by being aware that the content types then guide classification. While it’s true that content type architecture has a direct relationship on classification you can’t make a blanket decision such as every content type deserves its own list/library.

Maintenance Complexity

Shawn makes a good point that content types are site collection bound and having to mirror content types between site collections can be an administrative nightmare. I attempt to mitigate this by ensuring that as much as possible that a certain type of content is bound to a single site collection. While this isn’t always the best solution, often a content type such as “HR Policy” will be bound to a single instance to store these content items to reduce content management overhead.

Choosing the Right Designation

I also believe that a lot of the confusion around where content goes in SharePoint can be greatly reduced when you take the time to correctly name both the list/library and the corresponding content types. Nothing makes me cringe more than a generic “Documents” library with nothing other than the default content types. The user is then forced into the same folder structure they had on a file share. While this might be an easy transition for an end user it’s not the optimal solution in the new SharePoint paradigm.

Conclusion

All of the people in this conversation wish to optimize the user experience of SharePoint as well as utilizing all the great capabilities inside of the platform. While each SharePoint IA is unique I would favor more content type granularity for the reasons stated above.

1. Give me 2–3 examples of business critical documents you want into SharePoint.
2. Explain to me what the document is, how it’s used, and who is invested in the document.
3. After getting a description I probed for potential metadata to use in categorizing and grouping the information.

As you can see I’m not going to specify the site/navigation taxonomy. This would take more analysis so I confined the case studies to content types, metadata, and libraries or lists.

Use Case 1: Market Research Study

The first document we spoke about was a market research study the organization used to hone their product development. As we talked I extracted the following useful bits of information to help categorize the information.

• Large document from outside source (PPT, DOC, XLS, etc).
• Delivered on DVD.
• Used in internal presentations to convey business/product case.
  • Used by engineering for product architecture. Sections of the research study are reused/decomposed to develop product requirements.
  • Manufacturing, planning and commercial organization utilize the information to understand demand logistics requirements in the supply chain.
• The loop is closed by validation activities to consider whether “we accomplished customer goals” (value proposition).

Proposed IA

• Create a “Market Research Studies” document library underneath (possibly) a marketing or research site.
• Add a site content type entitled “Market Research Study”.
• Add the following metadata columns:
  • Process Step (Delivered, Engineering, Manufacturing, Customer Analysis)
  • Product Category (Pharmaceutical, Medical Device, etc)
  • Document Owner
• Due to the obvious workflow I would look into automating this inside SharePoint.

Use Case 2: Product Complaint

The next is a document submitted back to the organization by field agents concerning complaints on manufactured products. This site needs to be very simple to use with a minimalistic form to supply expedient submission of product complaints in the field.

• Submitted action report.
• Photos, text, output report are all included when recording complaints.
• Receive back product in question then run evaluations.
• Then get populated to corrective action system (LOB web application).
• Records management/compliance needed.

Proposed IA

• Create a “Product Complaints” site underneath (possibly) a manufacturing or production site.
• Create a list entitled “Submitted Complaints”.
  • To the complaints list add a content type entitled “Product Complaint”.
  • Add the following metadata:
    • Product Category (Pharmaceutical, Medical Device, etc)
    • Complaint ID (from the LOB web application for cross references)
• Add a “Complaint Photos” library
  • Add a content type entitled “Complaint Photo”
  • Add the following metadata:
    • Complaint ID (from the LOB web application for cross references)
• Turn on auditing on all document libraries and lists in this site.
• Possibly create a Data Form Web Part to rollup all data by Complaint ID.
• This also is a workflow candidate.

Conclusion

This is a very quick attempt at translating content into SharePoint information architecture. Obviously, further content analysis needs to be done, and a supporting site taxonomy is needed for this site collection. You can see how quickly a more robust architecture can help rolling up and tracking data for this organization. If you have any questions on how I translated any of this let me know in the comments.

This isn’t entirely the fault of the end users mind you. Often they are simply thrown SharePoint without a thorough understanding of how to leverage it effectively. The end user simply starts uploading and managing documents they way they’ve known on the file share and/or their local hard drives. The solution to the problem is found in proper and complete training.

Let’s take a look at the major reasons to avoid folders in document libraries.

Improved Findability

If you’ve ever tried to traverse someone else’s folder structure looking for a document you know what a terrible experience it is. We often end up frustrated and still without what we set out to find. Often folder titles take on something meaningful to the original user, but even when using a standard template to folders it still becomes difficult to find documents.

Using a single Documents library that comes out of a new SharePoint site does little to explain the information contained therein. Users then look at this single document folder as the root to an endless array of folders. The better approach would be to separate out your documents into multiple document libraries with titles more indicative of their contents. It also provides a better solution for your quick launch navigation in finding the information.

Content Type Effectiveness

Content Types are the backbone of categorizing and rolling up data in SharePoint. Content Types are limited to applying only to an entire document library so if you wanted to limit a content type to appear or not appear on a folder level isn’t easy nor is in intended to do so. Content Types are made for the document library and should be a representation of the data within the library. Remember that a folder is also a SharePoint content type, and putting documents within folders limits their ability to be surface through methods such as the Content Query Web Part (as you wouldn’t query all documents inside of the folder Content Type).

The Reasons for Views

Views in SharePoint provide the alternative to viewing data within a library without the use of folders. They are based largely on metadata set on the documents from (usually) the Content Types. When adding folders it renders views in SharePoint ineffective. Views provide powerful ways to view data and switch them quickly and easily. I wish more and more I had views and metadata instead of folders in my local computer.

Security

Another big reason to not use folders is the way SharePoint handles security. You’ll notice that security is done on the list level. You can set permissions on a folder which seems like a good solution, but it’s only temporary. As your sites grow it turns into an administrative nightmare to manage all your disparate security settings. The best way is to use the groups for security on the list which inherit on up the site collection, and when you need to aberate you can do so in a cleaner fashion.

Conclusion

This is a small sampling of why folders aren’t the best method in SharePoint document libraries. While not exhaustive it provides a basis for using the powerful paradigm presented in SharePoint to collaborate and share documents inside of SharePoint.

I’ll evaluate each of, what I deem to be, the major functions and tools of SharePoint.  OK, let’s get started.

Windows SharePoint Services — A

Windows SharePoint Services or WSS is now in its third major iteration.  It is the core that MOSS is built upon, and it is where the strength of SharePoint lies.  From it’s incredible Office integration, task and document management, and web part personalization options WSS is what caught my eye and made me desire a career change.There are some minor headaches and pitfalls, but certainly not enough to warrant anything less than an “A” in this category.

Social Networking Capability — B–

Unfortunately, SP didn’t do what I would’ve liked to see in this category.  They introduced “My Sites” in MOSS, but adding colleagues isn’t intuitive and the feature turns into a personal SharePoint site instead of a robust social networking tool for the enterprise.

Blogs and wikis were also introduced in WSS 3, and the inclusion of them is promising but the implementation is poor.  The blog is feature-less allowing only categories and less than impressive personalization features.  The wiki is super basic, and it leaves me confounded on how it seems so quickly implemented.  A look at the benchmark, MediaWiki, will show the lack of robustness in the SP implementation.

Enterprise Search — B+

The MS work on their search in MOSS is surprisingly amazing.  While many companies introduce search replacements for MOSS, often times they are trying to fix poorly architect edsearch solutions with the MS offering.

The search in SP offers many options for optimal information architecture including best bets, search logging/analysis, search scopes, and much more.  It’s impressive to say the least.  The crawler is also very, very effective with filters to spider other forms of content.  They even introduced federated search to this offering, and it makes it all-the-more impressive.

The only reason this doesn’t get an “A” is the search results and placing search in the default interface isn’t worth the high grade although this can be edited by any capable designer.

Business Intelligence — C+

Default business intelligence in SP is less than stellar.  Although key performance indicators (KPI) are in the offering it is simply a graphical display of business data.  Corporations need far more robust diagramming and analysis tools for true business intelligence, and it has been a ripe area for other companies to pick up what is lacking in this feature.

Excel Services is an interesting addition to this as it allows the graphing and analysis of Excel data which is the most rudimentary of business database and business intelligence applications.  I look forward to this being beefed up in the next version of SP.

Web Content Management — B

Web Content Management or WCM was one of my specialties in my last business that shares the name of this site.  I chose WordPress as my tool of choice, but there are fantastic tools including Drupal, Dot Net Nuke, Graffiti CMS, and many others that do a fantastic job with each having their own strengths and weaknesses.

The SP offering of WCM has moved them from solely a intranet/extranet tool into the Internet realm.  WCM is also done differently than or web CMS’.  SP uses metadata in a single list to control what content is available to the page creator in SP Designer.  Creating page layouts then becomes foundational to all SP WCM. Even though pages can be created and metadata is more focused on then other tools such as WordPress or Drupal it still leaves much to be desired.

The workflow of creating metadata to then be used on any form of WCM pages I find quite restricting, and it ultimately slows down the contributor who understands nothing about the WCM architecture.  Inline editing of the content is also less than impressive.  The rich text editor is shaky at best, and the constant need for modal windows hinders usability for the contributor.  To edit the “backend” is only a list without a robust administration interface found in other popular CMS’.

SharePoint Designer and Interface — D

I’m putting both the default interface and SP Designer in the same category since they are so inter-related.  The default interface is clunky, navigation is abundant but poorly implemented, and the “obviousness” of the SP interface is less than obvious.  Also, in the interface the markup is absolutely horrendous.  Typical of ASP.NET controls it outputs horrendous markup.  This hinders accessibility, ease of branding, and even in the realm of SEO when using SP for public-facing sites.  The markup reminds me of what MS is all-to-often ridiculed for lack of web standards awareness.

SP Designer is the approved tool to brand the SP interface.  It’s built on the legacy of FrontPage, and it’s capability and interface is very reminiscent of FrontPage.  However, seemingly they are learning from their rich IDE in Visual Studio and allowed it to influence the designer options and functionality.  If it weren’t for the ability to open up the content database I would never, ever use the tool.  It is expensive, bulky, and there are free editors that make SP Designer look amateur.

The ability to do XSLT in a GUI manner is an interesting perspective, and it makes such a difficult topic somewhat attainable by a non-XML/XSLT expert.  Also, the workflow wizard is actually quite impressive.  Although it has limitations I was able to create a rather complex workflow with logic rather painlessly.

Looking Forward

I’m hoping that these deficiencies will be address and strengths strengthened in the next version of SharePoint.  I understand much of what I criticized is still “version 1.0,” and I expect it to mature.  SharePoint is a powerful platform, and I expect it to continue to dominate the ECM market for years to come.

It’s stories like this that has given corporations a bad taste for the idea of blogging. It is seen as something that adds no real business value and instead detracts the employee from getting “real work” done or even worse smearing the image of the organization. After all, people on MySpace blog but no one “professional” does this. What do we then do with these new ECM solutions, including SharePoint 2007, that include blogging modules? Do we ignore them? Is it really that bad?

I have actually become quite convicted that blogging by employees can add immense value to companies in terms of knowledge management.

The Case for Blogging

What’s interesting about this is that most corporate executives/managers don’t seem to recognize that when they search on the Internet often times what they’re looking for is found on blogs. These can be answers to questions, similarly-minded individuals to collaborate with, and much more. Google has realized this and has even created a specialized search just through blog content. There is much to be learned.

Peter Kollock has published a fantastic article entitled “The Economies of Online Cooperation” where outlines the three major reasons why individuals participate in knowledge exchange. One of which, anticipated reciprocity, is a great example of how blogs do just that.

If each person shares freely, the groups as a whole is better off, having access to information and advice that no single person might match. […] If the possibility of future reciprocation is the motivation driving an individual’s contribution, then the likelihood of providing public goods will be increased to the extent individuals are likely to interact with each other in the future and to the extent that there is some way to keep track of past actions (for example, by making sure contributions are seen by the group as a whole or by providing archives of past actions and contributions).

This is exactly why people blog. There is a perceived reciprocity in providing this information. The second motivation, increased reputation, is also important. These two factors explain why people blog on issues other than their dogs. Here is a summation of reasons for allowing blogging in the enterprise.

• Employees will want to share information if they receive credit
• Employees will want to share information if their professional/personal reputation can be increased (leading to a subject matter expert label)
• Employees will want to share information if there is a perceived future benefit for doing so

These are powerful motivations. Surely it is enough to consider the opportunity for dramatic knowledge transfer.

Arguments Against Blogging in the Enterprise

“My employees will publish something contrary to our principles thereby tarnishing our image.”

This is a problem not with blogs or any other medium for knowledge exchange. If users cannot exercise restraint in this regard then it is a people problem and not one with blogs or other related methods. When an employee knows they will be held accountable for content they are less likely to do something detrimental to their careers. Further, you can enable only intranet-based blogs which allow the content to be only shared internally and also indexed for users to search against that information.

“Our employee productivity will decrease.”

This is also a problem not with blogs but people. Imagine if one of your employees has a valuable “lesson learned” in a critical business process. By enabling them to write about their experience the content can be disseminated to other employees to avoid eventual productivity decrease. I believe a strong argument can be made that by disabling blogging in the enterprise that that will cause potential productivity loss.

Final Points

By enabling blogging in the enterprise on topics related to the business you have actually enabled powerful knowledge transfer and retention. It will also facilitate strong community, dialogue, and increased business productivity. Don’t make the mistake of not using tools to their potential and quenching potential areas of knowledge transfer. By properly training and enabling your employees you will find you will maximize your ROI in your ECM solution.

And this example is better than other’s I’ve seen. On some sites where the blog/post title is long then the post title is truncated! This is unacceptable when search engines give so much weight to the content of your post titles.

For a long time I circumvented this behavior by using the Optimal Title plugin. It worked fine, but it was yet another plugin for something that should’ve been inside the core. So I opened ticket #4407 to integrate the plugin architecture into the core. I created a patch, and it became changeset 6,538! In short, I added a parameter into wp_title() that sets the location of the separator. By default, it goes to the left, but you can move it to the right by specifying it. If you don’t specify anything it defaults to the legacy behavior of going to the left.

This is the code you can now use to generate sexy SEO titles:

<?php wp_title('&raquo;',true,'right'); ?> <?php bloginfo('name'); ?>

This will print: Post/Page Title » Blog Name. By ensuring that you specify meaningful titles for your postings then you can ensure that your findability will increase.  The official documentation on this function has also been updated to include this change.

This was impossible until recently when Harvest published their full API. I now have the ability, through REST, to retrieve my data via XML, parse it, and put it where I choose. This lead me to creating a WordPress plugin to accomplish this, and I was encouraged by someone at Harvest to make it public domain. So I present to you the “Harvest Reports WordPress Plugin.” See the screenshot on the right for what will be accomplished with the plugin.

Remember that this was made to solve a specific business need, namely the display of pending costs incurred since the last invoice. This is not meant to be an exhaustive representation of their API as it only uses a slice of it.

Requirements

1. WordPress 2.3+
2. A Harvest Account
3. PHP5

You might wonder why you need PHP5 as WordPress only needs PHP4. I use the PHP5 SimpleXML functionality to parse the XML. This is far easier then trying to do it in PHP4. Most hosts do offer PHP5, but you might have to add the following to your .htaccess file to utilize that edition.

AddHandler application/x-httpd-php5 .php

Installation

1. Download the plugin
2. In WordPress 2.3 — 2.5 go to “Options” — “Harvest Reports”, and in 2.5 go to “Settings” — “Harvest Reports”.
3. Enter your information
4. Hit “Save”
5. Go to “Manage” — “Your Chosen Title” to see the report

To get your project ID go to your Harvest dashboard — “Manage”, and you’ll see your projects listed. When you open up one you’ll see a numerical value in the URL bar (e.g. yourname.harvestapp.com /projects/49691/). The value you want is 49691. Remember this is only meant for one project, as that was the business need I needed it to solve. Also, if you want to limit the end date on the report I have included that, but leave it blank to retrieve data up to the second.

Caveat On Hourly Rates

Since this plugin is intended to ultimately provide a monetary figure I wanted it to get the default hourly rate from the API. Unfortunately, when I first parsed the XML I saw that despite the fact that my tasks use my default hourly rate nothing was in the XML returned. I pinged their support and got the following rationale.

“When you read the Task API, you basically get back “No setting” at the second (task) level. We use the rates for reporting (and invoicing coming soon), here the defaults get cascaded. But for the API no cascading takes place to make it evident from where the value comes.”

What this means is that for every task that is used for the project you have to go in and manually set the hourly rate. Not ideal, and to me it’s not expected behavior (especially since the reporting tool inside the Harvest interface automatically uses that value), but once you set it you can forget it.

Upcoming Features

Even though I’ve worked a lot on this and need a break I still have improvements in mind.

• JavaScript date picker
• Exception handling from the API
• Ajax retrieval of projects inside the options page (no need to insert a project ID manually)

I also need to double check that is handles tasks that aren’t billable by default correctly. Since I only track tasks that are billable I didn’t test this, but maybe someone can verify for me.

Props

I want to say thanks to Danny Wen of Harvest for encouraging me to do this, and Andrew Charlton of Geekly Weekly for pointing me in the way of cURL and SimpleXML.

When I started my first blog I found that the more serious I took it and the more involved my posts got that I needed more functionality. I wanted my blog to look and act less like a blog and more like an online print journal. It was this desire that started my look for WordPress plugins that could address the desires I had, and these are the best.

WP-Footnotes

The first thing I needed was a way to cite sources and make additional commentary in my writings, and footnotes are the perfect way to do that (even though they technically are endnotes, but the plugin does paginate). WP-Footnotes is an incredible plugin to accomplish this effectively. It has a lot of options, and it’s incredibly easy to use. You simply choose what the marking for the footnoted is (by default it’s double parenthesis), and when your post is rendered to the client it creates all the links for you.

A recent version has a smooth scrolling option that I do not like however. I instead plugged in another smooth scrolling script, and it turned out much better.

JavaScript Pull-Quotes

One of the things I like most about print publications are attractive pull-quotes, and with the JavaScript Pull-Quotes plugin you can achieve nice pull-quotes. It also has many options including different styles to choose for quote. You can even have it automatically cycle between quoting to the left and right! This is the best way to improve an article aesthetically.

Table of Contents Generator

One of the things I enjoy about Wikipedia is how it can give you a quick glance at the article’s content through a table of contents. Generating this functionality in your WordPress posts happen through the Table of Contents Generator WordPress Plugin.

It has no need to use special markup like the ones above, because it automatically scans the headings in the posts and creates a table of contents. The plugin will also recognize top-level and sub-headings. It is a great reminder to use headings in your posts which drastically improves the semantic value of your content.

In Series WordPress Plugin

Often times when writing about a topic in-depth it’s advisable to break it up for the reader. The way to do this before would be to create a page announcing the series and provide links to all the articles in the series. Well no more! The In Series WordPress Plugin makes this task seamless. The plugin adds an option to add it to a series, and the plugin generates the necessary connections between the content. It’s great, because it requires no hacking of your template–it works right out of the box!

Even though I personally haven’t got to give this plugin a go, I’m excited to really make use of this one. Writing series is a great way to present lengthy content on the web, and this plugin takes all of the work out of doing so (besides the writing of course).

WP-Typogrify

The last deals specifically with improving all the little things in typography that we traditionally miss but make a difference. This is a port from the original Python script for WordPress, and it carries the name WP-Typogrify. This does things such as inserting inline styles to adjust the CSS around all-caps, ampersands, and does important little things such as turning double hyphens into em-dashes and much more.

Vote Now!