Suppose you wanted to build a Project Management solution and you thought SharePoint was pretty neat. Then you got a group of programmers you respected and you knew could do the job. Then imagine this group of programmers had to decide whether to build a web part or a smart application. At the end of the discussion would you a) have consensus and begin coding right away or b) have to come back the next day with doughnuts and alms to ease the tension and hash it out again.

If you're like us, then the answer was .... errr... (b). The arguments were plentiful and forceful, but mostly boiled down to ease of deployment and management for web parts vs richer UI and offline mobility for smart clients.

Before I get too far down the road, however, I should point out how overweighted towards web parts the SharePoint community seems to be. For instance, doing a cursory search of SharePointBlogs.com yielded only two(!) mentions of smart client technology:

Henk Hooiveld's blog on SharePoint and Office
Todd Baginski's SharePoint 2003 and MOSS 2007 blog

Obviously the developer community has spoken and it's web parts in a runaway. But the right decision for a particular circumstance is the right decision, even if everyone else thinks you're wrong .

For me it came down to the nature of the application and mobility. Mind you, I have my set of biases. Before SharePoint we developed a product for Groove (also project management), which carries smart client technology to the nth degree (must have been doing something right though, since Microsoft bought them and created the SharePoint, Groove and Project group).

The application aspect of the decision is the most rock solid for me. Project Management has enough complexity that it can be difficult to manipulate the various components without a lot of serious DHML and vbscript. And even then it seems problematic to do drag and drop scheduling in an interactive gantt chart through your browser without an ActiveX control of some sort-- and that would obviate the east of deployment advantage. While some approximation has been done by a few companies, it has taken them several iterations to approach basic usability. And we wanted to make usability one of our selling points.

The mobility aspect of our decision really comes down to when you believe will happen. I fully believe that some day no matter where you are, you will be able to access the internet. But that day has not arrived yet, and it won't arrive by the end of this decade either. And the day it does arrive, it actually won't because that will be the day they announce public travel to the moon, with internet connectivity coming soon. But maybe you reading this at Starbucks on your Danger Sidekick and shaking your head at the crumudgeon who just doesn't get it. Well, go start your own company .

Now I absolutely acknowledge the inherent distribution superiorty of a web application, or web part. However, I would argue its not quite as superior as it once was. Sure, if faced with the choice of purchasing boxes of software and installing them machine by machine, then I bow down before the web server and chant 'ease of deployment'. HOWEVER... those were the bad old days. Today, tools like SMS and technology like .NET reduce the web application distribution advantage to almost even. I recall a recent conversation with an IT person at a Fortune 500 company who stated they can update all 15,000 machines with new software in under 60 minutes.

So our decision came do to this: If you believe your application is complex enough and you don't believe in an 'always on anywhere' internet, then the benefits of a smart client will outweigh the single (but substantial) benefit of deployment. If you want to build the world's best name, rank and serial number data entry application, then I think a web part makes absolute perfect sense. But if you want to create an app that that is focused on user experience and furthers what's possible with todays rich UIs, then a rich, smart client is the way to go.

We certainly hope so.