Siolon » User Interface

Removing and Replacing Default SharePoint Ribbon Styles

Chris Poteet — Mon, 05 Dec 2011 17:03:45 +0000

SharePoint 2010 (and most likely future versions) provides default styles in the ribbon. You can see these with the “Styles” and “Markup Styles” sections of the ribbon. Here is an example of the “Markup Styles” section in action.

Default Markup Styles

What if a client does not want the default ones in there? You could overwrite them in CSS, but most likely your client will not want all of the default ones available. The way to change this is to use the PrefixStyleSheet attribute on the RichHtmlField in your page layout. Here is an example of it in action using the default column for publishing content. (This is also where you can disable other parts of the ribbon using attributes such as AllowFonts=“False” to turn off the font selection option in the ribbon.)

Changing the prefix for the custom styles will now remove them from the ribbon. Now using the following CSS, you can add selections to the “Styles” and “Markup Styles” section. (As a note, the default CSS prefix is “ms-rte”.)

/* Add to Styles Section */
.mystyleStyle-Bold   {
  -ms-name:"Bold";
  font-weight: bold;
}
/* Add to Markup Styles Section */
h3.mystyleElement-Title   {
  -ms-name:"Heading 3";
  font-size: 30px;
}

Now you can see your custom styles in each dropdown. Notice that the “Markup Styles” styles necessitate an element on the selector.

Our New Markup Styles

Using Custom Styles in Content Editor Web Parts

One of the caveats of this method is that it doesn’t work in content editor web parts. So, if a user were to try and add a content editor web part and edit the text, not only would they see the old default styles, but our custom ones would be gone. I thought that was just the way it would be until I found this post on the MSDN forums. In it, someone shares a bit of jQuery that allows us a similiar behavior on the content editor web parts as the publishing HTML fields.

jQuery(document).ready(function ($) {
/* Enable custom stylesheet prefix for CEWP */
ExecuteOrDelayUntilScriptLoaded(function() {
   $("div[RteRedirect]").each(function() {
      var id = $(this).attr("RteRedirect"),
      editSettings = $("#" + id);
      if(editSettings.length > 0 && editSettings[0].PrefixStyleSheet != 'mystyles') {
         editSettings[0]['PrefixStyleSheet'] = 'mystyles';
      }
   });
}, "sp.ribbon.js");
});

Using a DOCTYPE in SharePoint 2007

Chris Poteet — Thu, 20 Oct 2011 15:30:31 +0000

While SharePoint 2007 certainly moved the platform forward for its time, there is no doubt that doing UI work with the CMS is nothing short of excruciating. The reason for this is (a) really, really bad markup and (b) no DOCTYPE (SharePoint Designer doesn’t help the cause either). There is a lot you can do to deal with the first issue, but you’re largely stuck on the second.

The reason adding a DOCTYPE is problematic is because adding the DOCTYPE to the master page makes core functionality break like moving web parts between zones, and all the default styles are not made to work in browser’s standards mode. The best way to get around this would be for the DOCTYPE only to show when the page is in “display” mode but not in “edit” mode. (If you need to develop custom master pages for the “System Master Page” then I would not suggest using this solution because it will cause more heartache then it’s worth.)

To do this we need to include a content placeholder at the top of the master page.

Then, in our layouts, we can include the following EditModePanel that will only output what we have in display mode. Keep in mind that all attributes are necessary to include. It would be nice if we could just include the code block belowin the master page, but it doesn’t work (I presume because it isn’t in the form tag).

Add this CSS to fix alignment on the site actions menu.

.ms-MenuUILabel {
	text-align: left;
}

Thanks to Carlos Fernandez for working through this with me.

UPDATE: Turns out I needed an addition content placeholder to include the X-UA Compatibility Meta Tag. If I didn’t include it I had issues with the browser mode changing effectively. You can’t reuse the same content placeholder because the meta tag belongs in the head.

Advanced Metadata Techniques in Page Layouts

Chris Poteet — Tue, 27 Sep 2011 18:30:37 +0000

When SharePoint unveiled their web content management functionality in 2007, they included the practice on inline editing directly into the content management experience. While they were by no means the first to do so, I feel strongly that they did a very good job considering it was their first iteration of the technology. User interface developers creating page layouts can very easily integrate the editing of metadata directly into a page layout very easily by dragging columns from the “Page Content” section in the toolbox panel of SharePoint Designer. But what if we have some more advanced layouts, and when we try to add metadata into the editing experience? It actually makes the editing experience much less attractive.

