Quick and Dirty Mail Application Document Importing

01/24/2008 12:06 PM by Chris Toohey

Most of our "Inbox" consists of a Projects folder, which a specific sub-folder for a given project or task. Sales has a like folder structure, with Customers replacing Projects in their instance. Now, the "categorization" of email in this manner has two (at least, I know) huge pitfalls. The first being that their "shelved" email are only accessible via them or individuals that they happen to delegate to view their database. The second, and more technical issue here, is that individuals are storing massive amounts of content in an ever-growing list of folders <shudder> - the admins in the room should be running for the hills at the mere mention of what ultimately results in 1.5TB Mail files for your long-life employees and power-users.

Now, there's such a thing as a need for data retention, which (and Admins help me out here) you should take-the-path of enabling Domino Mail Journaling and look at a few e-Discovery tools that are out on the market today... but that's not really what I'm getting at here...

See - the above usage of email is not very collaborative. A new person comes onto a project or an account, and there's no-way to quickly ramp-up, since exchanges are de-centralized. Going with the Projects-meme, I'm going to suggest the following - which I currently use at several customers with great success:

Build a simple and sweet engine within your applications that allow the importing of context-specific, user-defined documents.

Let's say we have a project tracking application. You have a form (let's call if project, that allows each project to track metrics like Project Manager, Tasker(s), Taskee(s), Due Dates, etc. If I wish to view any information about the project, my expectation should be set to have the project document in this project tracking application be the source for all information that pertains to the given project. See the problem here - you won't have all of the information about the project because Joe Smith has it stored in his mail file. NOT collaborative at all really, and thus makes the application full of fail!

So how do we remedy this? Well, I lend towards giving the user the ability to import their email, calendar entries, and task list directly into the Projects database - creating a child-document relationship between these imported documents and their parent project documents. The best part of this? Well, not only do you clean up the user mail file (as this combined with journalling means that they no longer need to retain those folders, emails, and et al. - so "Yay!" for those Admins out there) and you get a totally centralized location for your content, BUT you also get all of this functionality with minimal design changes to the target Lotus Notes database!

Ingredients

1. Form Element: (ImportedMail)|Reply|Memo
2. View Element: (embDocuments)|embDocuments
3. View Element: (bykey)|bykey
4. Form Element: Project|project

So, we'll take a look first at the mail form. This form, as you should be able to tell by the name, is simply the visual for the to-be-imported documents. You'll want to keep this simple and sweet, as I recommend you create your own (or take the one from the example), as this will alleviate any confusion that you have left the projects application or that you should use this application to generate emails.

Once you've setup the (ImportedMail)|Reply|Memo form element, you're going to want to work on how they're displayed in the client - which is where our View element comes into play. Simply pick the look and feel of the view - or copy mine - and keep in mind that the very next step will set the requirements for view design and ascetics. You will want to have this view categorized by @Text($Ref) and auto-expanded.

Now, we're ready to modify your Project|project form element. Simply create a section on the form where you intend to show all imported documents specific to that user. It's pretty standard really - you'll embed the embDocuments, and set the Show Single Category attribute to @Text(@DocumentUniqueId). From this, you can see that we're only going to display the imported (child) documents of the project from within the form.

Now, you'll want a function of sorts to actually trigger the import, so directly above (pick your poison, but I prefer a pseudo-embedded view action bar-feel), and that's where this code comes in handy!

Grab the example database for the code - it's something that I threw together to give you an example (read: quick-and-dirty code - not refined product-level stuff here). But here's what I'm basically doing:

1. Check and see if the UI Document isNewDoc - and if so - inform the user that it needs to be saved prior to importing email.
2. Ask the user if they just want to go to their Inbox...
3. If not, ask the user if they want to use a cached version of their folders list - if available that is...
4. And finally, do a full look-up of all Folders (and update the user-specific cache) and let the user pick a specific folder.

I save that option for last, in my example code, as the folder listing takes so long - even over the LAN. If I can use a cached copy, which I get via creation of a user-specific "profile" document in the application. Pretty basic stuff really.

The usage of this methodology is very basic - very simple - and that's the beauty of this approach really. It's a simple, quick-and-dirty solution that addresses the non-colaborative aspects of email. Give it a spin and hopefully this method is as helpful to you as it has been to the customers and applications where it's been implemented in the past!