Fear and Loathing

Like the SharePoint team finally did, the InfoPath team has stepped up to the plate with their first blog entry on the next gen for form entry, InfoPath 12 (okay, so it’s a codename the real name will be known soon enough). For some of us this is old stuff but for those that haven’t seen it, InfoPath 12 will deliver the same rich client experience forms you get today but in a web browser. Nice.

What’s really slick is the additional platform of targetting mobile devices (as seen above). This really opens up the possiblities for doing some seriously cool stuff with forms.

Forms that live in SharePoint form libraries.
Forms that can be delivered to your mobile device.
Forms that can have workflow attached to them.

Yeah, that just plain rocks.

Be sure to bookmark the teams blog here or subscribe to their feed here with your favorite aggregator (go ahead, click on it you IE7 guys, I know you wanna…)

I’ve been meaning to do this blog for awhile and it’s a long one so better get a fruit flavored drink of your choice and curl up on the couch with your laptop for this one. Sorry, I do apologize for the rambling (and length) as this post has now encompassed a couple of hours of my time and I’ve been bouncing up and down the text like Tigger on crack. Caveat lector.

Terminology

One thing I want to stress as I go through this posting. I’ll use the term SharePoint throughout this post but it really will refer to both SPS and WSS capabilities. I’ll also use WSS and SPS where I talk about specific features so just keep that in mind as you fall asleep halfway through. Also note that most of this article discusses the current version of DotNetNuke (3.2.2 and 4.x) and SharePoint (SPS 2003 and WSS 2.0) but there’s mention of the v-Next flavors of SharePoint that will be coming with Office 12. I mention these because in some cases, they do level the playing field and create almost exact setups from what DotNetNuke has (for example with membership providers). So it’s a little hard to draw the comparisons without talking about it, but I’ll leave it as an exercise to the reader to draw your own conclusions given all data points. Hopefully it won’t be too confusing.

DotNetNuke

Microsoft introduced ASP.NET and people saw the potential, but they’re not completely sure about how to leverage it. Do we just rebuild our “classic” ASP apps using this new tool. What can we really do with it? Up until this point, anyone building a “portal” application would have done it manually. You all have done it because I’ve seen it time and time again. Corporate intranets built from ASP or even ASP.NET from the grass roots. I’ve even seen “web part” like implementations long before there were these funny doofers that people could drag and drop on web pages interactively.

Enter DotNetNuke. The amazing ASP.NET portal that spewed forth from IBuySpy. Okay, a super brief history lesson. Microsoft puts together a “portal” application to show off ASP.NET and it’s called IBuySpy, a fictional shop for purchasing spy type products (x-ray glasses, hidden microphones, that sort of thing). This app has a few key features showing off ASP.NET like being able to dynamically add “modules” to pages creating content, hide visibility based on membership, and provide simple site navigation (without having to manually edit pages to do any of this). IBuySpy is a starter kit and lets people build off it to create their own storefronts and portals. Life is good.

December 2002 rolls along and Shawn Walker forks the code, creating a VB.NET implementation with a few enhancements, and dubs it the IBuySpyWorkshop. The development community starts to froth at the mouth (as we often do with cool things) and thousands of downloads ensue (think Slashdot effect). It’s an immediate success and eventually evolves into it’s own product which is then renamed to DotNetNuke (this is a brief history, for a more concise one check out the DotNetNuke page or Shawn’s book). Since then, a few other forks have appeared all based off the IBuySpy codebase including Rainbow, etc. and I’m sure there are others. In any case, it’s a big hit and has some great features. Both DNN and SharePoint have a vast number of features where they align, and some other areas where they don’t. Let’s take a look at some of the differences and similarities and what makes each stand out.

Modules vs. Web Parts

A rose by any other name would be the same. Okay, so that’s not the quote but it works for me. DotNetNuke calls them Modules, SharePoint calls them Web Parts. They’re essentially the same thing. A .NET assembly (or assemblies) that makes up the logic and presentation for a function that can be placed anywhere on your portal.

