I’m at MIX! Got in late last night. Wow, Vegas is nuts. So gaudy – lights, sounds, smells everywhere. It’s pretty overwhelming. The Venetian is fantastically humongous. I have to walk a mile from my room to the part of the hotel where MIX is actually taking place. First time in a 5-star hotel for me, so I am pleased.

Right now I am sitting in the keynote session waiting for it to get started at 9:30 PST. There’s a pretty cool “screen saver” thing that is loading live Twitter comments from MIX attendees and displaying them on the screen in real-time. Pretty cool. Not a big Twitter fan myself, but it’s certainly being used in interesting ways here at MIX.

There’s a three piece band playing with an accordion, violin, upright bass, and assorted other instruments. One attendee described it as a love child between Tom Waits and Oingo Boingo. Did I just hear a glockenspiel? A freakin' Theremin too? Fantastic…

Well, keynote should start shortly… More coming up…

Exciting news! My session for MIX ‘07 was approved, so it looks like I’ll be in Vegas at the end of the month. Unfortunately, it’s sold out, so if you’re not already registered, you’re unfortunately out of luck as far as I can tell. However, I’m told all sessions will be recorded and available on the web for everyone to see as early as the day after the session, so I’ll post a link to it here for those who are interested.

The title of the session is “Internet Sites with Microsoft Office SharePoint Server 2007,” which is sufficiently broad that there should be plenty to talk about. Do you have specific things you’re interested in learning about, or that you think I should talk about in my session? Feel free to drop me a line and let me know. I’ll also be at the MIX Chat on Wednesday afternoon, so swing by and say hello.

And if you want to see some particularly poor yet frenetic dancing, join me at PURE on Tuesday night. Believe me, there’s nothing quite like a Microsoft Program Manager out on the dance floor…

Way back when I wrote part 1 of my series on building tylerbutler.com, I mentioned that I was using a custom sitemap provider to drive my “recent pages” section on my site. I was doing this with navigation because navigation controls inherently know where they are in a site’s structure, which meant I only needed one control in my master page to drive the links in the right hand section. I was using the DynamicChildLimit property to make sure I only got 15 links to show up in that section.

Unfortunately, I started having problems with the ordering of the links that were showing up, so I started talking with Chris Richard, the nav maestro. It turns out that the DynamicChildLimit isn’t meant to be used for that purpose. When you sort navigation, the sorting happens after the nodes are returned from the nav store. This means that if you have 50 navigation items sorted by last modified time, and you set a DynamicChildLimit="15", for example, you’ll get back 15 pseudo-random items, then those resulting 15 items will be sorted by last modified time. I say a pseudo-random set of items is returned because even though items returned aren’t really random – there is a deterministic way nodes get returned from the nav store – it’s complicated enough that you won’t be able to tell what 15 items will be returned at any given time.

Anyway, this means that DynamicChildLimit doesn’t really work the way I thought and it makes navigation unusable for my needs in this instance. However, a helpful guy named Bram Kleverlaan left a comment on my Part 6 post that he was able to use a SharePoint expression to make Content Query Web Parts know where they are in the site hierarchy. The trick is to set WebUrl="<% $SPUrl:~Site/ %>" in the web part’s properties. This expression will get expanded by SharePoint at runtime, and your CQWP will suddenly change based on the location of the page that’s loading it. I definitely had a “Why didn’t I think of that?” moment when I read Bram’s comment.

Anyway, I am using this now on my site, and I can verify that it works for web parts that live outside of web part zones. I have not yet tried it on a web part inside a zone, but I’ve heard reports that the property gets reset every time you change properties on the web part in the browser, which you can’t do for parts that live outside zones.

Now that MOSS is available to lots of people, and people are building lots of sites that don’t look like SharePoint, a lot of you might be wondering how you should get started in building your own custom master page for your site. I talked a little bit about this in my first post on building tylerbutler.com, but I think it might be valuable to post some info about the minimal master page and its role in helping you build a custom master page for your site. But first, some background…

During the early betas, people heard that you could make SharePoint “not look like SharePoint,” and so they set off to do just that. People started cracking open default.master and trying to understand it. The problem many people reported was that the markup in default.master was ridiculously complicated, and it wasn’t clear what could be removed and what couldn’t. The complexity is somewhat necessary for that master page because of all the delegate controls we have to put in place to support a bunch of different back-end SharePoint stuff (I do believe, however, that there’s plenty of things we could/can do in that master page to make it clearer and easier to customize without removing functionality, so this is not meant to be an excuse).

