A while back, Rocky Oliver floated the idea of resurrecting the Nifty Fifty, a group of fifty minimal sample applications that IBM threw into the box with every purchase of Notes 3.somethingorother. They didn't do much, and were never really intended to do much. They were fifty sets of ideas, fifty starting points for developers to build upon.
Lately, the idea has been getting a lot of play, thanks mainly to John Head. John suggested that, with Microsoft entering the fray and including application templates with the various incarnations of Sharepoint, the community should step up and contribute a set of "real" applications to run on Notes and Domino. The community consensus seems to be that the idea would not fly unless the apps were distributed and supported by IBM.
I guess it's time to throw my coupla cents in.
Should there be a set of application templates available that go beyond Discussion, Document Library and TeamRoom? You betcha. Does the set need IBM distribution and support? Again, you betcha. Do these applications need to be everything an organisation could lust after out of the box? Not on your nelly, nor on mine, neither. Not no-how.
What Domino needs is fifty (give or take) Really Good Ideas™ rolled into a neat little package. The applications need to be useful and usable, but each should really only try to do One Thing Right™. They should do that clearly and with voluminous documentation even for the most obvious bits. And while an application would need to include all of the ancillary bits that make its particular Really Good Idea™ work, it should absolutely cry out for extension and customisation.
Let's take the Prototype library's $ function as a basic example. The name is impenetrable (and forget about documentation — Prototype was not intended for human developers to interact with, so it's enough that Rails understands what's going on), but by the simple act of replacing document.getElementById("someID") with $("someId"), you save twenty-two characters with every call, recouping the cost of the function in only two calls. Twenty-two characters might not sound like much, but one might make a call like that a hundred times or more in a complex script, and that's more than 2KB saved right there. Short variable names come with similar savings, as do snippet "constants" fed into the constructor of a function or an object.
When it means the difference between 2KB and 10KB, even over a bad POTS connection it's not worth sweating. But when the same ratio takes you from 30KB to 150KB, you start running into usability issues over dialup and on slow, crowded networks. Sure, the file is cached, but that's on a per-database basis (and what if the user is using several applications of the same or similar design?) and only after that first slow download. The fact that the application is better-stronger-faster after it loads means very little if the initial hit feels like one is installing Office. Users will not put up with slow, and it will be Domino's fault no matter who actually wrote the code. Chuck one application, and maybe even the platform it runs on. That means that if clarity and extensibility are among the chief aims of the project, as I believe they should be, then we have to aim lower than Google Maps or BaseCamp with our web examples.
I agree that the templates in the set need to be as simple and clear as they can be. We are, after all, trying to sell the possibilities of the platform, and if a developer can't figure out what's going on, she's going to have a hell of a time trying to build her own custom applications. And they should be no simpler than necessary. Each application needs to do something that will be useful to someone, if for no other reason than to encourage the "Notes guy" to open the thing up in Designer to take a look under the hood. There almost needs to be a hole in every application, though; something that is obviously missing, but not so obvious that the template will be discounted as useless right away. NiftyNext™ should be at least as much about teaching as it is about value added to the platform. Let the all-singing, all-dancing, impenetrably complex applications remain as they are now — commercial ventures and the province of internal corporate developers.
After all, if everything comes in the box, we're all out of work.