Even though this is done for SharePoint 2010 there is a lot of continuity between that version and 2013 (and even back to 2007).  Views are an absolutely fantastic tool, so it does not surprise me it remains largely untouched between the versions.  Down below is a link to the e-book and each individual post in the series.

Download e-book

Blog Posts

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5
• Part 6
• Part 7
• Part 8

Twitter Friends: What one skill separates good IT consultants from bad ones?

— Chris Poteet (@chrispoteetpro) January 3, 2013

I got some good responses.

@chrispoteetpro Fantastic communication skills and the ability to quickly understand the (business) need, the true outcome/goal.

— Sherman Woo (@SPSherm) January 3, 2013

@chrispoteetpro communication or social skills!

— Marrell Sanders (@TechRevMarrell) January 3, 2013

@stacydraper @spsherm @chrispoteetpro Ability to adjust methods used to fit the organization rather than expecting org to fit to them.

— Ken Glover (@GloverKen) January 3, 2013

@stacydraper @chrispoteetpro How about just ‘not being a salesman’. Goes along with the ‘frankness’ thing. Do what needs to be done.

— James Love (@jimmywim) January 3, 2013

@chrispoteetpro I say it’s a terrible question.that being said, I guess I’d have to go with frankness.

— Stacy Draper (@stacyDraper) January 3, 2013

@mikegil @chrispoteetpro Applied curiousity –the ability to ask keenly insightful, engaging and stimulating questions

— Nancy Settle-Murphy (@nsettlemurphy) January 3, 2013

I’m interested what my other readers/subscribers think about this important question? If you asked me, I would say the answer lies in communication because as Marrell Sanders says: “a highly skilled jerk is still a jerk.”

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.

Before we get started I should be up front about my familiarity with each of these companies. I have used Colligo’s Contributor project for a few years now, and I admittedly love it. It continues to impress me, and I don’t hesitate to recommend it liberally. On the other hand, I have never used the harmon.ie desktop application. The reason I have not is because I hate Outlook getting slower than it already is, and I didn’t have a good experience with Colligo’s Outlook add-in (although I haven’t tried it recently). Hopefully I will use harmon.ie’s desktop product soon, but I’m just too used to Colligo’s offering. Regardless, I’m not letting those impressions shape the review below as I am judging each on their own iOS merits.

Colligo Briefcase

If you’re familiar with their contributor product, you’ll be at home with the iPad app. What they have essentially done is port the Contributor experience to the iPad.  You are given an add site prompt, which then asks the user which lists/libraries they want to sync. After choosing the lists/libraries you want the items and documents are downloaded.  You can open documents in other apps and re-upload to SharePoint, and you can also edit metadata with no limitations that I could find. It’s a straight document and list management iPad app for SharePoint, and it doesn’t promise anything more than that.

Here are my observations while working with the app:

• I couldn’t just browse SharePoint. If you attempt to open a sub-site you have to choose what you want to sync. This was never an issue for me in Contributor because I only sync one site at a time, but on the iPad app it stinks.
• The iconography is dated, and the overall aesthetic of the app leaves something to be desired.
• You cannot view pages.
• The whole focus of this app is document and list management, and it doesn’t attempt to include any social features like harmon.ie’s app.
• The app is not universal meaning you will be looking for another option for your iPhone.

harmon.ie Mobile App

Here are my observations while working with the app:

• I don’t think you can download anything for offline use unlike Colligo’s app.
• Viewing and editing metadata happens through the default mobile metadata view, which isn’t pretty on an iPhone more-or-less an iPad. This also doesn’t allow editing of columns such as managed metadata.
• If you want list support, use Colligo’s app because this app doesn’t support them currently.
• You can only use the app in portrait, and I dislike when apps force an orientation (except games).
• The iconography is also dated in this app, and unlike Colligo’s, the app doesn’t look retina-ready on my new iPad.
• Even though it shows colleagues, I couldn’t find any way to add a colleague.
• It also puts status updates in a non-obvious spot, but when you use Newsgator it just shows blank status updates.
• If you give me the ability to see social updates, please allow me to post them as well.
• The app doesn’t sync views but Colligo’s does.  It only allows you to filter by name and date modified.
• Like Colligo, you can’t view pages.

What Both Get Wrong