Anyway, there were customers that were trying to build internet facing sites on top of SharePoint, because a) we told them that they could/should and b) we rolled up a lot of web content management functionality from Content Management Server 2002, and customers that were using that product were investigating how they would move to MOSS. These customers did not want their site to look anything like SharePoint. These customers also often had a site design template that was coming from their design team, either in HTML or as image mock-ups. Trying to fit that design into default.master was exceedingly difficult because of all the unclear markup in that master page. Default.master is designed for a SharePoint site – one that looks and acts like SharePoint. But people who wanted to build non-SharePoint looking sites were getting tripped up by using it as a starting point.

We do have several master pages that we built that are much simpler than default.master. When you provision a Publishing Portal site collection, for example, we default to BlueBand.master, which has customized CSS and MOSS navigation out of the box. It’s a cleaner starting point, so we initially told people to start there rather than with default.master. We still had problems, though, because you never knew if a placeholder was absolutely necessary in your master page. What would happen is you’d remove a seemingly innocuous placeholder and your page would work fine until you browsed to some specific page that was overriding that placeholder, then things would break.

What we needed was a sample master page that included only the markup that was absolutely necessary to get your pages to render. Thus, the minimal master page was born. This master page is purposely bare. It’s just a bunch of placeholders – those placeholders are necessary for things in your site to work properly. With this master page, you can take your markup from your designer, paste it into SharePoint Designer, and move markups into the appropriate placeholders. If there’s some pieces you need/want from default.master or another page, you can always open them up and copy/paste the appropriate markup.

So, should you start with default.master, blueband.master, or the minimal master page example when building your own custom master page? Well, the answer depends on what you’re trying to do. If you’re building out a site that really should look and work like vanilla SharePoint, then maybe default.master makes sense. If you’re trying to do something more exotic, blueband.master and its siblings have examples of different navigational structures and color schemes, so maybe it makes sense to start from one of those that is close to the navigation/color you’re aiming for. But my personal recommendation is to start with the minimal page and copy/paste the appropriate controls/markup from other master pages as necessary. This ensures you get only what you need and want in your page, rather than having to weed through a bunch of markup to get rid of stuff that doesn’t look like it’s needed. If you do want to go the default.master route, then Heather Solomon has a custom master page that she’s tweaked from default.master to make things cleaner and more straightforward.

I hope this helps you figure out how to get started building out your site look and feel. There is a growing number of live custom sites on top of MOSS, and it’s exciting to see what people are able to build with this product!

Someone came by my office today and asked me if I could show him how to make a column on a SharePoint list required. No problem! While this isn’t as simple as it could be, it’s pretty straightforward. Go into the list you want to change, select List Settings from the Settings drop down, then click the column you want to change in the List Settings page. You should see an option called “Require that this column contains information.” By default, this is off, but turning it on will make the column required.

However, in this case, that option wasn’t showing in the UI. The reason was that the column was a Yes/No (check box) field. Now, if you think about it, this makes sense. A checkbox always has state, either checked or unchecked, so it’s by nature required. A user always has to fill in a checkbox with some data, either by checking it or unchecking it. It all comes down to the default state, which is settable in the SharePoint UI.

The interesting thing here, though, is that the user didn’t stop to think about this. And that makes sense. He just wanted to make a column required; he didn’t think about what type of column it was. SharePoint totally removes the required field setting from the UI for Yes/No fields because it doesn’t make sense. However, the user got confused. He wasn’t sure if the UI was missing by design or if he wasn’t looking in the right spot for the setting. If you have a task to accomplish using relatively unfamiliar UI, you go to the place that makes sense to you, but you’re never sure you’re in the right place. In this case, the user poked around other parts of the UI before coming to me, because he thought he was looking in the wrong place.

This might be alleviated by disabling (i.e. graying out) the part of the UI that is not applicable. This is somewhat clearer, because it says, “Yes, this is where you would change this setting, but it doesn’t make sense here or is not allowed.” This isn’t a hard rule. You can’t always display all possible settings in one piece of UI because if there are a large number of settings, things can get confusing and distracting. Some hiding does make sense in many cases. But it is worth some dedicated thought about your UI and what your users are trying to accomplish when deciding whether to hide a piece of UI or simply gray it out.