sine wave

  Justman & Associates

Home  About Us  Services  Portfolio  Fun  Request Info  



Consulting Samples - Problems and Solutions

There are packages that do many of these things now. But there weren't when we did them. And that is precisely the point.

Problem Solution

Framemaker/WWPublisher didn't "do" nav bar

Javascript navigation bars required 2 correlated but obscurely formatted flat files to be updated at the last minute by the content editor. Maintaining these in the last minute rush to web made her reluctant to do big fixes to the original.

Developed single xml file that contained information for both reference files, and two xslt transformations that created the necessary output. Editor needed only to edit one file, organized in her "logical" order, then execute the transforms and place them on the server.

When WebsWorksPublisher Pro wasn't enough

Framemaker exports to html through WWP, but its defaults leave something to be desired.

WWP conveniently supplies a "macro language" -- part javascript, part xml, part Xhosa (kidding). We pushed it a bit, but it worked!

Interactivity was missing

International tech writers' professional association had a web site with NO interactivity. As maintainer of its calendar, webmaster was spending too much time trying to research and enter a well-rounded list of events.

A blog-able calendar...before Blogs! Built a publicly updateable event calendar. While this had almost no security built into it, except that it emailed us the contents of any update, we are pleased to report that no one even tried to trash this in the 3 or four years it was up.

Framemaker to sgml conversion was too generic

An in-house programmer had designed a transformation map for the conversion (basic tool comes with FM) of hundreds of files. This map was so generic it only transformed a minor part of each file.

Documents had natural groupings of 30-100 each. For each group (and sometimes for subgroups as these were analyzed), we developed customized maps that converted more like 80-90% of each.

Doctors needed "pretty" boilerplate report

Elaborate echocardiograph reports often ran 4 pages, but text was always combinations of textbook phrases. Lots of long words and tricky spellings

Actually, we solved this twice! Originally, with a WordPerfect macro application, and 5 years later, with an Access database. The latter had several advantages: The Reading Doctor can edit or add to the phrases available. She can edit a report if she changes her mind. She has a database of case metrics preserved.

From Advanced Revelation to Access

Financial reporting company had a "perfectly good" reporting system built in Advanced Revelation some 15 years ago. Wanted to upgrade it to Access. However, report data were all in text fields, frequently duplicating analysis data fields. The only controlling principle seemed to be that everything in the original was designed around the layout requirements of Courier 10 pitch on certain sizes of paper. We were recruited to design new reports.

Did that, and a good deal more. One report had 7 subreports, and one of those had a subreport. Almost every layout of which Access is capable was represented. However, we also got involved in the definition of fields and menus, and finally of forms that could accept and process the data for the reports. In all, we probably designed 5 reports and 10 forms, a menuing system, and helped clarify some underlying problems relating to scheduling of updates (one set of reports came out semi-annually; another on an annual cycle controlled by the subject's FYE, a third set could be published anytime).