What Does It Take to Become Part of a Community Effort?

Mark Miller (@EUSP) and I sat down virtually yesterday to talk about being a member of a community. The context was the SharePoint community, of course, but we tried to keep it general enough to apply to pretty much any type of community. IMO, the same basic ideas apply to being in charge of your neighborhood social committee, a member of Congress, a speaker on a circuit, or a contributor to the SharePoint community.

All it takes great content, and the willingness to realize that you will act like a moron from time to time. Oh, and a love of bacon, but that’s probably optional.

The video is part of a series Mark is doing called Community Building – Real World Stories. He’s already interviewed a few others, with more to come.

This is part of a series of talks on how community leaders became engaged with their communities: how they found the community, the process they went through to become part of the community and insights into how you can become more credible and visible in your industry.

Next time I should probably set up my Webcam a little less slanty.


Working Title: Black Magic Solutions for White Hat SharePoint

Here’s something really exciting. I’m one of nine authors for an upcoming SharePoint book we’re putting together with Mark Miller (@EUSP), good old Mr. EndUserSharePoint himself. It’s going to be all about using script with SharePoint in interesting and (we hope!) useful ways.

As with our SharePoint 2010 at Work: Tricks, Traps, and Bold Opinions book, we’re each going to write a chapter about something we think is a really cool thing to do in SharePoint using JavaScript and/or jQuery to make it sing.

We’re going a non-traditional route with this book. It’s going to come together very fast and we’re going to publish it ourselves. Thanks go to Mark for both the original idea and the willingness to do a lot of the legwork to get things rolling.

The nine authors who are contributing to the book are: Chris Beckett, Dave Coleman, Josh McCarty, Wendy Neal, Eric Overfield, Peter Serzo, Paul Tavares, Ben Tedder, et moi. I’m pleased as punch to be a member of this group; every single one of the others has impressed me over the years with their talents and passion for that thing we call SharePoint.

Here’s my chapter’s working abstract. Maybe all the lessons I’ve learned about writing script in SPServices can help people out.

To many traditional SharePoint developers, working with JavaScript feels like taking giant steps backward into the Wild West of coding. While it can take some getting used to, nothing could be farther from the truth. By applying good coding practices to your JavaScript and jQuery work, you can devise solid, reusable script libraries to run huge pieces of the SharePoint functionality across your enterprise.

Drawing on the lessons learned from building and maintaining SPServices over four years and across three SharePoint versions, I’ll give you some tips and tricks about how to build better code and to make your life easier in the meantime. Whether you are in an enterprise of one or 100,000, the same good practices can get you where you need to be.

We’re really excited about it and we have some ideas that we think you’ll truly be interested in. But guess what? You can get in on the fun! We’re looking for some reviewers from the community to help us validate the solutions we’re writing about and make the final product as good as it can possibly be. If you’re interested, head on over to the Eventbrite page and sign up.

If you don’t think you can help out by playing a reviewer role, then you can watch our progress on Twitter with #SPWhiteHats.

Here are some more details from the Eventbrite page to tickle your fancy:

How would you like to participate in the creation of a new book?

Nine experienced authors from NothingButSharePoint got together and decided we want to self-publish a unique SharePoint book without having to go through the formal process of a traditional publisher. We want to do a solutions based book where people can select projects of interest to them. We don’t want a bunch of geek speak; just real world solutions that people can use to enhance their SharePoint sites.

That’s where you come in.

Each author will be writing one chapter for the book. We want the book to be as compelling as possible, so we need reviewers from the community to act as proof-readers and copy editors for each of the chapters. You will work with a selected author to review their work, test their solutions, and give feedback for possible enhancements. Each of the solutions are described below.

Your obligation? Look at the chapter from a users perspective and let the author know:

  • Does the solution work?
  • Is it something you would consider using?
  • Are there extensions to the solution that you would find interesting?
  • Does the language flow, does it have correct syntax?
We are interested in people who want to participate in an author’s project, You may select multiple chapters to review, but priority is given to those who select one single chapter. If the chapter you would like to review is full, you will see a “Sold Out” or “N/A” sign next to the chapter.
The first draft of the chapters will be finished on April 30th. You will work with the author during the draft period and then help with testing the final code and demos during the first week of May.

What’s in it for you?

What you’ll get for your efforts is twofold. First, you will be listed in the credits of the book as a technical reviewer for the project. Second, you’ll have pre-release access to a chapter of the book.

The solutions will be built and demoed in a SharePoint 2010 environment, but most chapters will also talk about how to implement them in 2013, when appropriate.