A SharePoint Web Part, just like a DNN Module, is a component that can be used in a site. In DNN you add them to pages, in SharePoint you add them to Web Part pages. Same concept as they offer positioning, personalization, minimize capabilities, etc. DNN has a few extra baked in features that a SharePoint Web Part could use like RSS feeds, custom containers, and a print capability. Again, in vNext RSS is built into the entire system so your SharePoint Web Parts will now be subscribable, much like DNNs modules today.

The big advantage that SharePoint has over DNN is that DNN modules can only be used in DNN. SharePoint Web Parts can be used in other systems that use Windows SharePoint Services as a foundation (Small Business Server, Project Server, etc.). While you can’t use all Web Parts everywhere, if it works in WSS it will probably work in SBS. This feature actually becomes even more of an asset with vNext as ASP.NET Web Parts can be used in both ASP.NET apps as well as SharePoint sites so you’ll be able to say expose a data source in a business application and (depending on the codebase of course) drop it onto a SharePoint page without hassle. Again remember that this is all very dependent on how you build your Web Parts but I don’t see DNN modules being used anywhere but DNN, even with Version 4.x that is built on ASP.NET 2.0.

Having played my SharePoint Web Part card, I have to say that adding modules to DNN is a snap with it’s Private Assembly (PA) approach. Basically you package up the Module a certain way and a Host can upload it and make it available to any or all portals running under it. This is all done at runtime without the system going offline (which includes adding new tables to the database, etc.). This is great although I’m sure you could exploit this with a rogue module. Compare this to the fairly daunting task of a) adding an assembly to the bin directory or GAC b) adding the SafeControl entry to the web.config file and c) potentially doing an IISRESET or recycling the Application Pool. Now if someone were to build a “Upload Web Part Web Part” that would be something (hint, hint).

I won’t talk about developing Modules vs. Web Parts as I get into it below but it’s all very similar from a conceptual point of view (ASP.NET, User/Server Control, yada, yada, yada)

Core Modules

DotNetNuke provides about 25 core modules. These are available out of the box and ready to put onto any page by an end-user. The later releases (3.x and up) came with templates and a wizard to walk you through applying a set of pages and skins to your site immediately. This is very similar to a site or area template in SharePoint. SharePoint provides a stock number of list and document library templates along with a set of instances of these (based on the site template you select).

You might say DNN has more modules than SharePoint does but if you look at the DNN modules most can be achieved with a custom list and perhaps some custom views tossed in for good measure:

It’s not an exact match, but it’s close and I would say each has advantages and disadvantages. An adventurous soul (not me, I have way too many projects on the go) might put together a custom SharePoint site template complete with the custom lists that DotNetNuke offer in a default DNN setup. There’s really no magic here although there some core DNN modules that you don’t need or have with SharePoint (like a login module). For the others, a custom list would pretty much give you similar functionality.

Putting on my DNN hat, I could say that you could add custom modules and perhaps tweak the codebase of DNN a bit to provide similar (but not 100%) funcationality of DNN that SharePoint has. After all, some of the Office 2003 integration is just done through ActiveX controls so nobody says it’s a “SharePoint” thing (for example, I’ve used the Address Book feature on a standard ASP.NET app before).

The only true gem that stands out here is the Office integration that SharePoint provides today and that may be compelling enough if you’re a MS shop and deal a lot with Office documents and Outlook contacts. You would probably have to go a long way with modifications to DNN to provide integration to Word (if that would be possible at all) and enable Word to check in a document to DNN (not saying it’s impossible, but certainly not a simple task).

Visibility

This is the primary feature in SharePoint that is missing today. In SPS we have Audience targeting and some security features to hide areas, but more often than not (and especially in WSS sites) the user sees more than he should. This is called Security Trimming, only show the end user what he can do and don’t let him get 5 steps into a Wizard only to tell him he doesn’t have access to complete the process (man does that bug the crap out of me).

