We have finished several Domino projects over the past year where we have consistently had multiple developers working on the same form at the same time. Not the same project, the same form.

In the most recent, there were three of us more or less constantly on the project (and in the form) for three months. In one before that there were, at times, as many as eight developers working on the same form at the same time. And these aren't trivial applications. The latest included more than 8,000 lines of JavaScript. So...pretty serious stuff.

"Wait just a minute. That's not possible," you say. "You can't have more than one person working on a form at one time without causing all kinds of problems."

Actually, you're right but, as it turns out, wrong too. Let me explain.

These projects, as I mentioned, are Domino applications. That is, web applications. Other than for administrative functions, they were not designed for use in the Notes client. That's a factor.

Also, because these were big complicated systems--one for an insurance company and the other for a major lending institution--they were also big complicated forms. That, actually, turned out to be a benefit.

Domino brings some really great tools to the table for doing group development, particularly for web applications. Chief among them are subforms and JavaScript libraries. These two design elements make it surprisingly easy to have many developers working together successfully.

Subforms, of course, make it easy to create a shared "form part" that can be used between several different forms in your database. You will often see subforms used for page headers or history sections--things that apply to many, or even all, of the forms in a database. They're great for that.

What they're also great for, it turns out, is segregating a part of the development process. In these recent projects, for instance, the forms we were creating were so big that to make sure they were usable without making users scroll up and down forever, we built them as multiply-tabbed interfaces. As, essentially, tabbed tables.

But not Notes tabbed tables. The Notes tabbed table--one of the options for using a table in Notes--does not transfer well to the web. I could do an entire posting about why you should never use a Notes tabbed table on the web but suffice it to say we don't do that. Rather, we roll our own using <div> tags to define the start and end of each tab's contents. That's just HTML.

What's not just HTML is the fact you can insert subforms between these <div> tags more or less as needed. Even better, insert a computed subform and it hardly even takes up any space on the page. So, what we end up with is a lot like what you're seeing in the image here...

I'll admit it's a little hard to see here (I'm being kind) but the red arrows point to the computed subforms on the page. There are a lot of them, one for each of the main tabs. (You can see the HTML for the actual tabs themselves--the part you click on to expose the tab body--just above the section with the arrows).

While this almost-entirely-HTML approach to the main form is certainly less WYSIWYG than the kind of development we normally think about when we think about Notes application development, what it does is move the bulk of the code for a single form out into a whole series of subforms.

And you and I and Henry and whomever else can all work on our own subforms simultaneously. So I can be working on the Summary tab while you are doing the Attachments tab and Henry is working on the Contacts tab. All at the same time, all in the same "form," all without walking all over one another.

Really, in our experience, it works great.

And, then you can do pretty much the same thing with the JavaScript.

JavaScript is a must-have for almost ANY web application. OK, so maybe if all you're doing is making an ugly page for your kids' soccer team you don't need it but if you're building any kind of useful business application, JavaScript is a requirement. Gotta have it.

The applications we're building are way more than just "useful business applications." They are completely integrated interfaces which connect to Domino data, of course, but also to legacy systems, to SAP, to Terradata, creating and reading from spreadsheets, files, databases...you name it. They are not simple applications (hence the 8,000 lines of JavaScript).

What that means is each tab has a lot of JavaScript functionality needed to make it work. Some of that JavaScript is used to retrieve and present data, often literally building the page on-the-fly from multiple backend data sources. Some of it is used for UI functionality both in the form of direct user interaction (dialogs and the like) and periodic AJAX connections to additional backend data for updates, validations, and so on.

Well, just like you can have separate subforms for different parts of the main form, so too can you have separate JavaScript libraries for each tab (or any other sensible application sub-component). YES, I know that having many separate JavaScript libraries used by your form is (comparatively) slow. No Problem. Once you have it all running you can easily copy all the code into a single JavaScript library for loading efficiency.

During development, though, it is vastly easier for me to work with the SummaryFunctions.js library while I'm working in the Summary subform (which goes on the Summary tab). And, at the very same moment you can be working in the CollateralFunctions.js library and the Collateral subform (which goes on the Collateral tab).

And, we're both busy as busy bees, working on the same form at the same time without issues. Really, that's pretty cool.

If you're going to do this, I highly recommend you create a few JavaScript variables somewhere in your application which you can use to figure out if the current user is YOU.

You can see how we do it in the image here. Why bother? Because, let me remind you again, you have several different people trying to work in (more or less) the same form at the same time. When you're writing that fabulous new bit of JavaScript that's currently kicking your butt, I don't want the entire page to error out every time I'm testing my fabulous new bit of JavaScript that is concurrently kicking my butt. To prevent that, we can each put simple tests in our code to only run the dicey bits if it's you or me or whomever is working on it.

That way you get your errors and I get my errors and never the twain shall meet.

We have found this to be a very supportable and very efficient way to build large and complex Domino web applications quickly with a full team of people. You may want to think about using something similar for your next big application development project.

1. Simon O'Doherty08/13/2009 11:23:23 AM

What I have used before is TeamStudio. Allowed me to work on a template while someone else was. Not free though.

http://www.teamstudio.com/new/index.html

2. Scott Good08/13/2009 02:01:35 PM
Homepage: http://www.scottgood.com

Hi Simon,

Yeah, TeamStudio can make it easier for a group of people to work together in the same database without whacking each others' work. What I was trying to point out is that even without a(n expensive) tool like that it's possible to be smart about how you organize your application so that multiple developers can do multiple things in more or less the same place without totally screwing things up. Actually, without even partially screwing things up.

Scott

3. Chris Blatnick08/13/2009 04:26:17 PM
Homepage: http://interfacematters.com

Nice post!

4. Henry Newberry08/19/2009 11:20:49 AM
Homepage: http://www.henrynewberry.com

One key element to the success of these projects that Scott did not mention is Design Element Locking. Using that assured that we avoided clobbering each other. Frequent verbal or IM request to free up an element were the result when potential disaster might have ensued.

Newbs

5. Subroto08/27/2009 08:00:27 PM

I love Team Studio its a 'must have' in my book. But I am pleased to see that my tabbed tables approach is as same as yours. Looks like I must be doing something right