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…

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>

I have created a new resources page that will contain interface design resources and tutorials as well as SharePoint-specific resources.

http://www.siolon.com/resources

The Tech Gang Show

I have signed on for my first podcast! I am with a small gang that covers current tech news, reviews, and I do the “Free File” segment which covers a freeware product.

http://www.techgangshow.com

I’m Engaged!

An absolutely fanastic woman named Gwen Robinson has agreed to marry me! I’m so lucky!

Here is the ring!

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.

A Little Background

Internet Explorer has for a long time been the bane of web developers.  Every since they won the browser war over Netscape (nearing a decade ago now) with what were judged unethical and illegal means which led to a monopoly investigation.  That was settled and Microsoft allowed to continue.  Since then web designers have had to hack, glue, and curse IE due to its large lead on browser usage.

Internet Explorer 6 released in 2001 has been the infamous browser that just will not go away.  Grassroots movement such as Save the Developers have said “enough is enough” and want to see IE 6 erased from the technology landscape.  But even in 2008, seven years later, they still average around 25% of all browsers in usage today.  IE 7 was released and was a huge step forward in standards conformance, security, and compatibility.  It gave both designers and end users hope for the future of IE.

The Controversy Today

Recently when IE 8 was announced it boasted an impressive conformance to several web standards including CSS 2.1, DOM improvements, and even parts of HTML 5.  It also boasted that it passed the Acid 2 test which tested conformance to the CSS standard published by the W3C.  We were all excited until they made their second announcement.

The IE team, under intense political pressure, offered three modes of browsing in terms of web standards support.  It offered the following.

1. Quirks Mode — long standing behavior reminiscent of IE 6, and it was used when no DOCTYPE was specified.
2. IE 7 Mode — With a DOCTYPE it rendered according to IE 7’s standards support.
3. Standards Mode — with the inclusion of a META tag IE 8 would render in the strictest manner possible according to the DOCTYPE.

The community revolted in a way I’ve never seen before, and the IE team decided to have the standards mode be initiated by default with a DOCTYPE, and if the designer wanted IE 7 mode he had to use a META tag.  A major victory was won, and designers everywhere rejoiced and anticipated IE 8.

Compatibility Mode for Intranets

With the release of beta 2 of IE 8 they introduced compatibility mode with some interesting defaults.  They announced that IE 8 would, by default with a DOCTYPE, render all Internet (public) pages in the strictest manner possible per the aforementioned victory.  However, by default all intranet sites (with a URL such as http://moss) would render in compatibility mode.

It’s interesting that they mention SharePoint specifically in the blog post, because I’m sure this move was politically based as I have yet to see a web-based MS application with the political clout that SharePoint has in the enterprise.  This setting is configurable by Group Policy, but it is doubtful that many enterprises will take this as an action item.

Thankfully, the IE team has two META tags that can override all these compatibility view settings.  One emulates IE 7 rendering engine used most prominently for backwards public-facing sites, but there is also an emulate IE 8 META tag to force sites, even specified to render in compatibility mode.

So, Why Should I Care?

I believe there are two major ramifications of this.  The first effects the end user, and the second effects intranet developers.  The only people I can really see caring about this on the development side are those branding SharePoint.  Let’s talk about each.

First of all, the end user doesn’t have the final say whether or not a site is rendered in standards mode or not.  Now, probably most if not all end users could care less, but the addition of a button in the address bar that appears “broken” designates pages that may not be broken but actually rendering perfectly in standards mode but the end user could be drawn to change the behavior because it appears the page is broken.  So with a misleading option in the UI and overriding behavior given to developers over users is a concern.

Secondly, the concern is for those branding SharePoint or other intranet sites.  What scares me is that this decision was pushed by, for instance, the SharePoint team for its product.  I fear that this is indicative of how the next version of SharePoint will be crafted—around compatibility mode and not standards mode.  Any developer will tell you how horrendous the markup and CSS is for SharePoint out-of-the-box.  I was eagerly anticipating the SharePoint team learning from their mistakes in crafting the core styles and master pages by going to a much stricter standards-based site which makes it much easier to brand, far more accessible, and even faster loading.

What Should MS Do?

My hope is that the IE team will respond to such a critique as this as they did their first decision.  Here are some steps I’d encourage the team to take:

1. Render all sites, intra or internet sites in standards mode unless a META tag is present or lack of DOCTYPE.
2. The end user has control over whether or not the site truly displays one way or another.
3. Remove that confusing button in the IE UI which is a poor UX decision.

Will they respond as they did before?  I don’t know, but I can only hope they’ll see the negative ramifications of this for end users and developers alike.

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.