Anyways, in DNN we have the ability to target modules to roles or inherit the pages security settings (which can also be targeted to roles). There is no individual user targeting here, so you have to define a role and assign that role to a user for him/her to see (or not see) a page or module. It works quite well and is vastly used on systems where clubs present information to members only, but the general public gets a different view until they register or otherwise are granted access.

Security trimming is there in SharePoint vNext (finally!) so again, the playing field is level.

Custom Look and Feel

This is a tough one but I have to give it to DotNetNuke as the winner (for now, see note below).

DNN uses something called Skins, very similar to Themes in WSS or using custom CSS files in SPS. However DNN Skins go one step further and let you design the layout of the page, including pulling in modules and controls (like the current date/time and a login control that shows who the user is or a logout button if they’re already recognized). Building a Skin for DNN is pretty basic and can take anywhere from a few minutes to a few hours (depending on how complex you create it). The great thing with DNN is that it uses the skin for every page in the system (primarily because the architecture of DNN runs off a single page). In any case, you don’t get the level of granularity in Themes vs Skins and frankly it’s easier to create a fully customized Skin in DNN (I built the WSS Skin for my personal site in about an hour).

Of course, we have to talk about SharePoint vNext as it fully utilizes ASP.NETs Master Pages so basically once that hits the streets, all bets are off. Apply a master page and instantly, Bob’s your uncle.

Infrastructure

You really can’t compare the two products on this level as SharePoint scales out to gargantuan sizes (Microsoft itself runs SharePoint for internal teams and has something like 250,000 team sites worldwide). Yeah, DNN is for hobbyists and in some cases can be used for corporate intranets, but I would want to try to scale it out to run the likes of IBM, Boeing, or NASA. A small corporation with a few hundred users, why not?

However as far as hardware goes, you can really only scale DNN out to 1 web server and 1 SQL server. There’s really no features like Enterprise Search, Single Sign-on, or separate indexing like SharePoint has so that’s the limit from an architecture point of view on DNN.

DNN provides many of the infrastructure items that ASP.NET has. For example logging. DNN provides a mechanism handling vendor ads and ways for them to pay for it. DNN also provides mechanisms to handle subscriptions so that users can access premium areas of the sites. You have to build these items for yourself in ASP 2.0 (again, it’s not difficult to build this, but does require “work”).

The best part about DNN is that a normal user can actually use it to add/edit/delete content out of the box. You can give them a demo and turn the mundane tasks over to them. You can accomplish this with SharePoint as well but for some reason a lot of people seem to scratch their heads at SharePoint. Maybe I’m just dealing with the wrong people.

Community

You would probably agree that the DotNetNuke community might be bigger than the SharePoint one (or perhaps more/less mature). Maybe this is true as there are literally thousands of DNN sites out there running eCommerce sites, club sites, and personal home pages compared to probably hundreds of SharePoint sites. This might be a result of free vs. $$$ for extranet licensing along with some other factors. I would say finding SharePoint vs. DNN content is about a wash at this point.

As far as Modules and Web Part availability go, this is a pain point for me. SharePoint has it’s fair share of commercial vendors. Guys like ADVIS, OmniSys, CorasWorks, etc. are founded on building extensions on top of SharePoint. As for DNN vendors, there are a few with most of the modules coming from SnowCovered (a reseller) however most that I’ve found are poorly documented or just hacks that someone has put together to make a few bucks (yes, I’ve purchased modules from them just to test these waters but I’m not saying all vendors are like that). That’s the problem I have with DNN modules. There’s a ton of them out there, but they all seem to do very similar things and some are completely unnecessary. For example there’s a Google AdSense module. However with AdSense, you get the HTML code you need for it so you can just slap it into Text module in DNN or a CEWP in SharePoint. I find most DNN modules don’t really add much value or function, but on the flipside they’re usually pretty inexpensive. On the other end of the spectrum, SharePoint Web Parts generally go the distance with replacing built-in functionality (like Ontolica’s Search) and really increasing the functionality of your portal, but this comes at a hefty price usually pushing up into the hundreds if not thousands of dollars.

