Tip of the Iceberg

Category domino
So as you all know, there's been much discussion about exhuming the Nifty Fifty. Or creating our own ("It's alive...."). I've a slightly different idea: instead of (or, perhaps, in addition to) showcasing entire standalone templates, how's about creating some really impressive embeddable "modules" that can demonstrate how rapidly an existing application can be juiced up by adding one or more of these modules? I think a perfect example of this is OpenLog: add the script library to any database and it's instantly more powerful. The issue that I have with standalones is simply that, when implemented within any given Domino environment, they don't fit in... unless we did go to the hassle of Blue-Rinsing them, in which they'll still look out of place unless the organization implementing them Blue-Rinses all of their databases too.

Why is that even an issue? Well, IMHO the two main points underlying the Notes vs. Sharepoint debate are cost and ease. OpenNTF obviously addresses the first issue, no question about it. But what about ease? Yes, of course, I can slap an instance of domBulletin or DominoWiki out on my server and have it ready for users to start using in five minutes flat. So I can rapidly enhance my Domino environment, and the users benefit. That was easy. But that's not the "ease" we're really looking for in this case. When I installed DominoWiki for the first time, my reaction was, "Wow, that was very easy to install," not, "Wow, that would have been easy for me to create myself." Hardly. Most of what ends up on OpenNTF took somebody (or a whole team of somebodies) months or even years to develop, in many cases using techniques that are either cutting edge at the time or at least far more advanced than those within the range of the average Domino developer. So I feel that a Nifty Fifty that will truly convince an organization that Notes/Domino is the right platform for them would not only get them off to a good start, but also showcase how easily they can create and enhance their own applications within the platform.

Please don't misunderstand me: I'm not saying that OpenLog is a perfect example because it looks like it would be easy to create... quite the contrary. However, the bulk of what it does is really contained in a single script library (well, technically two; one for LotusScript, one for Java... but the functionality of one is essentially mirrored in the other, just using a different language, which is yet another reason this is perfect for demonstrating the capabilities of the platform). So in looking at a single design element, I can follow along: "Oh... I see what he's doing here." Much easier to get my head around than trying to comprehend something as intricate as BlogSphere. There's only one aspect of it that keeps it from being the ultimate poster-child for what I'm suggesting: it appeals primarily to techies. Centralized, standardized logging makes our lives so much easier. And, although this indirectly translates into improved user experience, the users themselves don't immediately notice a difference. Or, if they do, they won't understand why.

Perhaps what I'm getting at would be best illustrated by a story from my own past. Once upon a time I supported approximately 250 applications... in an environment that had no templates when I got there. When a change was requested, a developer would make the code changes in the live database, test the changes live (which resulted in test data mixed in with the real data, that either had to be cleaned out later or was simply left there), and until the changes were complete, the affected functionality performed erratically, if at all. Ew. Meanwhile, any functionality that was similar (or even identical) across databases had to be applied manually to each in order for all of them to receive the benefits of updated techniques.

Over the course of a couple years, I implemented a multi-layered template inheritance framework that not only allowed users to be shielded from the testing process despite the lack of a separate test environment, but also ensured that, whenever a more ideal (faster, more secure, more reliable, whatever) approach was identified for shared functionality, the next morning all 250 applications had received the "better" code. This was accomplished by consolidating all shared design elements into a global template and setting each to inherit from that template, instead of an application-specific template. In particular, this template included a LotusScript script library that was common to all applications; hence, any time we further optimized a given function or class, the next morning any calls to the optimized code ran faster or more securely or more reliably. In every application.

At some point during this process I was approached by the owner of two separate, but related, applications. One was used for documenting all aspects of a certain internal process. The other was used solely for storing meeting agendas and minutes for a weekly meeting that was held for the sole purpose of discussing the current contents of the first application. The request I received was merely to combine the two; there was no point, they said, in having a separate database to store the agendas and minutes. I agreed, so we merged them. But we took it a step further: we added functionality allowing the meeting to be automatically added to the chairperson and invitees' Notes calendars. I'm sure most of you have done something very similar; this is exactly the kind of integration that makes Notes/Domino such a powerful collaboration platform.

Next thing I knew, however, another process owner approached me and indicated that there was another pair of databases with an identical relationship. They had seen the result of the previous effort - and users' response to it - and wanted the same for their applications. And just like that, our first module was born. Given that there was no application-specific code contained in the design elements that comprised that category of functionality, I copied them out to their own template, and pointed the inheritance of each element in the applications that now contained them to that template. From then on, we were able to add the same kind of calendar integration to any application in minutes, and each retained the auto-update capability: periodically we'd add features or fix some bugs, and the couple dozen applications that - almost overnight - had come to include this module would receive the upgrade, while the rest of the functionality of each remained intact.

Over time we applied this same principle to other modules. This not only made my life easier by simplifying the process of updating self-contained featuresets of completely disparate applications, but it also demonstrated to the users why Notes/Domino was the right solution for the various business needs it was being used to address. Management acknowledged its impact on the total cost of ownership, and representatives from all areas of the business contributed great ideas for additional opportunities to take advantage of this model.

What I believe ultimately made this approach successful was that each module was intentionally designed to be highly configurable. The best example of this concept was the workflow module. A single document (which wasn't a true profile document, but could have been) in each application defined whether the application used a serial or parallel approval workflow, and whether a document's revision ID was to be incremented numerically or alphabetically. The presence of these two fields was all it took to allow the subforms that comprised this module to be added to any Notes form and instantly give it a standardized workflow that fit that application's process, no matter how disparate the application was from any other that used the same module. And once again, any time the module was improved, the improvements filtered out to every application that used it.

My point is that this isn't just my approach; we all do this sort of thing, to some extent. This isn't some trade secret I'm giving away here. But we're all doing it independently, packaging up our code into an internally sharable form so that we can save ourselves hassle and make our users' lives easier. But wouldn't it be great to extend this approach globally? All of us create and support applications that are specific to a certain business or industry, but at the end of the day, most of them do very similar things, and certain portions of them are universal. So why not have a shared codebase for certain small areas of functionality? From the web side, think of prototype.js, or Scriptaculous, or the YUI... "everybody" now uses one or more of these. I'm just sayin' us Notesheads should have more things like this... some subform or script library or agent that instantly adds a specific capability to whatever application it's plopped into, demonstrates how easily a fledgling developer could come up with something similar, and is rapidly upgradeable whenever an ehancement to it becomes available.

I'm going to give this some more thought and try to come up with some ideas for specific modules that I'd like to contribute and/or would like to see someone attempt. I'm also curious to see if other folks have feedback on this.