Before I begin however I’d like to make a caveat: there are exceptions to this. There are cases of organizations using internal social media successfully, but those companies are often smaller and have a younger demographic. The points I’m going to make are for the majority and not the occasional success. I also envision that in the long-term (hopefully) social media technology will be more prominent in enterprises, but I believe it’s a ways off.

Social Media Has a Professional Stigma

Sites like Facebook and Twitter are often banned either by company policy or forcibly by the company firewall. They are seen as productivity killers, and often punishment is threatened against those that are found abusing it. Naturally when the company then says, “I know we said Twitter could get you fired, but we are pushing this SharePoint tool that provides the same functionality” (although not nearly as well as Twitter). Wouldn’t any reasonable employee be skeptical of that?

Repeated Stories in the Media of Retribution from Social Media

We hear time and time again in the news about people being laid off for comments made on social media sites or people never being hired after viewing content on social media sites. Employees become more cautious about what they post in their own private social media sites, and this makes it even more difficult to get them to use internal social media.

My friend Susan Hanley posted an article about content ratings “inside the firewall,” and her observation is that a lack of anonymity leads to less people giving useful feedback. She even mentions in the article attempting to find a successful using of content ratings in the enterprise and was unable to find one.

The Majority of the Decision Makers Are Older in Age

Selling a vision for social media in the enterprise has to go through executives, and most of them now are older in age and don’t feel comfortable exposing social media technologies in their company. Technology consultants know that without commitment from management and maintaining them as a sponsor and avid user the technology will go no where. You might find a CEO of a large company posting an external blog occasionally, but I’d challenge anyone to find a CEO who on a regular basis updates internal social media regularly.

Enterprise Social Media Technology Always Lags Behind

Microsoft announces Twitter-like functionality in SharePoint 2010, and the rest of the world says, “so what?” It’s been out for years, and by the time Microsoft gets around to cloning the technology it’s nowhere near the current standard. Enterprise technology often gets stuck at a point in time, and they work toward that until release. Microsoft is too large of a company to constantly be reinventing their approach to social media in SharePoint when they do major point releases every 3–4 years.

Enterprise Social Media Lacks Emotional Connection

How exciting is it to go to your SharePoint My Site and see that one of your colleagues added “project management” to her profile as a skill? Not at all. However on Facebook, Flickr or other public social media sites you can interact with family, see pictures of grandchildren and re-kindle long-lost connections. It has more perceived value in your personal life, because it retains an emotional connection. No amount of Twitter-like clone technology in the enterprise is going to make it as exciting as our personal lives. And no Microsoft I don’t think that organizational browser is very exciting regardless of whether or not it’s in Silverlight.

Most People Just Don’t Care

Unless a technological solution is actually being used after implementation then it was a failure. There’s no way around that fact, and I wish more consulting companies would own up to that truth. The fact is that the majority of people don’t care about social media. We read news stories that make it seem as though the world revolves around Twitter, but the fact is that it doesn’t.

Our company recently began using Yammer which is another Twitter clone for an enterprise audience. Even though the majority of our company are in their 20s they don’t participate. Why? They don’t care. The only time they do update is when a director mentions we should use it more. Most of them use it out of obligation and not out of a desire to share and communicate.

Social Media Burn-Out

Earlier this decade those who were interested in social media signed up for every site possible. After a while (much like the cycle in enterprise IT) we realize we have too many dis-unified services. This lead to sites like FriendFeed and Lifestream.fm that sought to aggregate all of our social media in a single place. After this roller coaster we become burnt-out and disenchanted and return to our regular lives.

Is There a Future for Social Media in the Enterprise?

You would think by the points I’ve listed above that I’m convinced it will never happen, but that’s not my sentiment. I believe it has an opportunity to be successful, but those issues mentioned above must be dealt with in a reasonable manner. I would also like to see companies making enterprise-grade software to start to innovate and not just play catch-up all the time. It would go along way to capturing the interest of users.

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.

Microsoft has said on record they are supporting browsers that are XHTML 1.0 compliant, and they haven’t said officially (at least where I can find and validated by others) that it will validate as XHTML 1.0. Regardless, we have a new default master page that uses both the strict XHTML 1.0 DOCTYPE as well as it uses the IE 8 X-UA-Compatible META tag that puts the rendering mode in the strictest rendering available in IE 8. By those two inclusions Microsoft is saying that not only are they coding a page against the XHTML 1.0 strict standard, but by using the META tag they are telling IE 8 that they “really know” what they’re doing. Here is the validation result from a default master page of a team site collection.

SharePoint 2010 Validation Failure

The Problem

The problem of the default master page is more than just an inability to validate. When using this particular DOCTYPE you are committing to not using deprecated elements and attributes and also that your HTML moves closer to XML by abstracting the presentation (CSS), structure (XHTML), and behavior (JavaScript).

There are elements used inside the default rendering of the master page that have been deprecated.

• valign
• align
• width
• border
• font
• color

Along with deprecated attributes and elements the rendering includes a bevy of inline JavaScript and CSS. I was hoping with all the emphasis on using jQuery in SharePoint recently that the principle of “unobtrusive JavaScript” would make its way into SharePoint. Unfortunately, it continues to uses attributes such as onlick and onload as well as tons of JavaScript inline. It continues to have no rhyme or reason why it comes out where it does.

Then you get stuff like this:

<p> </p>
<p> </p>
<p> </p>