How does that sound? If you’ve got the time and the inclination, check out the abstracts, select one chapter you’d like to review and let’s get started. If the chapter you’d like to select is marked with “Sold Out” or “N/A”, that means we have enough reviewers for that chapter.

Making Sense of HTML5 with SharePoint: Internet Explorer 9 Capabilities

Let’s take as a sort of given that the majority of people who use SharePoint, at least for Intranets, are using Internet Explorer. I know that’s a big assumption, and in most organizations it’s not fully true. Many people choose to go rogue from the standards and use other browsers, most front end developers refuse to use IE, etc.

So why make the assumption, you might ask? Well, I want to focus first on the HTML5 capabilities that organizations that use SharePoint can reasonably expect to use. Knowing that the majority of real users (maybe not the people reading this article) use IE as their browser means that our palette is somewhat limited. The fact that many users out there in the real world are still using IE8, IE7, or yes, even IE6 makes it even worse.

So let’s go with the using IE assumption, but allow that the version is IE9. Without that, this HTML5 stuff is all pipe dreams and smoke. When I I use the IE Developer Tools to set IE9 to IE7 or IE8 modes, I get a measly 42 / 500 points at the HTML5Test site. It’s hardly worth bothering with HTML5 goodness at that point. The HTML5Please site takes a different slant and gives a good,. clear overview of the capabilities of the different levels of IE. Without IE9, not so much. When can I use… shows every single HTML5 capability in tables for each browser level. The point is, there’s lots of information out there about what we should use, use with assistance like shims or shivs, use with fallbacks, or avoid. There’s no real excuse for developing something that won’t work with a known browser base.

So let’s look at the major cool HTML5 stuff that we can do if our users are on IE9, taking the majority of the information from looking across the sites mentioned above. I captured the images (yes, they are just images – no interactivity) from the HTML5Rocks Playground.


HTML5 Elements

Elements give us ways to prepare our content to live out on the Semantic Web. For us SharePointilists building internally focused applications it may be of less interest, but over time as content gets wrapped in these elements, we’ll be able to more easily reuse and redisplay content in different contexts.


HTML5 Canvas

Canvas may be the HTML5 capability that has the most people excited. Canvas gives us a container into which we can add graphics on the fly using script. ‘Nuff sed on this one for now. I’ll show some cool demos later.


HTML5 Video

Everyone loves a good video player, and HTML5 makes it oh-so-easy. Well, sort of. There are some odd inconsistencies due to the different standard which different browsers support, but remember that we’re focused on IE here, at least for now. We get a nice video player without any plug-ins or add-ons. See HTML5Video.org for demos and examples.


HTML5 Audio

Similar to the video player, we get an easy to use audio player. It’s basically the same thing from the user standpoint – it looks like the video player, but without the video part – but the way we set things up is a little bit different (but still really easy).

Now What?

So, that looks like a pretty short list, doesn’t it? Unfortunately, it is. The more I dig into this HTML5 stuff, the more I feel that while HTML5 as a standard contains a lot of great stuff, the browsers just aren’t there yet. Or they are too inconsistent for us to reliably build HTML5-based capabilities without using a lot of shimming.

But it’s not all bad. In the next set of articles in the series, I’ll show you how to take advantage of the capabilities above and then get into some of the others that you can use with the appropriate shims and fallbacks.

This post also appeared at NothingButSharePoint.com on 2012-04-27. Visit the post there to read additional comments.

Making Sense of HTML5 with SharePoint: Hello World

If you’ve been following along with this series, you’ve probably been thinking “Great, but what can I do with HTML5 in SharePoint?” In other words ‘What’s in it for me?” Let’s take a look at a simple example.

First of all, as I mentioned in the last article, we need to make some modifications to the SharePoint master page so that we can take advantage of the HTML5 goodness. It actually gets a bit more complicated than just changing the doctype and a meta tag. Luckily, SharePoint design guru Kyle Schaeffer has done the hard work for us and has published v5, the Responsive HTML5 Master Page for SharePoint 2010. For this article (and probably many following articles), I’m going to use Kyle’s v5 master page to help leapfrog us into HTML5-land. You should be able to follow Kyle’s instructions pretty easily to get v5.master up and running in your environment. Remember that you should only use it in a test environment for this exercise, as there are many reasons why using the v5 master may not be a good idea for your production sites today.

Once you get v5.master installed, the home page of your site ought to look something like this:


I’m keeping the look that Kyle’s given us in v5.master as is because it’s distinctive looking and we can easily tell that we’re doing something different. In addition to getting a great HTML5 setup, v5.master also gives you a responsive design layout. As you start to think about how HTML5 and CSS3 might help you to provide SharePoint support for different screen sizes, responsive design is one approach you might consider. (We should really pause here to give Kyle a big hand; this is truly great work!)

