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.

This post contrasts the design philosophies and approaches that underpin both Apple and Microsoft.  It is meant to be a conversation starter and not a way to flame either side.  If it weren’t for SharePoint, I couldn’t afford all my (admittely) over-priced Apple products.  Let’s now consider the question of what SharePoint might look like if Apple designed the product.

Native Apps Emphasis Over Web Apps

I think the most striking difference we would see is a fundamental shift away from the browser for SharePoint.  SharePoint at it’s core is a platform wrapped in a web application.  To work with SharePoint, by and large, means working in a browser.  Now of course the Office products and SharePoint Workspace do interact with SharePoint as desktop products, but the primary intent of SharePoint is to function within a web UI.

Apple on the other hand creates internet services only to enhance native apps. iCloud is a great example to illustrate this philosophy. While iCloud has a minimal web UI, it is not advertised extensively and wasn’t even mentioned (from what I can remember) when Jobs unveiled it. The emphasis at the unveiling was all about how the service would enhance native applications on iOS: Photo Stream synced your photos between devices, and “documents in the cloud” was a way to enhance native the iWork applications on iOS.

Consumers First, Power Users Second

I think the thing that frustrates most “power users” or “tinkerers” with Apple’s products is that it feels dumbed down.  There are settings, but it is nowhere near the expectation of a user familiar with lots of perceived flexibility. Apple presents their products for someone to get started right away with little issue. You hear stories of how grandma or a two-year-old could work an iPad, which is suppose to extol the usability of Apple products, but I’ve never heard that about a Microsoft product.

Microsoft, by and large from my perception, has power users in mind and scale back for more casual users.  If you’ve worked with the control panel in Windows as well as the settings in OS X, you see an immediate contrast.  SharePoint is no different.   Working with the settings for the library in the ribbon or settings page immediately clue in to the complexity of the product.  I’ve been working with SharePoint for several years, and I still don’t feel like I understand every setting just in a document library!

One of my favorite UX principles is the delicate balance between usability and functionality. Ideally, they meet in the middle and provide a good balance. Apple favors simplicity over extensive amounts of functionality, and Microsoft does the opposite. In truth, they both use with a little more balanced position, but I’m not here to criticize either in this post.

A Very Different Third-Party Ecosystem

I think another big area of difference is how the third-party ecosystems are handled. Apple is notorious for a rigorous review process which they want to handle both in the mobile and desktop space. Microsoft on the other hand recognizes third-party vendors (and sometimes buy them) but doesn’t distribute applications themselves.  Right now, Microsoft leaves the vetting of these products to the individual organization.  If I were a betting man, I’d venture to say this will in some way change in “SharePoint 15″ largely in part to the success of companies like Apple.

The SharePoint ecosystem is massive, and it makes for an extremely attractive feature to an already massive product.  However, the quality of these products also varies considerably.  I’ve seen products that are absolutely amazing and others that should never have been sold publicly.  Unlike Apple, Microsoft doesn’t publish any HCI guidelines, and this has a huge impact. I often said, “This app doesn’t feel like a Mac/iOS app,” but I’ve never said, “This SharePoint add-on doesn’t feel like a SharePoint tool.”

Marketing People Not Technology

As I’ve watched Apple over the last few years, I’ve realized how much certain marketing tactics can actually shape the way you feel emotionally about a product. They are well known for their marketing prowess and for good reason.  Almost every Apple ad or other marketing endeavor focuses on the result of technology, which ultimately highlights people, and not the product itself.  Ads for the iPhone 4 showed a dad on a business trip doing a Facetime call with his newborn child, and recent iPad apps show kids learning math on the device.

In contrast, Microsoft ads by and large talk about the technology itself and not a means to an end.  This isn’t always true, and I think Microsoft and other companies are shifting away from it due to the influence of companies like Apple; but it is still very prevelant. Microsoft has had some odd marketing choices recently from using Jerry Seinfeld to their absolutely worthless Office “vision” videos.  Anything on SharePoint from Microsoft has always focused on the technology. Granted, SharePoint and an iPad have different markets, but I would much rather see an engaging ad on SharePoint that talked about how people were improved not some sterile business process.

A Unified Approach to a Family of Products

The last thing I’d like to mention is how I think Apple would handle differently the creation of a “family” of server products. By this I mean SharePoint, Lync, Exchange, O365.  If there is one thing Microsoft understand much better than Apple is integration. I am sometimes amazed at how Exchange, Lync, and SharePoint can work together; but when you work with each one of the products it is apparent that individual teams with individual leaders are designing their own experiences with the product (i.e. Why don’t Lync and Exchange online use a ribbon?). I feel like I’m postulating here quite a bit, but I feel like if Apple approached the experience design between all these products it would be more similiar.