Maybe what bugs me more is the fact that I have to register on every freakin’ DNN site out there to get a demo of some module (or a free download). Believe me, I have hundreds of DNN sites that I’ve registered on just to see what they have to offer. Maybe I can’t blame the product for that as people can choose to leave their modules open for download without having to register, but then they lose the tracking feature.

This might be a sign of things to come should there be an influx of WSS v3 sites and user registrations with the new ASP.NET 2.0 providers so we’ll see where that goes. Come back in a year or so and let’s see how many SharePoint sites you’re registered on.

The other pain point is Skins and Themes. I’ve stumbled across maybe a dozen or so free Skins for DotNetNuke (with only a handful of them being any good) but there are some vendors/individuals who offer up custom Skins for a price. The SharePoint fence isn’t much better with probably the custom Themes Shane put together a few months ago being the best offering I’ve seen in a long time. So why don’t we have a repository of SharePoint Themes (well, WSS Themes technically) that are as plentiful as these Web Template sites that I get spammed about wanting to sell me thousands of site templates for a few dollars. That’s just not right.

ASP.NET

The question of ASP.NET 2.0 might come up in discussion as we compare these two creatures. In 2.0 I can drop a DataGrid on a page, bind it to a business class with my ObjectDataSource using Generics, have it fire on select, update, and delete methods and write a little code to make it work (and by little, I really do mean little). Toss in master pages, web parts, and themes and I have pretty much what both DNN and SharePoint have to offer. So why would I use either?

In some cases, it makes sense to build something but think about what SharePoint gives you. I can create a list without having to have discussions with my DBA and model my system. I can have grouped views of the information and publish it in varies ways. I can even consume those services and present them a completely different way (say as a lookup field in an InfoPath form). In other words, I can do a lot of the heavy lifting that I would have to do in ASP.NET 2.0 but without having to do it, if you get my meaning. Same as DNN (except substitute “Modules” for “Web Parts”).

There are compromises here as a SharePoint list or a DNN custom module doesn’t have robust referential integrity nor can it easily talk to my legacy application and make calls to an SAP API without having to write all that stuff. Those compromises are what software development is about. Buy vs. Build and all that. If I already have something that can come pretty close to what I need, why build it. If I can extend what I have (like write a Module or Web Part to talk to my legacy system) then all the better.

So rather than starting with a completely blank page using ASP.NET 2.0, you can start with a blank site or portal then extend it to meet your business needs. Its the foundation that these frameworks already provide that will enable you to hit the ground running. Who really wants to code a “Feedback” page or “Members” module/web part when you can simply add one dynamically. Grant you, some people will say that they can just download someone’s User Control and drop it in, but then are you now just not getting back into building your own Portal? In the end you’ll find that to be a much easier model to sell in terms of productivity to leverage what you can get for free (although there is a steep learning curve with anything and SharePoint or DNN is no exception).

Development

Which is a good transition into development. Both DotNetNuke and SharePoint are .NET based so both use Visual Studio as an IDE to build from and the framework to build on. As much as we all bitch and complain about how hard it is to create SharePoint Web Parts, personally I find DotNetNuke that much more complex. Take this Code Project article for example. It’s entitled Creating a DotNetNuke Module - For Absolute Beginners! The article is MAMMOTH and contains about 30 steps just what seems like a simple Guestbook module together. Wow. What a faceslap to the “simplicity” that DotNetNuke is supposed to be about. From a user perspective it’s good, but from the development side of the fence it’s madness.

One users experience was documented here on installing and setting up his environment. Grant you, he mentioned that he didn’t completely read the instructions and if you do follow the 35 page manual that Shawn has put together it (mostly) works. The thing is that this is 34 pages too long. When you actually have an template in VS2005 to create a module for you, why is it still so freakin’ complicated to get it up and running? To be fair SharePoint has it’s issues but they’re generally more specific like Code Access Security but to get a Hello World Web Part put together for SharePoint takes about a page (and that’s writing it up for Dummies to follow IMHO).

