This video demonstrates two extremes, and I also explain the technological improvements that allow you to walk the line between then. It is still important to note, however, that folders still fall short as a classification method. SharePoint provides a great opportunity to rethink how information should and could be classified to maximize your organization’s information and assisting others in finding it. I also mention a post on documents sets by my friend Michal Pisarek that can be found on the Microsoft Get the Point blog.

I will be presenting with newly crowned MVP Dave Coleman. My part of the presentations will the overview and conceptual, and then Dave will show how that is implemented using MetaVis. Below are details on both webinars.

“Moving From the Faithful File Share to SharePoint”

April 20, 2011, 2–3 PM (EST)

In this session we will look at a fictional migration scenario from a file share into SharePoint 2010. The focus of this will be a sample information architecture design process guided by company requirements. Through the combination of informed design decisions and thoughtful business analysis you can ensure the success of your SharePoint investment.

View On Demand

“Don’t Upgrade Your Mess”

May 11, 2011, 2–3 PM (EST)

In this session we will look at sample migration from SharePoint Server 2007 to Server 2010. Included in the session will be items of consideration when upgrading your SharePoint environment including concerns such as the information architecture, information classification and security. Upgrades provide a great opportunity to optimize your SharePoint investment, and this session we will show you how.

View on Demand

You can also download the files I used in the presentation.

• PowerPoint and Mindmap from the video
• Sample taxonomy mindmap mentioned in video

Mindjet MindManager has since become my tool of choice for creating and document SharePoint information architectures/taxonomies. I have created a template for SharePoint that you can also use in your next project to get started. While it has some specific columns and has a term store section it can also be used for MOSS/WSS 3 taxonomies as well with a little editing.

The template includes the following features.

• Content type nodes and hierarchy illustrated. The content type nodes also include properties such as internal name, public name, template, etc.
• Every out-of-the-box column has a template node with the available custom properties to define. Also included are visual column groups.
• Site structure illustration. Included are color-codes notes with properties for sites.
• Term store groups. Term store groups, sets and terms are illustrated hierarchically.
• Property mappings for user profile. Since SharePoint 2010 utilizes user profile properties in the term store an example node is included with the custom properties definable for a property import.
• A visual icon designation for many of the nodes as well as a legend is also provided.

Here are a few images to illustrate what it looks like.

Content Types

Content Types Section

Term Store

Term Store Section

Site Structure

Site Structure Section

Here is a video giving an overview of the mindmap (although it’s a little out of date now).

Download the template

Note on Compatibility: While this will open in the Mac version some fidelity is lost. Mindjet hasn’t quite gotten down the compatibility between the two versions. This was created in version 8 for Windows but opens and works fine in version 9 (not tested in lower versions).

There are two wireframes: one is for a team site template, and the other is for My Sites. I did not create a publishing site one, because if you’re doing wireframe activities for a publishing site most likely you’re starting over on your interface. You can however use parts from the team site one when building it if you wish. The SharePoint Foundation and Server 2010 team sites are the same so you can use the same wireframe.

They are provided in a Visio format and PDF. I have created them in Visio 2010 and assume they will work in older versions of Visio; please let me know if they do not. I also once again made use of the (updated) GUUUI Visio stencil kit.

• SharePoint 2010 Team Site Wireframe (Visio)
• SharePoint 2010 Team Site Wireframe (PDF)
• SharePoint 2010 My Site Wireframe (Visio)
• SharePoint 2010 My Site Wireframe (PDF)

UPDATE: A commenter below has linked to some Balsamiq templates if you use that application.

I think most DHTML menus are simply a band-aid for poorly conceived information architectures. There also is this idea that has stuck for the last decade that everything should be “within three clicks” as if have four clicks suddenly means the application is less usable. In truth it is a myth: “The reality is that users have no problem with clicking, as long as they are confident they’re heading in the right direction.” Since most of the time designers simply use existing complex information architectures instead of honing and refining them they default to DHTML to expose all of their site structure.

Let’s look at of the reasons that DHTML menus suck, and I will elaborate on several below:

• As mentioned, often times DHTML menus are used to hide bad information architectures.
• Many DHTML menus have no visual indication that there is a menu beneath it.
• Users become frustrated when they have to follow a complex path for a sensitive menu.
• Navigating by a keyboard loses its luster when using DHTML.
• DHTML menus are often not built with the ability to designate where the user is at in the site structure.
• These menus are often inadvertently activated by a browsing user leading to a jarring experience.
• Even though this is less of a problem then it was even five years ago many DHTML menus use horrendous markup, inline styles, and inline behaviors that fail to degrade gracefully.
• Some DHTML events, such as onmouseover, are becoming obsolete with the rise of multitouch devices.

DHTML Menus and Information Architecture

Before deciding that a DHTML is the way to go most designers don’t want to work a client through a process of investigating the information architecture to see if the application even needs the DHTML. Do you really need three different levels in your menu? Have you done a proper card sorting exercise to determine the ideal labels and structure for your navigation? Can you implement secondary navigation on pages that will compliment a more global navigational structure instead of having to expose all that content in a single menu? These are some of the questions to consider if your application truly needs the DHTML.

DHTML Menus and Indicators

I am literally amazed at the amount of sites I visit that fail to use any kind of indicator in their DHTML menu to tell the user there is content to be exposed. Most commonly when an indicator is used a down arrow or something close is used to designate that there is content beneath the navigation element. Below are two screenshots of sites that do and don’t use the indicator.

No indicators on Best Buy, Microsoft, and even Portal Solutions.

Sites with indicators include SharePoint 2010, Reuters, and Google.

DHTML Menu Sensitivity

Another issue that frusturates users is how sensitive DHTML menus are. If a mouse cursor accidentally slides off the menu the entire thing collapses and you have to start over. If the DHTML menu has multiple levels this can be even more frustrating! The complexity of so many DHTML menus is often the thing that makes them the least usable.

In addition to the menu accidentally collapsing, DHTML menus also have a tendency to expand even when the user had no intention of opening it by initiating the onmouseover event unknowingly which can be a jarring experience. This is especially bad when it is coupled with no indicators as mentioned in the last point.

Getting Lost in the Navigation Structure

One of the primary purposes of navigation is to inform the user where they are at in the site structure. DHTML menus are notorious for never showing where some is at in the site/navigation structure or where they’ve gone (the latter is less of an issue in my opinion for a navigation structure). A user is often left asking themselves, “Where Am I?” Proper and helpful navigation should at the very least designate where they are in the site as it corresponds to the navigation.

Often this has to be done with a dynamic programming language to allow the menu to show where the user is at in the navigation. An example I can show is how WordPress chooses to implement this functionality.

A Remedy: Superfish

One of the best implementations I’ve seen of DHTML is the jQuery plugin Superfish. It is based on the Suckerfish style of markup which is ideal when putting together navigation on the web. While I don’t gravitate towards DHTML, if you’re forced to use it by a client or some other circumstance then this is the best solution I’ve found.

Suckerfish is an ideal solution, because it deals with many of the issues I’ve mentioned above.

• There is an option for timed delay on mouseout. This alleviates the issue of someone accidentally mousing out and not having to start the menu traversal all over again. It can be adjusted to the best timeout for your audience.
• Keyboard navigation is fully supported.
• It supports the awesome hoverIntent jQuery plugin so it won’t accidentally fire when moused over. It also supports a new variation on the hoverIntent plugin called $.event.special.hover.
• It can automatically add arrows for you when there are menus beneath, but it also has a specific CSS class attached to those nodes that you can add whatever you’d like to designate content beneath the current menu item.
• It uses solid markup, and it offers a lot of custom classes added throughout the menu to style various states and elements.
• There are many examples showing you horizontal, vertical, and other variants on the menus appearance (check out the “nav-bar” example which I like a lot).

Conclusion

While I still firmly believe DHTML menus are not the best solution to the problem, Suckerfish at least provides as usable as an alternative as I’ve seen. DHTML still, I believe, is not necessary when constructing good user interfaces with good information architectures. It is a quickly deteriorating technology due to the use of multitouch devices, but if we’re going to use it we might as well make is as usable as possible.

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.

If you don’t have Quicktime you can view the presentation on Vimeo in Flash, and my slides are available on SlideShare.