One elegant way to improve perceived performance is to run computing task outside of user time. In Notes that is done using (scheduled) agents and scheduled replication (On mobile devices it is called PushMail ). When you have longer running tasks that only make sense when new data might have arrived, a scheduled agent doesn't make much sense.
Triggering a process "On Replication" is much preferable. Classic Notes agents don't have this ability, but the Notes full client can do that. Already today the replicator hosts not only classic Notes NSF replication, but also address sync and Activities sync. This type of extensions can easily be created using an Eclipse extension point: There are a few caveats (besides designing an 32x32 icon) when building the class, but once you know them it is straight forward:

• You either extend org.eclipse.core.runtime.jobs.Job or com.ibm.notes.java.api.util.NotesSessionJob
• For both approached you must have a default constructor without parameter. Neither of classes you extend has one, but your implementation needs one
• When subclassing Job you extend run() for NotesSessionJob you extend runInNotesThread(). The later has the advantage to have all the session handling completed, but you end with a dependency on Notes client code
• While both methods provide an IProgressMonitor as parameter, your code needs to try to obtain the Notes specific one (see sample)
• Keeping track of units of work is a pain, expecially when your tasks calls various modules with unknown number of steps. Luckily there is SubMonitor that allows to specify a set amount of "ticks" for a subtask that can then adjust them as needed (see example)
• You should check IProgressMonitor.isCanceled() inside your code and terminate processing at the first possible point (without sacrificing data integrity) when encountered

Your class could look like this:

This entry is part of the series Domino, XSL:FO and XSLT that dives into the use of XSLT and XSL:FO in IBM Lotus Domino.

XSL:FO and XSLT are text based formats, so you could use your favorite text editor (or a modern heir) to write your XML. You also can poke yourself in they eye.
A XSL\* transformation is code running with pattern matching, priorities (and closing tags), so the probability you get it right, especially when you are new to the domain approaches zero. A good content aware editor and a debugger tool is paramount. When looking around, most of these editors are geared towards developers. Here are some I tested or worked with:

• oXygen XML - this is the editor I currently use. It is cross platform, integrates into Eclipse and has a nice debugger and quite responsive support team
• EditiX
• XMLSpy - Used to be my favorite before I made Linux my main environment
• Liquid XML Studio
• Treebeard - a Opensource editor
• Stylus Studio

There are more, so you want to do some research yourself. Of course you can debug the hard way or just use the Eclipse XSLT Debugger.
Being able to write good XSLT, doesn't make you write good XSL:FO automatically. So you want to make sure the tools support that as well. The above tools do FO too and there are some specialized editors around to choose from. However they have limited appeal to a non-developer user.
A suitable tool for business users (still they would need to have some IT aptitude is the Java4Less FO Designer. It is modeled not based on an XML tree, but like other report generators, so business users might feel more familiar:

The price is modest and you only need licences for people who want to design FO reports, not to run them (that's pure Java, as you learned already).
As usual YMMV.