There are three big frustrations for both of them. First, I can’t view pages on either of these apps. I don’t know how many modern SharePoint implementations are document-only, but at Portal Solutions we do WCM extensively in all our engagements. It’s disappointing that there is no support at all for publishing pages (or wiki pages for that matter either).  Secondly, I wish both had site collection scoped search. They both support finding content within the current context, but neither support search at a more global level. I thought there was a SharePoint iOS app that did, but I forget which one it was.

The last thing is more a personal gripe. I love SharePoint, and I love my iOS gadgets, so when both come together I have high expectations particularly for the interactions and UI. Both of these apps don’t reinvent the SharePoint experience in any way for iOS. A robust platform like iOS allows you to rethink something of the mechanics of otherwise mundane tasks and make them enjoyable. Day One rejuvenated my love for journaling, Mint’s iOS app showed me budgeting can be fun, Tweetbot showed me how great Twitter can be on iOS. Both of these apps have UIs that look like they were designed by Microsoft developers, and my challenge is for them to rethink how they can utilize the iOS platform to bring a whole new experience to SharePoint.

Which One Should I Get?

It would figure that a SharePoint consultant would say, “it depends.” However, it really does in this case. If you need offline sync, go Colligo. If the social stuff is really important to your SharePoint experience (and you don’t use Newsgator), go harmon.ie. If you need both list and library support, Colligo is better for you. If you want to only spend money on one SharePoint app for both your iPhone and iPad, harmon.ie might be for you.

If I had to pick a winner right now it would be Colligo’s app. However, I think harmon.ie with some adjustments and expansion of their feature set could overtake them. Neither company can afford to be happy with where they’re at right now because it looks like the competition is just getting started.

Update: Both Colligo and harmon.ie have informed that changes are coming to address the items I’ve mentioned. Keep your eyes on each of these apps!

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.

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

<PublishingWebControls:RichHtmlField PrefixStyleSheet="mystyle"
FieldName="PublishingPageContent" runat="server">
</PublishingWebControls:RichHtmlField>

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

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.

<asp:ContentPlaceHolder id="DoctypePanel" runat="server" />

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

<asp:Content ContentPlaceholderID="DoctypePanel" runat="server">

<PublishingWebControls:editmodepanel PageDisplayMode="Display" SuppressTag="True" 
runat="server" id="doctypeedit">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

</PublishingWebControls:editmodepanel>

</asp:Content>

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.

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

<SharePointWebControls:NoteField FieldName="fc2e189e-ba91-48c9-9dd3-16531afddd50"
   runat="server"></SharePointWebControls:NoteField>

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.

<SharePointWebControls:FieldValue id="WorkAddress" FieldName="WorkAddress"
   runat="server"></SharePointWebControls:FieldValue>

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.

<PublishingWebControls:EditModePanel runat="server" id="PageMetadata">

<div class="pagemetadata">

<h4>Edit Page Metadata</h4>

<SharePointWebControls:TextField FieldName="Title" runat="server"></SharePointWebControls:TextField>
<SharePointWebControls:DateTimeField FieldName="EventStartDate" runat="server"></SharePointWebControls:DateTimeField>
<SharePointWebControls:DateTimeField FieldName="EventEndDate" runat="server"></SharePointWebControls:DateTimeField>
<Taxonomy:TaxonomyFieldControl FieldName="EventType" runat="server"></Taxonomy:TaxonomyFieldControl>
<SharePointWebControls:UrlField FieldName="RegisterLink" runat="server"></SharePointWebControls:UrlField>
<SharePointWebControls:NoteField FieldName="WorkAddress" runat="server"></SharePointWebControls:NoteField>
<link href="/_layouts/1033/styles/Themable/forms.css" rel="stylesheet" type="text/css" />

</div>

</PublishingWebControls:EditModePanel>

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

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

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.

<p>
<SharePointWebControls:fieldvalue id="BoxFourContent" FieldName="BoxFourContent" 
     runat="server"/>
</p>

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.

<p>
<SharePointWebControls:fieldvalue id="BoxFourContent" FieldName="BoxFourContent" 
     runat="server"></SharePointWebControls:fieldvalue>
</p>

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.

<h2>
<SharePointWebControls:fieldvalue id="PageTitle" FieldName="Title" runat="server"/>
</h2>

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.

<h2><span>
<SharePointWebControls:fieldvalue id="PageTitle" FieldName="Title" runat="server"/>
</span></h2>

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