For my final session of day one at the Australian SharePoint Conference, I took in Jeremy Thake's session on how NothingButSharePoint.com (NBSP) was built on SharePoint 2010.  Jeremy began the session by stating his goal as sharing what's involved in building an Internet-facing site on SharePoint 2010, the hurdles faced along the way (and how they were overcome), and the advantages of SharePoint 2010 as a platform. 

Conversations between Jeremy, Mark Miller, and Joel Oleson at SharePoint Conference 2009 in Las Vegas marked the beginning of what, a little over a year later, was to become NBSP. Back in 2009, Mark, Jeremy, and Joel were all running independent SharePoint communities, each on its own platform (WordPress, WSS 3.0, and Atlassian Confluence respectively).  Achieving unified messaging by combining the three different silos into a one-stop shop within a single platform was the goal of NBSP, and SharePoint 2010 was the obvious choice of platform.  Jeremy explained that NBSP launched in December of 2010, with a hosting environment donated by Fpweb and, in addition to Jeremy's own developer skills, involving the efforts of Marcy Kellar (UX), Heather Waterman and Corrie Haffly (concept design) and Kyle Schaeffer (refactoring style sheets, final CSS touches, and browser support) … all contributing their skills towards showing off what you can do with the look and feel in SharePoint 2010, and "how much you can make it not look like SharePoint."

Speaking on the topic of migration pain, Jeremy said that their particular challenge was "how to get the content out of the three different platforms and into this unified platform."  Rather than custom coding a solution, which would've been time-intensive, the decision was made to employ the migration tools available from Metalogix.  Having done so, a landing page aggregating the three content channels/silos (developer, end user, and IT Pro) became available in the unified presentation, with the option of diving into the individually branded silos if you wish. 

Addressing SharePoint 2010 as a WCM Platform, Jeremy explained that NBSP uses four site collections, one for each silo, and one root.  The challenge here was authentication, and rather than using AD, they decided to go with claims-based authentication via Live ID so as to not have to deal with the need to provision individual AD accounts, or with "idiots forgetting their passwords."

Regarding publishing templates, Jeremy shared the NBSP strategy of employing multiple content types and page layouts, and requiring content approval.  Contrary to Jeremy's assumption, however, it turned out that end users didn't necessarily know where to go in SharePoint 2010 to create new pages (whereas it had been obvious when the platform was WordPress), so training was involved.  Jeremy also pointed out that the "Extended Content Query Web Part is your friend," but that you should "really try to keep these things vanilla" and make use of the out-of-the-box features instead of jumping into custom development, which tends to make things "very brittle" when it comes time to move between major versions.

Jeremy then demonstrated the front-end form used to create a new article on the NBSP site.  Highlights included showing how seamless it is to get an image into SharePoint in 2010 as compared to the laborious process in the 2007 release, and how they leveraged managed metadata for the categories field.  Once all of the required fields on the article creation page were completed, clicking Save kicked off the content approval phase with a workflow.  Jeremy mentioned that "A little bit of training was necessary with the approval process as well."

With My Sites, Managed Metadata was leveraged inside User Profile properties.  The fact that this doesn't work anonymously is "kind of burning us at the moment" Jeremy said, although he also noted that forcing people to login to access content does build up the registered user base more quickly than would otherwise be the case.

NBSP is using out-of-the-box search at present, with search refiners in use, and Jeremy explained that the next release of the site will leverage FAST Search.

Regarding the Blogs Site Template, Jeremy said that since the out-of-the-box rich text editor is poor, there's no support for video media, and comments and RSS are also poor, the decision was  made to use Publishing Pages instead of a traditional out-of-the-box blog.

Speaking to the custom development efforts within NBSP, Jeremy explained that they: built custom Web Parts to aggregate data; employed a custom commenting engine that is iterated through by a custom Web Part (which will be made available shortly on CodePlex) including CAPTCHA to eliminate spam, which had been a big problem on EndUserSharePoint;  a "community equity" effort to reward Top Contributors to the site with recognition via a custom service application (site founders will soon be removed from inclusion since the algorithm is otherwise biased towards them as the most frequent contributors); use Google Analytics for Web analytics since "there are not enough stats in SharePoint 2010" (though Jeremy was quick to note that analytics in 2010 are "definitely improved" from 2007); are working on a "mega drop down" for complex navigation, leveraging search and Managed Metadata; employ a custom RSS solution since, by default, Publishing Pages don't support RSS and their custom solution renders all articles from the site or, by request, just the articles of a specific silo (or silos), as well as additional RSS feed possibilities, such as only subscribing to the site's podcast library.

Jeremy performed a demo showing how to Edit my Details on a user's Profile page after authenticating with Live ID.  Explaining that it's not possible to authenticate via Live ID if a site isn't on HTTPS, Jeremy said that's why NBSP is on HTTPS.  Once authenticated and on the Profile page, the desired user name should be set since it's not passed in via Live ID, and any additional changes to the Profile will then show up as the "Author Info" which trails each post on the site.

Social integration with Facebook, Twitter, etc. is in place on NBSP as a means to encourage the community to share the site content with others.  Since Twitter doesn't support HTTPS, they use Add This as a social bookmarking tool, which allows users to choose which social network  to share content with via a single Share This button.  They will also soon be adding Lightning Tools' Social Squared tool for their forums, which is "effectively a Web Part you add to the page which is feature-rich."

Some of the lessons learned around implementation that Jeremy shared were:

• Don't underestimate the importance of branding, and always use Visual Studio to package solutions. "Insist on solution packages," as Jeremy said, also recommending the CKS: Development Tools Edition add-on that's available for Visual Studio at CodePlex.
• Jeremy strongly recommends using Balsamiq to create wireframe mockups for SharePoint sites. They'll be publishing their own Balsamiq templates on the site so that others may benefit.
• Speaking of the starter Master Page, Jeremy said, "The Ribbon, as great as it is, does cause issues."
• Page layouts: One per content type for now.
• Web Part rendering: With XSLT, designers don't need to touch Dev code, which makes Jeremy a big fan of XSLT.
• Speaking of tools specifically, Jeremy said that, "Visual Studio 2010 has come a long way … please use it," and also recommended using SharePoint Designer 2010, "but take what you do in SharePoint Designer and put it into Visual Studio and deploy it that way" (via a solution package). Of the solution package recommendation for deployment, Jeremy said in no uncertain terms that it was "biggest takeaway" of the session, again stressing that you should "insist on WSP solution packages."
• Regarding source control, Jeremy also strongly recommends using source code. They use Mercurical using TortoiseHG. Jeremy uses it for release management, which captures every release in source control, and pointed out that it's "Free for up to 5 users, cheap for more."
• Automated builds via PowerShell allow for a replicated, working dev mirror of the production site.

In summary, Jeremy said that you need to "really set those expectations up front" for public-facing SharePoint 2010 sites, also pointing out that "You'll need the right resources up front," cautioning that you can't assume your existing developers and designers will be able to do what's required.  Additionally, Jeremy recommends that you set realistic timeframes, and set up a communication plan, which is especially important for geo-dispersed teams such as the NBSP team.

For interested readers, Jeremy also mentioned that he has authored a series of NBSP: How We Did It posts on the site, in which he goes into much greater detail (including code snippets).