The ShearerSite template system allows authors to add templates to their pages in a platform-independent way, without overhead at the server. It also supports automatic navigation generation. Authors can use their existing authoring packages and/or set titles, keywords, and simple HTML contents through a web-based interface easy enough for novice users. With the addition of PDF conversion software, authors can upload Office files and present browser-friendly Adobe Acrobat Reader files to the viewer. The system integrates with FrontPage, Net-It (through interoperable metadata files), ActivePDF, Acrobat, and Microsoft Site Server’s content replication service.
When my department took over the hosting and maintenance of the company web site from another company, I needed to update headers, footers, and other repeating elements on a large number of pages. I looked around for a system that would take care of it, but existing HTML editors and content management systems had serious flaws, including increased server load, inflexibility, and "lock-in". They usually lacked interoperability with other systems, even through straightforward import and export of standard HTML files. See below for more on these flaws. (A later in-depth training session with BroadVision’s portal product showed its problems were even worse than I had thought.)
The existing HTML code seemed to have been created from templates, but there hadn’t been any upkeep. A search box that appeared on each archived press release page, for example, inadvertently showed the history of their search engine as it changed address every few weeks, and the Search button was broken on all but a few of them.
I could do many search & replace operations alone to fix these problem once, or I could also add special HTML markers and write a small template system so that we would never have to worry about the same problem again. So that’s what I did. The system was designed to avoid the repeating the same mistakes. All pages are saved in regular HTML to provide the greatest compatibility with existing systems. All templates and includes are also HTML and, likewise, can be created and modified with any HTML editor. No software has to be installed on the production Web server, so it can handle requests with static-file speed.
A Web interface allows content authors to apply updated templates and replicate from the staging server to production. (The whole thing, including coding of a web interface for content authors and the creation and application of all templates, was completed within a 30-day site cutover deadline.)
An open system allows great flexibility and interoperability. The navigation system is an example. Before it was written, our main content author was using FrontPage’s built-in navigation feature to put lists of buttons in a left-hand navigation bar. However, as the site grew, this became unwieldy and confusing for users. There was no "breadcrumb trail" telling users where they were, and the button titles (which were limited to non-antialiased graphics in a very small selection of fonts) did not wrap and had to be short to avoid extending off the edge of the button. The top button was always named "Home Page", but it took the user to different pages depending on where the user was, in one case requiring a mini-tour of four clicks before something recognizable as a home page appeared. Also, FrontPage subwebs were walled off from each other as far as navigation links were concerned, even if they were part of the same site, so breaking a site into subwebs for performance or for delegation of authoring privileges affected what you could do with navigation.
The solution was to add a navigation component (which fit into the existing system well as a special type of include); one that would read FrontPage’s navigation data and write out a breadcrumb trail and child links, all customizable through templates and stylesheets. Adding navigation to the template system took only two days from initial conception to deployment, including figuring out FrontPage’s internal data format. The content author could still configure the navigation heirarchy using FrontPage’s graphical interface, and the existing complex navigation hierarchy was preserved. In fact, there was no change to her workflow. But the usability problems were gone: there was now a breadcrumb trail that went all the way up to the site home page, and long link titles would now wrap. The content author was extremely happy.
Later improvements to the navigation feature added the ability to link different FrontPage subwebs together and to optionally bypass the FrontPage navigation editor entirely by inferring the navigation hierarchy from the folder structure itself. This is the method the content author now uses.
A later update added PDF conversion of uploaded files (using Adobe Acrobat Distiller for delayed, offline conversion, or ActivePDF for online conversion) which allowed it to completely take over the functions of our old Net-It system without any loss of file information, since it can read the document titles from Net-It’s .csi files.
Also see the Features, How to Use and Revision History pages.
Language | Python. |
Compatibility | Browser: Any. Server: Any supporting CGI, though to date only IIS 4 and 5 have been tested thoroughly. Apache support is being tested now. The command-line variant has been tested under Windows 95 and Mac OS X. |
Reusable Internal Components |
|
Download | See the Download page. |