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…

“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

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

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>

Because we often don’t fit well into a nice category we are responsible for a much larger part of designing information systems. Nothing makes this more evident than the process of creating wireframes, and I’m going to address the debate on interactive vs. static wireframes in the context of our role in the development process from the perspective of designers, customers, and managers. The time has come to more clearly define who we are, the role we play in the development process, and be sure that we satisfy all interested parties in the process.

The following quote from Rosenfeld and Morville in their IA magnum opus will be expounded upon:

Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for “real visual design.” The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site’s information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page’s widgets. (pgs. 308–9)

Are We Interaction Designers?

The answer is yes and no. We certainly have a role in the overall user experience process, but we are not responsible for how a user actually interacts with an information system. Let’s face it our annotations don’t replace the role of a qualified interaction designer. I will be focusing on the fact that our value-added proposition is that we can effectively lubricate the evolution from a stiff business requirements document into something reminiscent of a usable system that is then passed onto the programmers, designers, and usability gurus.

Please understand that I understand that the field of IA, UX, and all other aspects of architecting interfaces often happens with just a single person. I don’t want to minimize that as I myself served all these hats. I’m simply pointing the role of a wireframe in the overall interface design life cycle.

There are an abundance of tools that purport to aid architects in creating interactive wireframes, but then what does that display to our team members? Does a designer want to be handed a garbled, poorly-coded, auto-generated layout with cookie-cutter interactions? I know when I was a designer I wanted at least some liberty in what the interaction and user experience ended up looking like. It’s true that in most design shops that the designer serves an IA role, but when we have dedicated information architects shouldn’t we stick to doing what we do best? Don’t we deliver more value in designing taxonomies, labels, navigation, and conceptual layouts?

The Customer’s Perspective

The customer will always prefer something interactive—that isn’t a question. Looking at a bland Visio document doesn’t exactly inspire someone, but what is the purpose of the wireframe? Are we not trying to get the customer to focus on the layout, labels, etc and not how the interaction will take place? When we design interactive wireframes doesn’t it also pigeon-hole the designers to design around the interactions from the IA’s wireframe?

Here is what usually happens when you give anything interactive to a customer when you’re trying to do IA and not interaction design/user experience. They will spend more time clicking around complaining about the pop-up windows and the way it looks and not what we actually want them to be looking at? The value in static, seemingly dry wireframes is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.

The Designer’s Perspective

Designers are artists in their trade. They make money, because they know typography, colors, interactions, and all the other unique challenges to being a designer. I can’t tell you how many times I’ve asked for wireframes when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wireframe are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The problem only escalates when an information architect tries to tread too much on what the designers are supposed to do.

When an information architect goes out and converses with the customer, interacts with the functional business requirements, and creates and receives buy off on a wireframe that it is almost invaluable to a designer and the other programmers. A programmer can then focus on database schemas, object orientation, while the designer can worry about the aesthetics of the interface. You will become a programmer/designer’s best friend if you can abstract the job of creating labels while not dictating how the interaction and how it will actually look.

The Project Manager’s Perspective

Project Manager’s are often the hardest to sell on the value of IA. They look at IA as something the designer does, and that only contributes to the difficulty of selling the importance of our field. They are likely to look at the designer and say: give me a mockup to send to the customer, and when money becomes an issue in the project they’ll cut IA’s always before designers. I have never heard of a designer being cut in place of an IA. It has never happened.

We need to carve out what we do best. Designing information systems amongst different skill sets is not reminiscent of some measure of unrelated diversification—everything we do as IA’s is related to everything else. We just need to be sure that what we do we do as well as we possibly can while enabling our fellow designers and programmers while appeasing our customer.

Conclusion

The thesis of this essay was to define what our role is in the wider scope of the development process, and address just one small part of our value added proposition in the development of wireframes. We have so much to offer, but we must be careful on where we tread because we fill such a political position in the development process.

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

Hirsch’s Branding Effort

I was recently tagged to “brand” a SharePoint installation for Hirsch Pipe & Supply Co.  I knew it would be an interesting challenge, but I had no idea how bad it truly would be.

SharePoint is built on ASP.NET 2.0 which I had worked with in my previous job. I found ASP.NET very powerful and flexible. Master pages, App_Themes, CSS Friendly Adapters, and more made working on ASP.NET interfaces relatively painless.  Knowing that SharePoint utilized master pages I thought it would be much easier than it was.  However, it turned out to not be the case.

The Default Master Page

I was immediately struck by the mess that is the default master page.  The master page is laid out with, of course, tables which is reminiscent of why Microsoft is such a joke in the designer world.  Well, I decided to rip out the tables, and surely that would make it easier right?  No.  It turns out that SharePoint only uses one standard ASP.NET control (the navigation control), and the rest are SharePoint specific “delegate” controls which made layouts with CSS difficult.  These are of course stored on the file system, and the only way to edit them is to create painful features.  It looked as though I was stuck with extensive tables for much of the layout.

