Well, if I needed something really flexible (especially for interactive work), I'd build custom UI. But the tour's display-UI requirements were: look good, and be easy to edit. The "easy to edit" might have been better served with RTF (which is well supported by Groove's TOM-based richedit control), but plugging in tables and pictures would have been harder. So, HTML.

Thus the main UI of the tour tool is just a Web browser (Groove's browser component, which is a wrapper around IE). There's a template-page on the local disk, which loads some JavaScript helpers and some CSS style. Then, at runtime,

• the script moves into a stage;
  
• code in the script's default PreInitialize handler grabs the contents of a resource attached to the current stage (usually from a CDATA section, since this is raw HTML not XML);
  
• this is pre-processed (some variable substitution), and squirted into the main DIV in the webpage.

The "variable substitution" piece is useful: it understands a range of embedded references. These include

• Propertynames, to be replaced with the property's value;
• Resource names, to be replaced with the value of the named resource on the current stage element (so you effectively can do nested "#include" in the HTML, if you want);
• Pseudo-hyperlink: references to Groove objects (tools, files in a docshare tool, etc) which turn into clickable hyperlinks to navigate you to the destination;
• Inclusion: references to files in a Groove fileshare tool, which turn into the "thing itself" (for example, to reference .JPG or .SWF files which were loaded into the space at runtime, and which you want to appear inline at the tour's user interface).

I've used this sort of "HTML inside Groove" view in quite a few tools now. It still takes a non-trivial amount of development effort (to build the template page, script helpers etc), but if you need a clean, flexible, not-very-interactive UI it's definitely the way to go.