Case in point, here is an event page layout for the new Portal Solutions site built in 2010 (the methods described in this post will work in 2007, but all sample code is tested in 2010). As you can see, I have a section that highlights details about the event, and this section is a smaller, floated column on the right. Dragging the columns from the toolbox into the page layout produces a rather ugly content management experience.

A Rather Ugly Experience

The forms that are added inline throw off the layout. You can also notice that I also have a styled button, and putting this page into edit mode actually makes that metadata column incomprehensible. Clearly, we need a better solution.

Using the Read-Only Metadata Value Control

Thankfully the platform provides us some tags that allow us to change how this works. Instead of using a single control that does both the edit mode and display mode we can split the two. Here is what the code looks like when I simply drag and drop the column from the toolbox (this is the address column which actually OTB).

What this control does is in display mode it only pulls the value of the column, but in edit mode it adds the form to support editing the value. We need the ability to separate the two display modes to make for a better experience, and I will show you how.

But first let me direct your attention to that nasty GUID in the snippet above. That comes from SharePoint Designer 2010 by default, and what we really want to use there in the FieldName attribute is not the GUID but the internal name for the column (in SP Designer 2007 it correctly pulls the internal name). While this code might work for a one-off, it certainly won’t work in a scenario where we need to publish these page layouts particularly in a feature deployment. If you didn’t create the column with a feature you can find the internal name by simply opening up the column in edit mode inside the UI (Site Settings » Site Columns » Your Column Name), and in the title bar it will tell you the internal name after the ?field= in the URL (be sure if you create the name in the UI to keep the column name all one word when first creating, and then you can go back and add spaces).

The Column’s Internal Name

Now let’s look at a special control that only pulls the value from a column, and even when it’s in edit mode it doesn’t show a form. This truly is a column in read-only mode. This snippet uses the same address column.

This is much better! Technically, the ID can be whatever you want, but be sure to coordinate to with a developer if they are working with this in any way and need to know the ID. I usually keep the ID and the FieldName the same, but that is at your discretion. Now let’s replace all the columns with this read-only control and see what this looks like in edit mode.

A Much Better Appearance

Adding Back in the Editing Experience

This is looking good, but we still want the ability to edit the values for these columns inline. To do this I add a section at the bottom of the page dedicated to editing metadata. I still keep the rich HTML fields (Publishing Page Content) in the page where they display (if I’m using it), but I move all other columns down below (and sometimes depending on the situation I even put publishing HTML fields in this metadata zone as well). To accomplish this we are going to use the EditModePanel control from the same toolbox panel (in the SharePoint Controls » Server Controls section) to add content into the page that only displays when the page is in edit mode.





Edit Page Metadata

This will allow the content contributor to have a much more streamlined experience particularly in pages where you have a significant amount of metadata you want to offer to edit inline. The column controls I’m using above are similar to the ones provided by the toolbox (with the GUIDs replaced with internal names), but with the EditModePanel it only shows the form layout to edit when the user asks for it in a much better layout.

The one thing to notice is the inclusion of a SharePoint stylesheet that styles the HTML from the controls added when the page is in edit mode. I noticed sometimes the stylesheet didn’t come through, so to alleviate I just included it. It only renders when in edit mode so it’s not an unnecessary HTTP request for viewing content only, and even if it is already included it shouldn’t cause you a styling issue unless you want to overwrite these form styles (in that case remove that reference above).

Here is what the edit metadata zone looks like in edit mode which I put under the page content. I didn’t do much with it style-wise in this screenshot, but you could add some nice touches depending on your desires or needs.

The Dedicated Metadata Editing Area

Adding the Top-Level Site Title as a Navigational Aid

Chris Poteet — Wed, 15 Jun 2011 17:58:40 +0000

I’ve had an interesting requirement show up in the last few projects. All of them were public-facing, and they wanted to have a navigational aid above the quick launch to show the top-level site title. In other words, if the site is contained within a top-level site called “What We Know,” then above the quick launch that text will show up to aid give the user an additional aid in understanding what section of the site they are in.

Site Title Above Quick Launch

I had no idea how to accomplish this so I reached out to my talented co-worker at Portal Solutions Carlos Fernandez. Carlos was able to give me an interesting and reusable solution I’d like to share. I take no credit for this code. I modified a part of the jQuery to pull in the anchor, but the approach and everything else was his work.

Including a Custom AspMenu

