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.

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.

Edit Dialog

A client asked me to create a roll-up of some document libraries, and I decided to exercise the data form web part. It worked fine until I was asked why he got an open/save dialog and not the standard SharePoint read-only/edit dialog from document libraries as to the right.

After some help from some Twitter folk (@zaijian and @gvaro) it was made evident that there is some JavaScript that surrounds the anchors in the document library.  After comparing AllItems.aspx to my custom page I saw the JavaScript not included. I then added the JavaScript references around my XSL, and sure enough I got the dialog!

I tried to go one step farther and the whole context menu, but I was only able to get portions of us such as the gold hover bar. I know there were some hidden divs the JavaScript used, but alas I had other work to move onto. If anyone has experience with adding the whole context menu I’d be glad to add it here for others.

<a onclick="return DispEx(this,event,'TRUE','FALSE','TRUE','SharePoint.OpenDocuments.3','0','SharePoint.OpenDocuments','','','','110','0','0','0x7fffffffffffffff')" href="{@FileRef}" onfocus="OnLink(this)"><xsl:value-of select="@FileLeafRef" /></a>

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.

Taking the Plunge

For a while I was doing all my virtualization of MOSS inside Virtual PC which, to say the least, wasn’t the most enjoyable experience. I tried running it on my Sony Vaio with Vista (I did like the laptop), and it just didn’t work out well for me. The computer was slow and unresponsive. It didn’t make me feel as though I had truly recreated a production-like environment to do my SharePoint work in. Then I started seeing that all the big SharePoint consultants were using MacBook Pros with VMware Fusion or Parallels. I decided to take the plunge for a better experience.

After comparing Parallels and Fusion I decided to go with Fusion, and it was a good decision! With my MBP which has 4 GB RAM, 2.8 Ghz processor, and a 320 GB hard drive at 7200 RPM I run SharePoint faster than some dedicated Microsoft Server setups I’ve seen! I can get in and do all my analysis and minor development quickly and easily. It allows me to enjoy the best of OS X while still running my necessary applications for my SharePoint work.

VMware Fusion in Action

Here are some screenshots of SharePoint inside of VMware Fusion.  A recent VMware post outlines one user running Windows SharePoint Services 3.0 in Fusion, but here I am running the full blown version of MOSS Enterprise. You can also see screenshots of me running Visual Studio 2008, SQL Server Management Studio, PowerShell, and MOSS in IE. I could even run all of this in unity mode quickly and seamlessly.

MOSS in Fusion

Visual Studio 2008 in Fusion

SQL Server Studio in Fusion

My company, Mixon Consulting, asked me to write a curriculum on branding SharePoint with my extensive experience with user interface design.  Once I learned the details on how to use the SharePoint platform I was able to put together a curriculum that helps individuals through the painful process.  I’m please with the result, and I look forward to teaching it and help others with the task. Here is an overview of the curriculum:

• Understand the SharePoint platform
• Become acquainted with the differences between various SharePoint interfaces
• See how Microsoft constructed a default interface and how to change it
• Learn the common tasks SharePoint Designer can help you complete in the effort
• Learn how to use technologies such as the data view and data form web parts
• Utilize SharePoint web content management (WCM) features to deliver instant value to your organization
• Create custom master pages, stylesheets, and pages

What Makes This Class Unique?

You might be wondering that after seeing the list above. After all, there are other training companies that provide the above in a curriculum.  There are, however, some serious differences that you’ll get from someone versed in user experience and web standards development.  Here are a few:

• Use free and open source tools to understand an interface
• Learn how to distill functional business requirements when doing design work
• See how information architecture plays an important role in designing interfaces
• Have the opportunity to converse with someone with nearly a decade of interaction and interface design
• Get access to resources to help you in your branding effort
• Learn how to find answers when you need them

If you want more information you can see the official marketing materials on Mixon’s site.

Register Today!

Registrations are being accepted today.  The first class will be on November 11th for three days, and it is $795. If you register by the 30th of this month you’ll get a $50 discount.  Here are links to register.

1. November 11th — 13th
2. December 10th — 12th