I mean, yes, we as SharePoint developers scream about how difficult impersonation is and how some APIs don’t work right or are not documented correctly. Yes, it’s an ugly world we live in and sometimes a PITA but nothing compared to the steps in this article. And this isn’t the only article or approach. I’ve gone through the official document and module creation and the Code Project article isn’t over complicating things. It really is that immense. For a SharePoint guestbook you could just create a list, modify the fields and if you really, really, really wanted write a Web Part of all about 50 lines of code to present the guestbook (you could probably just slap together a DataView Web Part in FrontPage with no code and call it a day, but let’s compare apples to apples here). Feel free to challenge me on this, but as far as developing DNN Modules vs. SharePoint Web Parts goes, even writing out HTML in code is better than the hoops you have to jump with DNN.

I can hear the OSS zealots out there now. Oh but DNN is Open Source (=good) and SharePoint is Microsoft Closed Source (=evil). Personally I think this is a non-issue. If you seriously are looking to sell someone don’t try to pitch them on the fact that you can crack open DNN and start making modifications whereas you can’t with SharePoint. Trust me, it’ll take more time to “add” a feature to the DNN codebase than its worth. There’s also the discussion around learning from DNN but I’m not very happy with how the codebase has evolved and frankly from some peoples experiences (and mine) just from building the codebase or trying to build a module for it, it seems to be a result of over-engineering and many extra unnecessary layers. It’s not to say SharePoint isn’t similar but SharePoints implementation of tables inside tables inside tables are presentation problem, not architectural issues.

If you really want to learn from something like this, get Visual Studio Express and install the Personal Web Site Starter Kit or something. Less code, similar functionality.

Bottom Line

DotNetNuke has it’s place. SharePoint has it’s place. Both are great at what they do and they seem to overlap in some areas, while completely living in their own space in others.

Currently. If you want an externally facing website where you want the standard message boards, blog, calendar, feedback, and files (and users can optionally register online), then I would say DNN is for you. CommunityServer has some of these and the latest beta looks like it’s approaching something usable like that as well however I haven’t seen a lot of add-ons for CS (or the add-ons were bastardized patches, much like how there are add-ons for phpBB to turn it into something other than a forum). The CS community isn’t as expansive as the DNN one is either as it hasn’t been around as long. You could probably do well with either if you’re looking for a simple community site for say a club or something but DNN does feature more modules (at a cost as you can see above) and more extensibility than CS does so if you’re planning to go beyond the OOTB experience, you might be better off with DNN.

As for DNN vs SharePoint, it’s a toss up. There are both pros and cons to each. In the current incantation, you need Active Directory behind SharePoint but that changes with the next version so you can go to a more “register and login” model like DNN has.

I think the Private Assembly feature of DNN is killer in that I can download/write/purchase a module and have it on my site in minutes without asking an IT guy to reset IIS or modify a web.config file for me. That alone sets DNN apart from SharePoint right now. Again, however, the feature system of SharePoint is going to allow this kind of approach but I don’t see it getting as simple as DNN is today.

Like anything, choose the right tool for the right job. Obviously DNN isn’t as scalable as SharePoint is and it can’t search file shares, web sites, Lotus Notes databases, etc. but then it also can’t be setup and running on an external web host where you don’t have console access in 10 minutes like DNN can.

Choose, but choose wisely.

Also be sure to check out Richard Dudleys post on DotNetNuke and SharePoint here as he puts together a good summary. His place is generally DNN for extranet, SharePoint for intranet. I would agree for the most part and it’s a good rule of thumb to follow if you’re into that sort of approach.

Update: Come to think of it and reading over Richard’s blog post again he really does touch on the main points I listed here (cost, Office integration, authentication, skinning, etc.). He just does it in a much more compressed and easy-to-consume-in-one-sitting read. Kudos to Richard.

