Siolon

What if Apple Designed SharePoint?

Chris Poteet — Fri, 03 Feb 2012 15:47:13 +0000

Before I get started on this post, I need to be honest with two important points. First, I realize that Apple would most likely never desire to create a product like SharePoint. Apple is primarily a consumer electronics company and not as concerned with the corporate world. Secondly, I’m thoroughly an Apple user, and I do enjoy all their products but am still a Microsoft man. This is common amongst many Microsoft consultants because we are consumers as well as producers.

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.

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

Usability Testing: Why Aren’t We Doing It?

Chris Poteet — Thu, 18 Aug 2011 15:18:05 +0000

I was recently selected to speak at the SPSEMEA SharePoint Saturday. For the talk I wanted to talk about the often forgotten art of usability testing on SharePoint projects. All of the content is generic and applicable enough that you don’t have to be implementing SharePoint to get something from this presentation. The content is made to be applicable to any type of application implementation.

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.

SharePoint Designer Modifies HTML On Save

Chris Poteet — Wed, 22 Jun 2011 15:00:22 +0000

The “Designer” in SharePoint Designer is used a little too liberally I think, but regardless here are two issues that SharePoint Designer does to your markup when saving the file. As far as I know this issue happens in both the 2007 and 2010 versions. Also, despite looking through all the program’s options, I can’t find one that causes this behavior to turn it off.

Designer Removes Closing HTML Tags

The first is that it removes closing HTML tags. This happens when you use the shorthand to close a SharePoint control. Here is what it looks like when this issue comes up.

When saving the file (in this case a page layout), SharePoint Designer removes the closing paragraph tag. To change this instead of using the shorthand to self-close the SharePoint control use the longer version.

Designer Adds a Non-Breaking Space Character

The second issue is SharePoint Designer adding a non-breaking space character when saving. Here is the markup that causes the issue.

In this case simply wrap the control in a span, and the issue goes away. Notice I am using a self-closing tag, yet for some reason in this instance (in the very same document) it doesn’t remove the closing HTML tag. Perplexing.

The first rule of a good web design tool: don’t mess with my markup.

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;
	}
}
});

A New Blog and Published Articles

Chris Poteet — Thu, 02 Jun 2011 17:53:11 +0000

First of all, I want to mention a new project that I’m very excited about. For a while now I’ve wanted to create a separate blog, and the focus of that blog would be solely around the experience oddities that baffle us all in SharePoint. Here is a description from the “about” page:

SharePoint is an amazing tool that has almost endless possibilities, but it has some rough edges. Ask any SharePoint consultant, and they can easily go on at length about things in SharePoint that baffle them. This blog is about those baffling moments. The difference between good applications and great applications are details, and SharePoint is such a massive application (really it’s a platform which has a default interface and features) that many details get lost or are forgotten. This blog is about the interactions, information architectures, usability issues, and other experience decisions that I and the community find problematic with the application.

I will be accepting entries to the blog, and all that is outlined on the page linked above. Please let me know your thoughts, and if you are so inclined you can subscribe.

Unexpected Error (error.siolon.com)

Recent Articles

I recently did two articles for other SharePoint blogs. The first was for the Microsoft end-user blog Get the Point. I was contacted by them a couple of years ago, and I wrote some articles but lost touch with them. I decided to get back to contributing. I am really proud of the article, and I think it is an exhaustive look at the out-of-the-box functionality provided by the enterprise keywords column.

Demystifying the Enterprise Keywords Column

The second article was actually a sizable project I worked on with MVP Michal Pisarek, and it is posted on Nothing But SharePoint. The thrust of the article is to expose others to the analysis process necessary to craft successful SharePoint solutions. For the article we focused on search, but it is certainly a process that can apply to other areas of SharePoint implementations.

By far the best part of the entire process was getting to know Michal better and working with him. If you haven’t read his work, or interacted with him I suggest you do. It’s refreshing to work with someone with such a similar outlook on the technology and consulting.

Let’s Make Search Not Suck

Visual Demonstration of Folders vs. Metadata for Classification

Chris Poteet — Mon, 23 May 2011 15:07:41 +0000

Of all the posts I’ve done on this blog relating to SharePoint, my article denouncing folders is by far the most popular. I later wrote about improvements to folders in 2010, and this video is a culmination of those two posts. I was asked in the comments on the former post about a visual representation explaining why using custom content types and metadata is superior then just using folders to classify content. I looked to see if anyone had done something like it already, but I surprisingly couldn’t find anything.

This video demonstrates two extremes, and I also explain the technological improvements that allow you to walk the line between then. It is still important to note, however, that folders still fall short as a classification method. SharePoint provides a great opportunity to rethink how information should and could be classified to maximize your organization’s information and assisting others in finding it. I also mention a post on documents sets by my friend Michal Pisarek that can be found on the Microsoft Get the Point blog.

Upcoming IA Webinars with MetaVis

Chris Poteet — Fri, 15 Apr 2011 18:14:18 +0000

I have been asked by MetaVis to do a couple of presentations on information architecture design considerations when doing SharePoint migrations. If you’re not familiar with MetaVis and are an information architect or power user I suggest you check them out. They provide robust tools for information architecture creation, classification and migration.

I will be presenting with newly crowned MVP Dave Coleman. My part of the presentations will the overview and conceptual, and then Dave will show how that is implemented using MetaVis. Below are details on both webinars.

“Moving From the Faithful File Share to SharePoint”

April 20, 2011, 2–3 PM (EST)

In this session we will look at a fictional migration scenario from a file share into SharePoint 2010. The focus of this will be a sample information architecture design process guided by company requirements. Through the combination of informed design decisions and thoughtful business analysis you can ensure the success of your SharePoint investment.

View On Demand

“Don’t Upgrade Your Mess”

May 11, 2011, 2–3 PM (EST)

In this session we will look at sample migration from SharePoint Server 2007 to Server 2010. Included in the session will be items of consideration when upgrading your SharePoint environment including concerns such as the information architecture, information classification and security. Upgrades provide a great opportunity to optimize your SharePoint investment, and this session we will show you how.

View on Demand