And here’s another example. Notice that a HTML element comes after the HTML ends. (There are even spans in the head of the document for some reason.)

</html>
<span></span><span></span><span>

Inline styles were a big problem in 2007, and it doesn’t seem to be any better in 2010. They might as well have just used the center and font tags.

<p class="ms-rteThemeForeColor-5-5" style="text-align:left;font-size:10pt">
<img alt="People collaborating" src="/_layouts/images/homepageSamplePhoto.jpg" style="margin-top:5px;margin-right:5px;margin-bottom:5px;margin-left:5px">
</p>

An excerpt of the 2010 core CSS file.

You would hope that when they do use an external stylesheet that it would be a well commented and laid out file. Unfortunately that is not the case. It still doesn’t have comments, similar code formatting, and it has odd “ReplaceColor” text which I assume changes depending on the SharePoint theme you have selected. We know that this CSS will also not validate against any CSS specification.

Instead of combining the two selectors that use the border: none; they continue from 2007 making them separate selectors which increases the size of the file and decreases the readability of it. This file needs to be clearly documented, formatted consistently, and use of best practices such as CSS shorthand to increase the utility for developers, gain validation, and make the file smaller as a result.

Are There Improvements?

It’s not all bad news. Certainly the inclusion of a DOCTYPE is a step in the right direction. I’m also surprised that the strict IE 8 META tag was used to force IE 8 standards mode. Certainly there are less tables, and class names are clearer then they were in 2007.

These are some positive changes however with such a monumental new version I was hoping that many of the aforementioned issues would not be an issue in 2010. Maybe in 2014…

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.

• Syncing Notes, Tasks, and mail.
• Folders included in Mail interface.
• Free/busy support in iCal.
• Room booking support in iCal.
• Searching the GAL from Address Book.
• Includes contact groups.

There has always been Microsoft Entourage, but only this year did they beta Entourage connecting with Exchange 2007 web services which is the recommended method over MAPI. Most likely Apple will beat Microsoft in building the first client that connects solely through Exchange web services (which is why 2003 won’t be supported in Snow Leopard). On top of that the new iPhone 3GS will also support data encryption which is apparently an enterprise request.

When you add on the fact that both Outlook Live (the successor to Outlook Web Access) and SharePoint 2010 will support browsers other than Internet Explorer you now have (almost)  complete platform independence with your line of business applications. For everything else you can use Boot Camp free in the Mac OS or use VMWare Fusion or Parallels. It is exciting to see great technologies such as Exchange, SharePoint, and Apple OS work seamlessly together.

Political Barriers

Politics are often the first road block encountered when bringing a tool like SharePoint into the enterprise. Someone becomes sold on the platform usually in IT but sold to executives shortly afterward, and then the backlash begins. The first to bring argument against the technology are those who monitor and/or administer legacy systems. The BroadVision/Notes/etc team are not keen on having “their” application moved into a new platform and potentially turned off. SharePoint becomes the hardest to sell to these individuals. Instead of jumping on the new technology train they fear the loss of their job and will fight it to the end.

Cultural Barriers

Usually an enterprise class technology will make it pass the political barriers, because some executive (should have) been sold on it and pushes it through. The next group of people who become change averse are the end user or information worker as Microsoft calls them. These are the people that are being told that the file share is not the way to store and collaborate anymore. Often times frustration ensues, and many people don’t care to see how much better SharePoint can potentially do their processes and fight it.

This is a stage where “quick wins” are important. During this phase the SharePoint implementation team take an existing process that was cumbersome and error prone and do something like automate it with workflow. They could also make the Sarbanes-Oxley compliance team by showing auditing. Here you try and bite off a little bit, show improvement, and these people who benefit become evangelists for the product. The most effective sales person inside of a company is another co-worker.

Technological Barriers

The technology itself can become a barrier if it is not planned wisely. Let’s say you being to roll out the technology, and it’s painfully slow because you have SQL issues. The resulting effect could turn many potential users into quick haters. They then respond that “it’s too slow to use” and it becomes a hard stigma to overcome. It is important that the technological implementation is thoroughly assessed and implemented before training and implementation begins, because when the implementation starts it’s very important to set a precedent of reliability.

There is another technological barrier that is actually more cultural but very related. There will be people who instantly grab onto the technology and want it to do everything for them. These projects often can creep into an implementation and push a project off its timeline and sideline its overall implementation and adoption. It’s very important to have a project plan that is detailed in scope and people involved that want to see it saw through. Getting other ideas to use SharePoint is great, but not when it slows down an entire project.

“To ensure the best possible experience across multiple browsers we’re focusing our SharePoint 2010 engineering efforts on targeting standards based browsers (XHTML 1.0 compliant) including Internet Explorer 7, Internet Explorer 8 and Firefox 3.x. running on Windows Operating Systems.  In addition we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems.  Due to this focus Internet Explorer 6 will not be a supported browser for SharePoint Server 2010.”

Amazing! Even IE6 is seen as a dead technology by Microsoft’s standards. Hopefully with news like this and Windows 7 pre-release excitement the browser might finally be relegated to the hall of technological mistakes. They also announced the WCM features in the next version will allow much greater control over the markup which may finally make SharePoint a real candidate for WCM for public-facing sites!

The announcement does also focus that the technological requirements will be all 64 bit and based on Windows 2008 as the host platform.

Presentation Resources

• ASP.NET CSS Friendly Adapters (Examples)
• xhtmlConformance Setting
• W3C Markup Validation Service
• Presentation Slides