The first thing that has to happen is including another instance of the ASP.NET AspMenu control, but it uses a custom sitemap provider with custom attributes. Notice that it has a custom SiteMapProvider, and it has a StartingNodeOffset value. I also use the SharePoint:ProjectProperty control to give the title and URL of the root site; the reason for this is that the AspMenu renders nothing in the root site since it’s using an offset.

Using jQuery to Surface the Title

Using jQuery we can pull the top-level site title that the subsite is contained in and display it in custom HTML without all the HTML from the AspMenu. First is the HTML you used to embed it in the desired location. This uses a heading one which if you use that element elsewhere you might want to downgrade the header (as a semantic best practice you keep a single h1).

Here is one example where you don’t need the title to be an anchor. Notice how the PrepareDisplayValue function deals with the root site, because as mentioned above the menu doesn’t render anything for the root site.

jQuery(document).ready(function ($) {
var titleText = $.trim( $("#siteTitleValue .menu-item-text").text() );
$(".siteTitleDisplay").html(PrepareDisplayValue(titleText));
function PrepareDisplayValue(titleText) {
	if (titleText.length == 0) {
		var titleText = $("#rootSiteTitle").text();
			return titleText;
		}
	else {
		return titleText;
	}
}
});

If you want to include the anchor to the top-level site you can use the following jQuery snippet.

jQuery(document).ready(function ($) {
var titleText = $.trim( $("#siteTitleValue .menu-item-text").text() );
var titleURL = $("#siteTitleValue a.menu-item").attr("href");
$(".siteTitleDisplay").append("" + PrepareDisplayValue(titleText) + "");
function PrepareDisplayValue(titleText) {
	if (titleText.length == 0) {
		var titleText = $("#rootSiteTitle").text();
		return titleText;
	}
	else {
		return titleText;
	}
}
function PrepareUrlValue(titleURL) {
	 if (titleURL == undefined) {
		var titleURL= $("#rootSiteUrl").text();
		return titleURL;
	}
	else {
		return titleURL;
	}
}
});

Default Header and Navigation on My Sites and Search Center

Chris Poteet — Tue, 08 Mar 2011 19:22:53 +0000

For reasons unbeknownst to me and other SharePoint practitioners the Microsoft team decided not to include the site collection navigation as well as the large header above it (contains site logo, title and description as well as the social buttons) in My Sites and the enterprise search center. I’m not going to go on about why I think this was a poor decision, but I wanted to provide you with master pages for both that establish consistency.

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

unbeknownst

Hiding the SharePoint Ribbon from Anonymous Users

Chris Poteet — Wed, 29 Sep 2010 18:30:11 +0000

Working on a couple of public-facing 2010 sites hiding the ribbon has become an issue in each of them (I’ve noticed several public-facing 2010 sites that don’t hide the ribbon, but that’s not an option if you want a clean brand). Searching for the solutions turned up a couple of solutions, but neither solution in itself turned out to be the best option.

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.

The ribbon starts with the following HTML.

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

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.

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.

SharePoint 2010 Wireframes

Chris Poteet — Thu, 09 Sep 2010 20:59:16 +0000

Another version of SharePoint is on us, and the need for the vital excercise of wireframes still exists. I created wireframes for MOSS, and now I have added new wireframes for 2010. If you search for SharePoint 2010 wireframes you’ll find a blog post, but those aren’t really true wireframes in the low-fidelity sense (they’re closer to full comps); and he’s not releasing them publicly anyway. I am a fan of very low-fidelity wireframes, and Visio is one of the better tools to do this in.

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.

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

Making DHTML Menus Suck Less

Chris Poteet — Thu, 03 Jun 2010 01:41:39 +0000

There are designers on both sides of the DHTML menu issue. Some are liberal to use them and have no issue with them, and there are others (including myself) who think it’s not the ideal solution to a navigational structure. Navigation is unquestionably the most important part of any web application, and if it is poorly implemented it makes your application unusable and, more often than not, no one will use it.

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.

SharePoint 2010 and XHTML Validation

Chris Poteet — Sat, 09 Jan 2010 22:26:12 +0000

I’m writing this and another post about doing development on the SharePoint user interface and the overall user experiences to display some of my disappointment with issues I thought would’ve been resolved in this upcoming version.

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:

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.)

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.

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…

SharePoint 2010 System Requirements and Browser Support

Chris Poteet — Mon, 11 May 2009 21:33:09 +0000

The Microsoft SharePoint team has announced on their official blog the following amazing statement (emphasis added):

“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.