OOTB: Out of the Box
CEWP: Content Editor Web Part

Whew. We finally got our second episode of Plumbers @ Work, Right Planet, Wrong Universe now online. Took awhile but it’s now available on the Community Radio at MSDN Canada site. You can listen to it directly through this link. Also the RSS feeds on the MSDN Community Radio site seem to be fixed now so feel free to subscribe here (I checked and it works great in iTunes). We’re just updating our Plumbers @ Work main site now to post it there as well.

Here’s the rundown of our second show:

• Introduction
• The Plumbers are In - Bil, James, and John Report; Dan is MIA
• Living the 2005 Canadian Launch Tour
• The Performance "Gardener" Has Left the Building
• CTP Hell is Over
• WPF, WCF, and WF! Oh My!
• "Office 12"
• MSDN and TDD
• Google Analytics
• Marketing BizTalk Server 2006
• ASP.NET Web Administration Tool
• James Gets Excited about Virtual Server 2005 R2
• Half-Time
• WinFX, Part Deux: Visual Designers
• Clemens Vasters' "Soccer Anywhere" Project
• Microsoft Application Verifier (Bounds Checker on the Cheap)
• PromptSQL: Intellisense for T-SQL
• Visual Studio 2005 Add-Ins
• SharePoint Adventures with the DSL Toolkit
• Taming the "Wild" Corporate Developer with VSTS
• SQL Server 2005 Service Manager and The Case of the Missing System Tray Icon
• Orb.com
• Xbox 360, Where Art Thou?

We’re working on putting together a schedule so we can be more consistent with the episodes. There was a big gap between our first one and this one, mainly due to the holidays but we’re looking to do regular shows every few weeks or so and will have those online for your listening pleasure. With time we’ll get better at the podcasting as well as our schedule of posting the show!

Well, that’s the plan anyways.

Sometimes I really wonder how I get the neurons firing in the morning. I completely forgot about this event here in Calgary tommorow (thanks to Monty and Lindy for the reminder! I owe you guys a coffee, beer, small furry animals, whatever). And here it's all about collaboration (including, yeah, SharePoint).

Tommorow I'll be at the Microsoft TechNet Canada Event, TNX Exchange. This is a pretty cool tour focusing on communications and collaboration with Rick Claus presenting 5 sessions on Active Directory, Exchange 2003, Live Communications Server 2005, Internet Acceleration Server 2004, Office Communicator 2005, and of course SharePoint Portal Server 2003.

Not sure if registration is still available at this late date but check out the website here (Calgary registration can be found here). Again, sorry for the late notice here as I was napping. Feel free to send me rude feedback and hate email.

Creating SharePoint Web Parts and Controls can be tedious at best. Lots of compile, click, refresh, going on. Two tips I wanted to pass along to budding developers today.

Commented out controls still evaluate
Let's say you're writing a new Control and embedding it on an .aspx page like so:

<%@ Register Tagprefix="ABC" Namespace="..." >
<ABC:MyControl runat="server" />

Let's say we want to turn this control off so naturally you might do this:

<%@ Register Tagprefix="ABC" Namespace="..." >
<!-- <ABC:MyControl runat="server" /> -->

In fact, the control is still executed by ASP.NET (or the SharePoint ISAPI filter, I'm not sure which) and whatever output that control creates will go onto the page. Grant you, it's still wrapped in comments but if your control is throwing an exception, you might be scratching your head wondering why it's doing this. So to be safe, just comment out or rename your Render method your code (Note: if you don't inherit from SPControl you might not get any output, but then why are you not inheriting from SPControl?).

Web Parts that output nothing still output something
Another quirk is the base classes in SharePoint. All Web Parts are inherited from WebPart so even if your RenderWebPart or CreateChildControls method does nothing you'll still end up with output something like this on the page where a Web Part lives:

<table TOPLEVEL border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top">
<div WebPartID="00000000-0000-0000-0000-000000000000" HasPers="false" id="WebPartWPQ1" width="100%" class="ms-WPBody" allowDelete="false" style=""></div>
</td>
</tr>
</table>

So just watch that your WebParts will still render even if you're code doesn't output anything.

It’s Tuesday and rather than bring you original content like any good-minded blogger would, I’m here to rehash a bunch of other news that everyone else has already told you 3 times over (and rip through my inbox fulfilling everyone’s shout out requests). God I feel dirty.

Joel does Calgary
Joel Semeniuk, Microsoft Regional Director and Visual Studio Team System guru, will be in Calgary giving a talk on Wednesday, January 25, 2006 from 5 to 8pm about Visual Studio Team System. This will be a great opportunity to hear about what Team System promises to bring to our world. If you're a current MSDN Universal subscriber, you'll be getting a free upgrade to VSTS Developer. So might as well learn what you'll be getting.
 
http://www.jameskovacs.com/blog/VSTSAndJoelSemeniukComeToTheCalgaryNETUserGroup.aspx
 
Registration is available on the Calgary .NET User Group web site: http://groups.msn.com/dotnetCalgary. (Please register ASAP)

First UK SharePoint User Group Meeting
The SharePoint User Group UK would like to invite you to the first user group meeting hosted by Microsoft at Thames Valley Park in Reading. Held on the evening of Monday 13th February, talks will be given by Steve Smith and Brett Lonsdale of Combined Knowledge on the topics of SharePoint Farm Design Best Practices, and Developing WebParts using User Controls. Attendance is free, with Microsoft supplying refreshments and nibbles at half time. Please check the forum for the full agenda, and post a reply there to register your intent on attending.

http://suguk.org/forums/72/ShowThread.aspx

Be like the Fox
Bob Fox has been an avid reader of my blog (or so he says) and he’s been a great help in the SharePoint community. His web site and blog has a lot of great SharePoint info so you might want to add him to your blog roll. Hey, and its just cool when your name is Bob Fox. The marketing for that just writes itself.

Web Site
http://bobfox.net/spnj

Blog Site
http://www.mycblog.com/blog/Foxhole

Now re-entering… CTP Hell
Microsquishy has put out (yeah, like you wouldn’t want that to happen) the Community Technology Preview releases of Microsoft Expression Graphic Designer (Acrylic) and Microsoft Expression Interactive Designer (Sparkle). There’s also a couple of other designers coming shortly and sometime after the release of the public beta of Office 12/SharePoint V3/etc. they’ll probably be more.

Is it just me or has Microsoft gone goofy with all this naming. First they come up with some pretty cool code names (Avalon, Acrylic, Sparkle, Indigo, etc.) but then turn them into 10 syllable phrases that are sure to take up more than a few lines on DVD packaging. What brain child dreamed this design up? Can you imagine the marketing boardroom pitch on this?

Marketing Guy #2: Okay, we’ll come out with all these products with cool names like Avalon and Indigo

Stuffy Executive Type: Yes, sounds good. Make me money, make me money.

Marketing Guy #3: And we’ll release early builds so we can convince all the droogs out there to log our bugs for us and save us having to hire teenage Haitian workers for 6 cents a day.

Stuffy Executive Type: Go on!

Marketing Guy #1: And just when things are ready to go out the door, we’ll turn those crafty code names into extremely long winded phrases that will confuse buyers and make presenters mispronounce them in public. It’ll also mean you’ll need two slides in a powerpoint deck just to show the name of the product.

P.S. Bought a copy of BlogJet as it’s really working out well. Hopefully it’ll stop the spam I keep getting from Dmitry about new features and cool things you can do with it. Ahh, the price of freedom.

P.P.S. Will be releasing a raft of software shortly (I’ll leave it up to your imagination to define “raft”) and will be using cool codenames as it’s all the rage now. Watch for SharePoint Builder, the “Twinkie” build soon (and feel free to suggest some codenames as I’m the last person to come up with an original idea).

