Category Archives: Content Management

A Case Study in Translating Business Needs Into SharePoint Information Architecture

I got a good comment on my post about the folder-less SharePoint paradigm, and I thought it would be a good opportunity to show how to translate business needs and content analysis into business requirements that can then be translated into an information architecture. I decided to speak with the commenter over the phone, and I asked him some simple questions.

  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.

Leave a reply

The Folder-Less SharePoint Paradigm

FoldersWhen someone first shows me how they’re using SharePoint I look for a sure sign whether they understand and have implemented the SharePoint paradigm to document management—I look for a folder. Granted using an occasional folder here and there is not the end of the world and doesn’t prove someone doesn’t know how to use SharePoint effectively. But if folders are used in a similar fashion to one’s hard drive it is indicative in a lack of understanding.

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.

51 Replies

The SharePoint Grade Card

I have now had a much larger exposure to SharePoint’s product offering, and I feel in a much better and knowledgeable place to assess the strength and weaknesses of the technology.  Like any product that attempts to serve a wide range of functionality there are going to be stronger and weaker areas.  One thing the SP team at Microsoft does well is addressing shortfalls in the technology as it matures.

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.

Leave a reply
  1. Pages:
  3. 1
  4. 2
  5. 3
  6. 4
  7. 5
  8. 6