I remember playing with the beta, and after about 10 minutes I completely gave up.  It was obvious that Microsoft was trying to tow the line between a touch and desktop UI, and it ultimately ending up satisfying neither audience or need.  This video was shared on Twitter, and it summarizes my sentiments perfectly on Windows 8.  Even though the video is a bit long (about 24 minutes), I highly suggest watching until the end.

Jakob Nielsen also posted his usability findings on Windows 8, and it is worth the read.  With both the article and video you can get a sense of what went so wrong with this OS.  Was this the reason Steven Sinofsky was fired?  I would’ve imagined that Ballmer signed off on this mess.

There is also news that Microsoft is taking another page out of Apple’s book and moving to a yearly release cycle with their desktop operating systems.  Whatever they might be doing, I hope that they manage to fix Windows 8.  Everyone was in an uproar over Windows Vista back in the day, but I always thought those criticisms were overblown.  But this time all criticism about Windows 8 is warranted.

Presentation

I made a video that was my actual presentation including going over all of the slides and analysis on the usability test. The presentation runs slightly over 50 minutes. You can also download the slides from the talk as well.

Usability Test

If you want to watch and think through the usability test in its entirety without my commentary you can view it through the UserTesting.com site.

View Usability Test

Resources Mentioned in Presentation

Here are links to the various sites and applications I mention in the slides.

• Morae
• Sliverback
• UserTesting.com
• Open Hallway
• Optimal Workshop

The Mythical End User (Who Really Is You)

We all know (at least I hope we all know) that designing by committee is a shortcut to failed design (this video nails the comedy behind it). One of the first mistakes made in design meetings and teams is that our own personal preferences and desires get projected onto a mythical end-user. How often have you heard something like this.

• “Our users don’t like drop downs.”
• “I don’t think our users will want to see green there.”
• “You know, I’m not sure end users will like that.”

When we probe more we find out that these end-user projections are just personal preferences. The problem of going into a client and suggestion you’re focused on “the end-user” will almost instantly and unconsciously turn our design discussions into projections of this mythical end-user. The well versed usability expert Steve Krug puts it in perspective.

“And the worst thing about the myth of the Average User is that it reinforces the idea that good Web design is largely a matter of figuring out what people like. […] The problem is that there are no simple ‘right’ answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested.“
Steve Krug, Don’t Make Me Think: A Common Sense Approach to Web Usability (pg. 128)

The Misuse of End User Research

It’s not without debate that understanding what types of users that will use your application is of value. If your application has a very specific focus and niche group it makes a lot of design decisions a lot easier. However, often times a mistake made is when we start placing all types of value on suggestions and feedback we receive from users.

Don’t jump ahead on me. I’m not stating that users don’t have valuable input at many stages of the design and maintenance process. If I believed that I would also tell you that usability testing is the largest waste of time in a project which I clearly do not. But I believe that decisions made by an informed UX researcher are often negated, because end users make proclamations about how they feel an application should behave. This ultimately makes your application less worthwhile to larger groups of people. Don Norman states the following.

“Sometimes what is needed is a design dictator who says, ‘Ignore what users say: I know what’s best for them. […] The ‘listen to your users’ produces incoherent designs. The ‘ignore your users’ can produce horror stories, unless the person in charge has a clear vision for the product, what I have called the ‘Conceptual Model.’ The person in charge must follow that vision and not be afraid to ignore findings. Yes, listen to customers, but don’t always do what they say.”

When designing an application a user’s opinion should be stated and noted but not used as the barometer for our design activities. Let’s face it, if we’ve done any work designing application the one thing that that will show up time and time again is that end users don’t know what they want. It’s not their fault either they are simply caught in the middle. Successful applications help users through accomplishing what they need to do without an unfair focus on what they think they want to do.

The Better Emphasis: Designing for Activities

In the article mentioned above by Don Norman he goes on to explain more of why designing for activities is better than user-centered (he uses “human-centered” terminology). All applications exist for a reason, and that reason is to help someone accomplish a task or achieve a goal. It doesn’t matter whether the activity is buying clothes, researching movie times or playing games online. If designers were more honest with themselves and spent less time laboring in Photoshop they’d realize that better time is spent thinking about design in terms of what goals and activities need to be accomplished by your users.

It is this focus that really helped me see a new light in designing user experiences. When I was liberated to think more about designing applications that accomplished goals and less about whether they application used Verdana or Arial I became much more effective. All of the sudden the applications I worked on delivered more utility and saw users returning more often. It is the reason I implore designers everywhere to not use “user-centered design” but instead turn your clients attention to “activity/goal-centered design.”

Conclusion

The astute reader will notice nothing I’ve said here goes against the classically defined tenants of user-centered design, but I wanted to illustrate why using that language with less educated clients doesn’t ultimately help you in your design activities. Be intentional and careful with the words you use, and I guarantee you will find more success in your projects.

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.

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

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.

Note: Please don’t think I’m saying that the way it looks is not as important, but is pales in comparison to our following discussion.

What? You Mean Users Come Here?

When I heard first of User Experience (UX) I had a hard time wrapping my arms around it.  I made it more difficult then it is supposed to be.  In short, UX is the discipline that aims to understand not only who your users are but what they are trying to accomplish with your application.  When you understand UX then you create an interface that facilities these user’s behaviors and desires.   I found this great definition of UX:

The term “user experience” refers to a concept that places the end-user at the focal point of design and development efforts, as opposed to the system, its applications or its aesthetic value alone. It’s based on the general concept of user-centered design. (Source)

I love this definition, because it illustrates that UX “places the end-user at the focal point” which is critical to your applications success.  When you neglect how your users will interact with your system then ultimately, and I guarantee this, it will be a failure. 

We’ve all been on sites that have left a sour taste in our mouth.  Maybe we are forced to use this sites, and when we use them we’d rather complain about them then actually use them.  Whether it’s an intranet or public-facing site we still have the same possibility for failure.  Often times schedules push the necessary time to understand UX to the back-burner in order to “get something out in front of the customer.”  Doesn’t that seem ridiculous?  We want to get something out for our customers so they can benefit from it, but we don’t do the careful assessment necessary to ensure that this happens?

Practical Steps to Facilitate UX Research

Here is a short list of items to remember when developing your next application to conjure UX research.

1. Spend some meaningful time interviewing a wide-range of potential consumers to uncover what they would use your application for.
2. If you’re replacing a legacy system then be sure to ask what about the current system frustrates them.
3. Let your feedback from the consumers drive those tense decisions that often play out between the development team and management.
4. Diagram workflow to understand all variations your users can get from your application.
5. Usability testing will become invaluable to see how users actually use your system as opposed to a hypothetical discussion.
6. Engage user feedback and understanding when developing your information architecture (labels, navigation, etc).

We are all users, and we all have strong opinions on how interfaces should look and function.  The only problem is when we start designing applications that cater to our personal or internal desires and not what aides our customer.  UX doesn’t have to be a burdensome process that puts your project behind schedule, and if done correctly you’ll see immediate and lasting positive effects from your effort.