So, we’ve got v5.master in place and we can now take advantage of HTML5. (I feel a little like Julia Child when she says “I just happen to have a completed soufflé right here in this other oven.”) In thinking about what a “Hello World” for HTML5 and SharePoint might be, I struggled a little. Regardless what I chose, there had to be some up front work (borrowing Kyle’s v5.master page gets me past that) and putting the words “Hello World” on the page doesn’t show any real HTML5 goodness. I think I’ve settled on something simple enough, yet useful enough, to prove that HTML5 can really make your pages sing, and more easily than using other methods.

One of the things we get with HTML5 is some new attributes for input elements. Input elements are the things we use in HTML to get input from the user. So, for instance, the Title column in any SharePoint list is rendered on the list forms as an input element that looks like this:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255"/>

Once you get past the really long (and ugly) name and id attributes, the input element is pretty simple. It has a title attribute that contains the name of the column (‘Title”), a few CSS classes (“ms-long ms-spellcheck-true”), a type (“text”), and a maxLength (“255”). As far as HTML elements go, it’s about as straightforward as it gets.

Depending on your branding, the input element will render looking something like this. We’ve all seen it before.

Now, we’ve all visited sites where there is a helpful prompt inside the input element that tells us what we should plan to type into it.

It’s a great little mechanism to help a user to understand what they need to do next. We’ve all become very used to it and while we may not notice it after a while, it can lend a great assist. The nice thing about it is that the prompt text disappears when we put our cursor into the input element and it only reappears if we leave the element without typing a value.

SharePoint doesn’t give us this behavior out of the box, but we can make it happen with a little script.

var titleInput = $("input[title='Title']");
var promptText = "Please type a title for this item";

