Welcome to

As I mentioned in my first post we are getting close to alpha on our second product, currently codenamed Walla. Just like this blog is an experiment in community, our second product will be an experiment in simplicity.

Our first product, Logistic for Lotus Domino, is large. It’s not Vista large with millions of lines of code, but it also wasn’t a weekend project. Logistic is our answer to the issues of email purge, discovery, and compliance. Logistic isn’t a Swiss Army Knife application, but it was engineered from the beginning to be multifaceted. It can be used to find email based on nearly any Notes email parameter — sender, recipient, subject, body, file attachment, age, view/folder location, form type, etc. This also includes negative parameters. For instance, find all emails with the subject “Test” is a positive parameter. Find all emails that don’t have “Test” in the subject is a negative parameter. Once the requested emails are found it takes one of several actions: purge it, move it, or report on it. While it is spending so much time inside the mail databases looking for these matching emails it also collects some useful statistics. I could go on and on, but you get the point here. It does a lot of stuff.

Our second product will not do a lot of stuff. It will do one thing, but it will do it very well and very easily. I have always been a huge fan of simplicity in software, but have never really had a chance to express it with Notes. After all, most of the applications that Notes programmers create are based around workflow, and a majority of the time they are complex workflows that take complex code. What is changing here at Conxsys is that we are focusing on tools for Domino administrators. As Domino administrators ourselves we often times run into tasks which require specific tools. These tools either:

1. Don’t exist.
2. Are incomplete.
3. Are parts of a larger, very expensive tool set.

To that end, we plan to focus on tools for the Domino administrator for the time being. Maybe, when all is said and done, we will package them all together as a toolbox, but for now and the foreseeable future these will be distributed as individual tools for very specific tasks, not unlike the real world tools used around the house. A hammer for nails. A screwdriver for screws. A paint brush for paint. Very targeted, very specific tools.

So, just what is this simple tool going to do? It will monitor server documents for modifications made to any field and report on it. Not exactly earth shattering, is it? It’s not supposed to be. Wire cutters ain’t an adrenaline pumping thrill ride either, but they perform a necessary job.

When Walla finds modifications it will report them in the form of an audit document in the Walla database, but via configuration it can also send out an email alert. In my experience running Domino for large corporations change control is taken very seriously. Certain items, especially configuration items such as server documents, were strictly off limits except for critical emergencies or changes that were planned well in advance. No matter the precautions taken at these different companies, from time to time an admin (both junior and senior) would edit a server document without change control. Most of the time these were merely mistakes. A local replica being used for testing with realizing that it was replicating back up to the server. Accidentally modifying the configuration in the production domain instead of the test domain. Sometimes they were intentional, though not malicious. An overzealous junior admin who was well intentioned, but not well trained. Sadly, however, there have been times were it was quite intentional and quite malicious.

The problems with any of these scenarios are in tracking down the responsible individual and getting the configuration back to what it was before, not necessarily in that order. I know what you are thinking. “Check the Modified By field for the responsible person” and “how could you not know what the previous configuration was?” Consider this: Joe Admin, thinking that he is in the test domain, accidentally modifies Field A. By the time the change is noticed, Jane Admin had modified Field B in the same server document via standard change control process, therefore her name shows as the user to last modify the document, not Joe. Furthermore, there are hundreds of fields, hidden and visible, in a server document. Which field was changed? You can’t just ask Joe because he doesn’t even know that he’s the one who caused the problem, or if he does he’s hiding it out of fear. Once you finally figure out which field was changed, what was its previous value? If it wasn’t a simple checkbox or radio button and you haven’t thoroughly documented every field entry in every server document (you have, haven’t you?), then what was the previous value?

For those who agonize and lose sleep over this very type of problem (and if you don’t you should), Walla — or whatever we end up naming it – will let you rest assured that your server documents are being monitored. It will watch all server documents by default or select ones via configuration for changes and create an audit report when a change is detected. In any field, even the hidden ones. It can optionally send out an email alert when a change is found allowing you to take immediate action. Best of all, because it tracks the value of every field and therefore knows exactly what the previous entry was, you can rollback any field to its previous state with a simple button click.

With all that said, just because a tool does one thing does not make it easy to use. One of the key goals of this application is ease of use. I feel that if you are going to make specific, targeted tools that perform one job, they better do it with minimal or no configuration. Walla will work by simply putting the database on any Domino server and signing it with your ID. Though it has a profile document that can be used to configure the utility, it is totally unnecessary unless you want the tool to perform in a manner that is not the default. And even then we will likely include a configuration wizard to walk even the greenest of admins through the configuration process.

This experiment in simplicity extends past just a set-it-and-forget-it application. Almost a quarter of the time spent on this tool will be on the user interface. Not only are we striving for a clean, streamlined look, but we are also trying out some interesting techniques with forms in order to present the data just a bit different than we usually do. And no, this does not have anything to do with the recent fascination of webifying Notes applications with AJAX or other Web 2.0 technologies. Don’t get me wrong, all the Web 2.0 / Domino stuff is extremely cool, but not what I am going for with this app. After all, this is a tool for Domino administrators, not a whiz bang GUI front-end for a CRM application or web site. And most Domino administrators spend their time in the client, not the browser, so it made sense to make this client-centric. The problem with that, from a design perspective, is that so many Notes apps look the same. Yellow forms in Default Sans Serif 10pt black font. Blech! We can do better than that (and some have), but most organizations developing Notes applications do not want to spend the time on presentation. This goes for both commercial and in-house developed apps. I can’t begin to tell you how many commercial apps I’ve seen in my days that cost upwards of $10K that look awful. I’m not talking about shiny interfaces here, I’m talking about confusing, non-intuitive UI’s. We may not be able to make it look like Aqua or Aero Glass with the Domino Designer, but it can at least be a clean, simple interface. We will be trying our best to achieve that with Walla.

For those interested the alpha will be public with an expected release date of mid-1Q07.