When I did yank out much of the table layouts it only opened up a headache down the road.  It was actually more painful to try and layout it with CSS then just sticking with the table layouts.  What made it difficult are the extensive nuances in the SharePoint interface that are dependent on others.  For instance, I would lay it out in CSS, but when I went to edit the page to add web parts everything went awry due to dependencies on extensive tables for layout.  I was able to lay out the majority of the default master page with CSS, but I ended up reverting to tables for the main content area due to pain after pain. I did go with Heather Solomon’s minimal base master page for publishing sites which was a better start then I had.

The CSS

The fun doesn’t stop there.  SharePoint has a core stylesheet that is over 4,000 lines long.  I’ve dealt with more styles in one shot, but looking at the stylesheet you would think a 10th grader created them.  There is a lack of shorthand, units of measure, and extensive IE proprietary styles.  Add onto the fact there are no comments in the stylesheet it is absolutely useless to attempt to decode it.  You also can’t simply remove the core styles; well, you could, but it’s another headache that is ultimately not worth tackling.  It’s again easier to deal with the bad then try to make it better.

SharePoint does allow you to specify an alternate stylesheet which does, thankfully, get rendered after the core styles.  The cascade becomes your best friend in altering the styles.  You’ll also notice the “classitis” that abounds in the master page and core styles.  They all have a prefix of ms– which is unneeded and unhelpful.  I wasn’t surprised to find a lack of advanced CSS 2 selectors due to the pressure to support IE 6, but they are hardly any descendant selectors which would drastically decrease the amount of classes in the markup.

The JavaScript

I know Microsoft is now supporting jQuery which we can only hope will reduce the amount of “obtrusive” JavaScript through the site.  It reminds me of how I wrote JavaScript back in the day.  Attempting to decode the core JavaScript is a puzzle I didn’t even attempt.  You are once again forced to use proprietary JavaScript instead of taking it on to write it any better.  If they did abstract the obtrusive JavaScript it would drastically decrease the complexity of the markup sent to the browser. I did end up using jQuery to set the size of certain divs, and I also attempted to clone() and append() DOM elements but it proved fruitless.

Hope for SharePoint vNext

I hope, first that I never have to alter the SharePoint UI again, but that the next version of SharePoint will construct a better default UI with the following changes.

1. Use CSS for layouts.
2. Ditch the delegate controls to use more of the standard ASP.NET controls (or at least improve them).
3. Use a well-commented core CSS file with advanced selectors to eliminate the need for classes.
4. Switch to an unobtrusive JavaScript model.
5. An increased focus on accessibility for public-facing sites.

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.

Navigation is without a doubt one of the most essential elements of any interface, and as a result adequate time and thought is necessary to ensure your interface’s navigation is usable and comprehensive.  From the all important global navigation that stays the same throughout the site, to local navigation which changes based on the content of the page, to contextual navigation which exists within the content itself.  They all work together to form a powerful navigation experience.

• Information Architecture as an Extension of Web Design — features some good points on navigation and IA.
• Information Architecture Deliverables: Site/Navigation Structure — a good article on conveying your IA suggestions for navigation through deliverables.
• Essential Navigation Checklists for Web Design
• Where Am I? — a fantastic article on improving your navigation by highlighting context within your site’s IA.

Types of Navigation

There are typically a few types of navigation: global, local, contextual/supplemental.  Sometimes you may only need one, but other times you may need all three depending on the amount of content and the complexity of the interface.  Understanding how and when to use these different types

• Global navigation is a navigation structure that stays consistent through your application to provide familiarity and a good overview of your site’s content.
  • Global navigation design pattern
• Local navigation is a navigation structure contingent on the current content.
• Contextual navigation refers to navigation that is embedded within a site’s content to facilitate further browsing.  The best of example of this is Wikipedia which links content together inside the articles.

Breadcrumbs

Hansel and Gretel weren’t the only two who wanted to get back to where they started.  Breadcrumbs, when well thought out and implemented in moderation, can add a dynamic and usable element into your interface.

• Location, Path & Attribute Breadcrumbs — an excellent overview of approaches to breadcrumb navigation.
• Breadcrumb Navigation Increasingly Useful — Jakob Nielsen’s analysis of the effectiveness of breadcrumbs.
• Design Cop-out: Breadcrumbs — a very insightful article on the thought necessary to implement breadcrumbs and not using them to “cop-out” of other aspects of IA.

Pagination

Pagination is often an over-looked aspect of effective navigation architectures.  When combined with a thoughtful search architecture it will increase findability drastically.

• Pagination Gallery: Examples And Good Practices — an incredibly rich article outlining common mistakes and best practices.

Navigation Design Patterns

Design patterns are a great way to see how others are starting to standardize the way they approach certain aspects of design and their resulting interactions.  Most often, navigation mistakes are made, because the designer doesn’t take into account existing patterns that users may be familiar with.

• Patterns in Interaction Design — here is a great listing of patterns related to navigation styles including accordions, fly-outs, and much more.
• Elements of Design — an interesting gallery of creatively styled navigation.
• Information Architecture models: Guide to web site navigation patterns — an overview of different approaches to modeling the content in a navigation scheme.