// When we click into the element, remove the prompt text if it is there
titleInput.click(function() {
  if($(this).val() == promptText) $(this).val("");

// When we leave the element, replace the prompt text if there is no value
titleInput.blur(function() {
  if($(this).val() == "") $(this).val(promptText);

// Set the initial prompt text if there's no value by triggering the blur event

That’s not too complicated, yet it’s more complicated than it seems like it ought to be. I didn’t have an example lying around, so I decided to write it from scratch, which took me about ten minutes. I needed to think about the edge conditions (what if there’s a value but it’s not the promptText?)

So what does HTML5 gain us that makes this easier? Well, there’s a new attribute for the input element called “placeholder”. To get the behavior that I wanted above, I can simply do this:

$("input[title='Title']").prop("placeholder", "Please type a title for this item");

Now you may be saying “Wait a minute. You’re still writing script!” Indeed I am, but it’s only one line of script. The only reason I need to use script at all is that SharePoint doesn’t “know” anything about the placeholder attribute. (I could write managed code to modify the Title column across the board, but that would be tremendous overkill and may not even be what we want.) All the script is doing is adding the placeholder attribute to the input element, and HTML5 takes care of the rest and we get this in the active DOM:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255" placeholder= "Please type a title for this item"/>

Well, HTML5 doesn’t actually do anything, but it tells the browser that it should do the prompt text thing. Unfortunately, Internet Explorer 9 doesn’t support the placeholder attribute yet (check the HTML5 Test again) so I had to run through this little exercise in Firefox.

And there’s the rub again. Since browsers don’t all behave the same yet, we have to consider which HTML5 capabilities we can use. Kyle’s v5.master loads HTML5 Shiv if the browser is IE < 9, but that doesn’t seem to fix it and I didn’t feel like monkeying with it to get it working in IE. In other words, there are still monsters here for those who are not wary.

So, there you go: a “Hello World” exercise, if you will. The real point (in case I didn’t make it well enough) is that HTML5 gives us easier ways to do some common tasks. In this case it’s a simple prompt in an input element, but there are more complex tasks (think playing videos, and more) that HTML5 will also make much easier. Stay tuned for more…

This post also appeared at NothingButSharePoint.com on 2012-04-18. Visit the post there to read additional comments.

Making Sense of HTML5 with SharePoint: Browser Capabilities

In my last article I talked about what HTML5 is and that it will help us get to a more  “Semantic Web”, but I didn’t explain what the W3C standards really mean. Partly that’s because the process is long and drawn out and murky at best. When I talk about the HTML5 recommendations and standards, maybe I should put “recommendations” and “standards” in bold, flashing text. The word recommendation is closer to the mark. Take that and the fact that the HTML5 standards are in draft mode, and there’s a lot of loosey-goosy-ness to the whole thing. I’ve seen quite a few people saying that the HTML5 standard will be finalized in 2022, and they aren’t really joking. That’s about par for the course if we look at the life cycles of past HTML standards.

What all that means for browser capabilities is that they are basically all over the place. While each browser team wants to support HTML5 (at least if they want to be as cool as the other kids), they each have different priorities and interpretations of the standard.

This post also appeared at NothingButSharePoint.com on 2012-04-03. Visit the post there to read additional comments.

The HTML5 Test

One good way to understand what this all adds up to is to look at a site that I found called The HTML5 Test. It’s not the only site out there that will tell you how your browser stacks up, but I like the way it gives an overall score and then breaks things out into easy to understand sections.

Because of my consulting work, and even more because of my SPServices development work, I have most of the major browsers on my laptop. Here’s how the versions of each browser I have stack up on The HTML5 Test:

Internet Explorer 9
Version: 9.0.8112.16421
Firefox 11
Version 11.0
Safari 5
Version 5.1.5 (7534.55.3)
Chrome 18
Version 18.0.1025.142 m
Opera 11
Version 11.62 Build 1347

While it may seem just like a gratuitous way to add a bunch of images to this article to make it longer, I thought it was interesting enough to include the details. As you can see, the scores are all over the place, and none of them are all that close to the maximum of 475. (If you have an eye for this sort of thing, you’ll note that even these snapshot images don’t look exactly the same, though they should.) Worst of all, our dear old friend IE9 scores the lowest. If you dig into the details of the scores, you’ll see that the variations are even harder to think through.

What this tells us is the we have to be very careful to understand what our browser base is for SharePoint if we want to take advantage of the goodness that HTML5 provides. (This is true of any so-called “front end” development that you do – you simply *must* know your browser targets and have good strategies to deal with them all.) I haven’t been able to find any typical browser distribution statistics for SharePoint on the Interwebs, but SharePoint itself can tell you what browsers are visiting your installation if you look at the Web Analytics statistics.

If you are lucky enough to be building your solutions in an organization where the supported browser base is proscriptive (e.g., everyone *must* use IE8 or Firefox 11 or something) then your job may be a little bit easier. However, as the BYOD movement takes hold, even that luxury is eroding. On the other hand, if you’re developing for an Internet site, then all bets are off. You’ll see everything from IE6 to Netscape to Opera to IE10 Beta and back again.

SharePoint and Browser Support

SharePoint 2010 itself, while it can be used with just about any browser, is really primed for Internet Explorer. If you look at the out of the box v4.master page, you’ll find several strong indications of this. In fact, these are the two first things you’ll need to change to start using HTML5 in SharePoint.

First, there’s the DOCTYPE.

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

This doctype tells browsers which standard to adhere to. In this case, it’s the XHTML 1.0 Strict standard. This setting precludes us from getting any HTML5 goodness. To enable HTML5, it’s a simple matter of changing the doctype to the simpler:

<!DOCTYPE html>

Next, the v4.master page has a meta tag in the header which forces Internet Explorer into IE8 mode:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

To allow IE9 to flex the HTML5 muscles that it *does* have, you can change this to:

<meta http-equiv="X-UA-Compatible" content="IE=9"/>

So Now What?

As I noted above, even IE9 doesn’t score all that well on The HTML5 Test. So how can we try to take advantage of HTML5 until Internet Explorer and all of the other browsers catch up to the moving target that is the HTML5 standard?

Well, luckily, there are people out there who understand these issues well and they have written some things that can help.The most well-known option is something called Modernizr.

Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.

Modernizer falls into the class of software known as “shims”. Shims let us use functionality which isn’t there for us yet by mimicking that functionality in a different way or otherwise filling in the gaps. Or, in geekspeak from Wikipedia:

In computer programming, a shim (from shim) or shiv is a small library that transparently intercepts an API and changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. Shims typically come about when the behavior of an API changes, thereby causing compatibility issues for older applications which still rely on the older functionality. In such cases, the older API can still be supported by a thin compatibility layer on top of the newer code. Shims can also be used for running programs on different software platforms than they were developed for.

Once the browsers catch up, the shim won’t need to do as much and eventually we’ll be able to get rid of it. (Don’t hold your breath – 2022 is a long way off.)

You can reference Modernizr in your master page to take advantage of HTML5 functionality that the browsers doesn’t yet provide. It’s not a silver bullet, of course. You still need to understand your target browser base and think about how you are going to use the new standards to get the best results. Knowing where in all that the shim is going to support you is key.

I’m not going to go into anything specific that Modernizr can help with in this article, but I will touch upon useful capabilities it provides as we see how we can use HTML5 in SharePoint as we go along.

Don’t worry; cool demo stuff is coming. I just think that we should understand the basics first.