Spanky

If you haven't already done so, head over to Mary Beth Raven's blog and read this thread. Go ahead, I'll wait.

I posted a response there, but I've got a bit of a rabbit trail started, and didn't want to hijack her topic.

For those of you who are unfamiliar with how DWA works, allow me to explain.

No, there is too much. Let me sum up. Buttercup is marry' Humperdinck in a little less than half an hour. So all we have to do is get in, break up the wedding, steal the princess, make our escape...

If you've seen The Princess Bride, you know what a great film it was. And you also know that there is a whole lot more going on than you'll notice the first time you watch it. You have to watch it several times, paying strict attention, to figure out all that is going on. Therein is the essence of my problem with DWA. There is too much. Yes, it is very cool, yes, it works well, yes, I like the interface. But there is too much stuffed into a single nsf.

The decision to add contacts to the mail file in order to make DWA work was an extremely bad one. I know that the developers and architects had to agonize over this decision, I know it was probably a very tough call, and I realize that people a lot smarter than I thought this was the right thing to do. They were wrong. Adding contacts information to the mail file caused myriads of unintended consequences, many of which we still have to deal with. Contacts information should never have been added to the mail file. Personal NABs (remember those) should have been used instead. Yes, using two databases instead of one would have caused an initial greater footprint, this difference would have been minuscule. The benefits of having mail in a separate database as contacts far outweigh any perceived rewards. It seems the decision makers forgot a very important rule: It is better to do one thing well than many things poorly. This was a bad decision.

Adding RSS feeds to the mail file is the inevitable heir to a lineage of poor design decisions.

What do I mean by poor lineage? Getting back to the decision to add contacts, that wasn't the first bad decision regarding the mail. I believe calendar & schedule information (appointments, meetings, to-dos, etc) should never have been added to the mail file either. Before you start spitting venom; please hear me out:

Notes/Domino is GREAT at replication. Notes/Domino is GREAT at linking multiple databases into a single application. A user's Mail application could, and should, consist of email, calendar and contact databases. (BTW - why oh why are single databases now referred to as "Applications" in 8? In Notes/Domino, an Application consists of one or more related databases used to perform a specific task.). Keeping these as distinct and separate databases would greatly reduce the bloat and overhead of the current mail file design. It would also make managing the three distinct, yet very much related, types of data (mail, calendar, contact) much easier. Notes/Domino developers (those of us in the field who use the product) have been developing multiple database applications since at least R3 (I started with R3, so I can't speak with authority about prior versions). These three types of data should never have been included in a single database.

One of the most important rules when developing an application is to keep it as simple as possible, and not over-complicate things. Have you looked at the design of the mail template recently? It is hugely complicated. Please don't take this as a personal attack on the template developers; it isn't. This design train is already moving too fast, and they are so busy trying to keep it from crashing that they can't see it's on the wrong track. Or perhaps they can see, but just don't have the ability to change it. The only thing I'm sure of is that I'm tired of train analogies.

The mail file is way too bloated as it is. Adding RSS to it is, as my buddy Nathan said, a HORRIFIC idea.

I'd like to see the Mail application split up into multiple related databases. Perhaps a composite application, perhaps not. If IBM / Lotus can't (or won't) do such a thing, perhaps this could be the next OpenNTF killer app.