I don’t think the lack of end-user experience is only between these server products. There are times in SharePoint that I wonder how the experience can be so different even inside the product (I even started a blog pointing all these things out).  Apple is fortunate that they had a Jobs who could almost singlehandedly touch every part of the company, but I feel like Microsoft could gain from a single person designing and coordinating the experiences across all of their server products. I sometimes feel like Microsoft creates by outlining features (instead of designing an overarching UX) and then creating the product by diving out tasks to disparate developers (which is how most consultants work).

Conclusion

SharePoint is a great product with a lot of potential, and it’s quite apparent that there’s nothing but limitless excitement right now for the product. I think Microsoft is getting the clue from the success of other companies like Apple and are changing their approach drastically, and that should excite anyone involved with the Microsoft family of products.

The process was simple. I just had to find the code that created the header and navigation and include it in the out-of-the-box master pages for My Sites and the search center (called mysite.master and minimal.master respectively). The search center will then look exactly like v4.master in the header region. The My Site master page has the custom bar above the ribbon, and you’ll notice the site collection title, site title and description are not in the header. The reason for that is that the mysite.master uses those placeholders elsewhere in the master page. For the sake of sticking with the out-of-the-box design I’ve kept the content placeholders where they were designated in mysite.master.

You can then add your custom CSS and JavaScript to the master page as well as any other changes you wish to do. It will at least give you a start on interface consistency between the three major aspects of the SharePoint interface. The ZIP file contains both master pages including a text file with the code I placed into each of the master pages for reference.

Download Master Pages

Searching I found this Technet forum post. In that solution it is a complete CSS solution using a control detecting anonymous and logged-in users. This solution works just fine, but I wasn’t happy with simply hiding the ribbon. If I didn’t need the ribbon why waste all that load time and HTTP requests to load it only to hide it?

This led me to look for another solution, and I found another one that used security trimmed controls to not load the ribbon if not logged in. This was great! I was excited until I logged out to test, and I then realized the vertical scrollbar was hidden. The reason for this is because SharePoint 2010 hides the vertical scrollbar and adds in a custom scrollbar to stick the ribbon to the top. When you hide the ribbon the scrollbar doesn’t show because SharePoint uses overflow: hidden; in CSS for the body so it can handle the scrollbar.

The Hybrid Approach

This led to take both of them to construct the best solution. I used the security trimmed control to hide the ribbon, and then I used the control from the forum post and modified the CSS to handle the scrollbar. Here are the steps combining both of the solutions and including my addition.

1. Add the following before the start of the ribbon.

<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="AddDelPrivateWebParts">

The ribbon starts with the following HTML.

<div id="s4-ribbonrow">

2. Then close the security trimmed control at the end of the ribbon. It should look like the following.

<Triggers>
 <asp:PostBackTrigger ControlID="WebPartAdder" />
 </Triggers>
 </asp:UpdatePanel>
 </div>
</div>
</SharePoint:SPSecurityTrimmedControl>

3. Add the following outside of the security trimmed control (I put it before, but it doesn’t matter). You’ll notice now the body is set to scroll on overflow, and since it’s on the page it will trump the SharePoint style due to the cascade.

<asp:LoginView id="LoginView" runat="server">
 <AnonymousTemplate>
 <style type="text/css">
 body { overflow-y: scroll !important; overflow-x: hidden; }
 body #s4-workspace { overflow-x: hidden; overflow-y: auto !important; }
 </style>
 <!--[if lte IE 7]>
 <style type="text/css">
 html { overflow: auto !important; overflow-x: hidden; }
 body { overflow: auto !important; }
 </style>
 <![endif]-->
 </AnonymousTemplate>
</asp:LoginView>

Note: This supports IE 6 kind of. It will give a vertical scrollbar, but another one is also added. If I’m forced to find another solution I’ll post it, but I’m sick of IE 6.

This also fixes scrolling on iOS devices as well which don’t take kindly to the way SharePoint 2010 does scrolling by default. Hiding the ribbon alleviates the problem and returns one-finger scrolling.

UPDATE: I realized while implementing this for a client that the permissions level to keep the ribbon from loading was too high. I have since changed the permission level from ManageLists to AddDelPrivateWebParts (a role on the OTB contribute group, because why would you have read only users authenticate?). If you use a custom role be sure to match the lowest authenticated user to a role in this list on MSDN.

There are two wireframes: one is for a team site template, and the other is for My Sites. I did not create a publishing site one, because if you’re doing wireframe activities for a publishing site most likely you’re starting over on your interface. You can however use parts from the team site one when building it if you wish. The SharePoint Foundation and Server 2010 team sites are the same so you can use the same wireframe.

They are provided in a Visio format and PDF. I have created them in Visio 2010 and assume they will work in older versions of Visio; please let me know if they do not. I also once again made use of the (updated) GUUUI Visio stencil kit.

• SharePoint 2010 Team Site Wireframe (Visio)
• SharePoint 2010 Team Site Wireframe (PDF)
• SharePoint 2010 My Site Wireframe (Visio)
• SharePoint 2010 My Site Wireframe (PDF)

UPDATE: A commenter below has linked to some Balsamiq templates if you use that application.

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>