Followup on the new website

More on the website revision, in part to remind myself what I did and why, and perhaps something here will be of use to others.

So, I’ve been converting our Innovative Interfaces catalog pages on our libcat server to a format as close to the new server pages as possible.

I’ve wanted all along to make the transition as seamless as possible — ideally (IMHO) most users won’t realize they’re moving back and forth from one server to another.

Due to the wiki template set up on the campus website (and therefore the old library pages), however, we elected not to do that and allowed variation on the catalog pages.  Now, with the new server, I’m striving for identical looks.

Little things crop up in the process, of course.

Date Script

JavaScript for date in the header is one I borrowed some years back for use in the catalog.  We are finally able to use it on the regular home page now that we are on a server that allows it.  I like it because it specifically states what today is (day of the week and date) and the hours today only.  There is also now a link to all our hours on a separate page.

When we’re closed, it says so for that day, but I wanted the ‘closed’ message to remind people that online services are still available: “Closed Today (Online Services Still Available)”.  The catch was, I had that message on one line replacing the ‘hours’ text for that day, and it’s a much longer piece of text.  It threw everything off in the header — kicked everything right off that over and some of it wrapped onto additional lines, which looked terrible.  So, I broke the text display for the ‘closed’ message into two lines and it works neatly now: “Closed Today<br />Online Services Still Available”.

III uses “tokens” which are shortcuts to scripts in their system that handle certain tasks.  These work somewhat like SSI (Server Side Includes).

For example, for much of the top header in catalog pages, I can use “toplogo” which calls up a separate HTML partial file to fill in a stock header.  Same for “botlogo” which fills in a stock footer section.  Very handy.

So, I linked the toplogo section in the catalog to run the same JavaScript for the date/hours info from the library server, so I only have to change it one place to update it (changes in hours, holidays, etc.).  Very handy.

Advanced Searching

The catch to the above is, the header in ‘toplogo’ included the same catalog search box that is on all the pages.  The Advanced Searching page in the catalog, however, is one page that uses not an HTML form, but a token which calls up a form, since it’s more complex (combines terms, searches several indexes, etc.).

That called form assumes it’s the only one on the page, which conflicts with the one in the stock header.  Normally, you avoid this by giving specific names to the forms and referring to those, but when using the token to call up the form, I didn’t have the option to change the token-called script.

Trying to use Advanced Search in the proper box resulted in the form trying to get information from the box in the header search box instead (since that was the first form encountered on the page), and then telling me I needed to enter something there.

Answer: I entered the toplogo completely in normal HTML on this one Advanced Search page, instead of calling it with the ‘toplogo’ token.  That way, I could comment out the search box in the header so only this page is without that search box in the header.  Now the only working search was the one called by the Advanced Search token script.  Conflict eliminated.

If I change the header, I’ll have to remember to change this page as well.  However, the date script still works as usual, so no extra concerns on that.


CSS (Cascading Style Sheets) are multiplying in the catalog.  III includes one of their own (untouchable since it operates some of their specialized functions), and we can override aspects of that and augment it with another, which we do. Now I added the one for the new style pages.

That meant that I had to make sure that adding the style sheet Joni created wouldn’t conflict with any names in the other style sheets.  Then I added that to the list of style sheets to check when a browser creates a page on the screen.

Then there was minor tweaking to get the CSS to work within our catalog server.  This included some little spacing things to allow for (as usual) Internet Explorer not working to the same standards as other browsers, but that worked out.

I commented a lot in the catalog version of the CSS file as to what I did to make it different from the version in the home version.  I may need to know all that some day.

Testing Browsers

I’m testing with Firefox 3.5 and Internet Explorer 7 and 8 (although 8 is not approved on our campus at this time as it won’t work properly with our version of some instructional software elsewhere on campus), as well as the current Windows version of Safari (since I don’t have a Mac to test) and current Google Chrome.

Progress is being made!


ILLiad and Canons

I spelled that correctly.  Really.

It’s “Canon” as in the manufacturer, and OCLC’s ILLiad interlibrary loan service.

After long consideration and talking to Innovative Interfaces people, we’re moving away from the Innovative Interfaces ILL module, such as it is, and setting up ILLiad.

I’d gotten a Canon MX-700 all-in-one to replace our old fax machine earlier.  It seemed to be doing well, so when we needed a color printer to handle the occasion ILL that we need to print, I just got another — on sale, of course! — since it could double as a scanner with an ADF (Automatic Document Feeder).   Inkjets are expensive for cartridges, but we don’t print that much color from it, and send black&white to a laser printer instead.  They could both use the same cartridges.

When it came time to train on ILLiad’s “Odyssey” function, which scans in documents to lend, the Odyssey software crashed.  It wouldn’t even open — just crashed the ILLiad software completely.  Apparently it didn’t like the Canon MX700 driver at all.

Hmmm.  So, I installed the driver for our older, less reliable Epson 4490 (they’ve been dying on us at an accelerating pace).  Then tried it without the Epson attached, but kept the Canon MX-700 attached.

Now, Odyssey came up, said it couldn’t find the Epson (we told it never mind) and Odyssey opened.  Then I chose the Canon from the list of available scanners.  And we were in business.  The trainer couldn’t explain it.  Did the same thing on another computer.  Install the Epson driver to find first, and it came up.  Canon only, it crashes.

Now we needed a scanner (just a scanner, no ADF, no printing) for another ILL workstation.  I had just gotten in a Canon 8800F so I put that on with the 8800F driver.  Try to load Odyssey and — Crash.  Try something else.  Crash.  Crash.  OCLC claims it works with any TWAIN scanner.  Crash.  Consult, check all the suggestions off.  Crash.  Crash.  Install the Epson driver.  Crash.  Install the MX700 driver.  Crash.

The librarian in charge of ILL finally worked it out.  Turn the Canon 8800F off first, then load Odyssey, then turn the Canon back on.  Then Odyssey seems to be happy with it and lets you change to the Canon.

Scanners are notoriously wonky creatures, and OCLC software is very particular, but at least we have a workaround.  If anybody else has an explanation or better way to do it, I’m open to discussion.

BTW: Dell PCs using Windows XP Pro, USB interfaces.  I love USB interfaces because they allow you to switch equipment so easily.