I generally try to use Scrum with most of my projects. Even if they’re my small, one-man pet projects I still follow Scrum principles (except I don’t have daily standups with myself, that would just be silly). So I try to keep a product backlog, create sprints for myself and work things into the sprint backlog. Grant you, for the one-man projects and things I do for fun I’m always the customer and the customer is always right. It’s a good process and I try to evangelise it as often as I can when working with clients to help them along the process of not doing too much up-front design and spending gobs of time creating reams of documents nobody is going to look at and will be out of date by the time the first line of code is written.

Anyways, with Visual Studio Team System there are a few options coming out. VSTS comes with the Microsoft built-in MS for Agile framework which isn’t bad (it’s not great from an Agile perspective as there are just too many things going on and you need a work item to scratch your ass) as well there are some other things in the works that are more aligned with what Agile, and in particular Scrum are about.

However there’s the cost. Not only the hefty price tag that comes with VSTS and it’s various flavours but the cost of ramping up your people to work in the new IDE, the cost of training your testers to work completely in the new environment, and well the cost of just everything. It adds up and for the smaller shops it’s just not a good fit. Expecially if you do Agile and need/want/desire something lightweight. A spreadsheet might do but why not use WSS? Some people were asking me if the recently released Team Room (renamed to Team Worksite for whatever reason) would be a good fit for this. It might but I thought we could do better.

I have a template in the final staging that might work for you. It’s based on Scrum and follows the principles of Scrum (Product Backlog, Sprint, Sprint Backlog Items, etc.) and takes much from Ken Schwaber’s excellent book, Agile Project Management with Scrum (ISBN: 073561993x) which is a great resource.

The template needs some work and I’m just debating how to distribute it now. The problem is that there are some lookups across lists which can’t be setup in a site definition but then having it as a STP file would be easy to upload and use. I’ll probably create both so you can twiddle with it, but each will have advantages and disadvantages (for example, in the site definition I can change the names of the headings on views without changing the display names of the fields themselves but I can’t do that in an STP file).

Anyways, take a look (click on the image above for the full-meal deal) and let me know what you think. Who knows. Maybe we can evolve the template to include custom web parts so you can have a VSTS replacement for the cheap bastards out there.

Note: The Iteration Progress chart is just a static image, there’s no live charts in the system (yet). 

Ever wonder what the heck all those .aspx pages in your _layouts directory are? Of course they’re for running your Portal but there are a lot of files and some are rather interesting (and rather odd). So here’s something to do when you’re bored one afternoon. Download this CEWP (Content Editor Web Part) file here and import it to a Web Part Page on your portal. It’s just a simple listing of all the pages with links to them which will open up in a new window. Don’t worry, just launching these files doesn’t do anything destructive (but I can’t be held responsible for you if you click OK or otherwise continue using the page).

Most pages are things you’re used to and have seen (and probably used a lot) before. Some are subsets of pages that you’ve seen (for example, htmledit.aspx is the Rich Text editor you see when you create a Basic Page). Most pages require parameters in order to work (in some cases they’ll tell you what that parameter is) so you’ll have to check out what’s useful and what isn’t. In some cases you can reuse the page as they’ll post back to the calling page information it contains. For example, you can invoke CategoryPickerPopup.aspx and get a popup window that lets you select an area in the portal which you can then use in your own page or Web Part. Re-use that infrastructure! Work the machine!

There are also some neat things here too. The mngsubwebs.aspx page for example will show you the page you normally see for managing subwebs in a WSS site (for navigating to or even deleting). In the Portal, this lists all the areas that exist which can come in handy sometimes.

Anyways, have fun and play around. Let me know if you find this useful or discover any coolness.

P.S. it seems weblogs.asp.net is going up and down like a yo-yo tonight.Wonder if they’re having problems or <gasp> upgrading to Community Server? So I apologize for any weird behavior.