Since we first released Teamstudio Export back in February 2018, we’ve steadily added more features to the product, most of which have been enhancements to the HTML archives that Export produces from your Notes databases. We’ve added full text searching, more options for configuring views, doclink support and better ways to format the field values that appear at the document level. The one thing we’d never added though, mostly because of the amount of work required, was full blown Notes form rendering in HTML.
But that’s the one feature that I always felt slightly held the product back. The Notes NSF database structure doesn’t include the concept of a field label. Fields in Notes have names, values, and data types. But there is no label that’s stored as part of the database structure. Field labels only appear as text in the context of the form design. And so, if you divorce the data from the form layout, as we do in the Export document level presentation, you have no way of associating the field label with the data. Depending on your form design, that can make it hard for archive users to understand what they are looking at.
It is possible to add a configuration file that allows you to define the order that fields are displayed, to hide fields, and even to set your own field labels. However, that requires some work to set up the config file, and that’s work that was already done by the developer when she or he originally built the app.
The obvious answer, of course, is to have Export use the form design to render the form in the browser, and place the field data in the right places on the rendered form. Sounds easy when you say it quickly. But it turns out to be a massive amount of work, to do it properly. Just think for a minute about computed-for-display fields, or hide/when formulas. Computed subforms? The Notes development environment has evolved a huge amount over the last 25 years, and coping with every edge case in terms of faithfully rendering any given Notes form is just not feasible. But, after many months of sustained effort, we think we’ve covered enough to provide a solution that’s a lot more than good enough. And we just released it as Teamstudio Export version 3.0.
How useful is this new feature? Here’s a simple example from a well-known database design, the good old Discussion Database. Here’s a screenshot of a document being rendered by the Notes client:
Looks familiar, right? When the database has been exported to HTML and rendered by earlier versions of Export, you’ll see a list of field name/value pairs:
The data is all there, and the rich text is nicely formatted. But look closely at the top of the screen, and you’ll see a new tab labeled Preview. Here’s where you’ll find the field data rendered on the Notes form:
As you can see, it makes quite a difference to be able to see the data in the context of the form itself. Of course, in Export 3.0 the Preview tab is the default view, but you can always switch to the Data view to inspect the actual field names and values.
As I said, it’s just not possible to implement everything we could possibly encounter in a Notes form design. However, if you come across something that doesn’t work (some obscure @Function, for example) then we encourage you to report it to us and we’ll implement it if we can. We plan to continue to make improvements in new versions of Export as time goes on.
Just a word about future upgrades to Export. Some of our customers are archiving their Notes databases as part of a program of decommissioning Notes & Domino. If you already archived all the databases you want to keep and you’ve shut down all your Domino servers, that’s not a problem for Export. As long as you keep the intermediate XML format archives that Export creates, you can re-create your HTML archives with a newer version of Export and you’ll get the enhancements. We store just about everything in the XML archive, and the format has barely changed since the very first version of Export shipped.
So what else is in the new release of Export? First, you can now specify where Export should store its temporary work files while it’s archiving. If you’re archiving very large databases, it’s helpful to be able to tell Export to use a separate drive for its temporary work files, should you risk running out of disk space. URLs that we find in rich text are now converted to active hyperlinks in the HTML output. There are a bunch of other fixes and minor enhancements; the details are all available in the release notes.
If you have an active subscription for Export, you can download the new version from the Export download page. If you don’t have an active subscription, contact us to learn more.
We think this new version of Export really makes a huge improvement to the usability of the HTML archives. We hope you agree!