Se-lu 26, pff-qff edition
A tech oddity.

As I'm running through debug phase on courseware, I'm finding and fixing lots of little text errors as expected. Missing periods, inconsistent bolds, repeated words.

Only one non-textual problem remained, which seemed stubbornly unsolvable until I LOOSENED MY MIND.

The problem was narrow and highly specific. One animation, out of a couple hundred, refused to show up in one specific situation. This animation ran properly in all the usual browsers when the module was 'barefoot'. But when the module was running inside ScormCloud displayed through Firefox, the images didn't show. IE and Chrome behaved properly in ScormCloud.

I compared the animation with others. By linear thinking it seemed to be extreme in two ways: (1) It has more images than most of the others (2) its timestep is longer than most of the others. But neither of those variables was at the end of the line; a few other animations were longer and slower, and worked properly. I tried cutting some of the frames, and tried shortening the timestep. Nothing worked.

Could the filenames be a problem? ScormCloud is highly case-sensitive. All filenames must be purely LC. But that wasn't the problem here.

The filenames were aff-eff01.jpg ... aff-eff30.jpg, because the animation is about afferent vs efferent nerves.

Too long? Other animations have much longer names. Hyphen? Most of the animations have hyphens.

Well, is there something peculiar about the name itself? Nah. Can't be.

SE-LU.

When you reach "can't be", you have to LOOSEN YOURSELF and assume that it can be.

Tried changing the names from aff-eff*.jpg to pff-qff*.jpg.

BINGO! It works!

Because pff-qff is meaningless and looks vaguely dirty, I changed to a more meaningful word. Still good.

Why does Firefox refuse to display an image named aff-eff01.jpg, when running in ScormCloud?

Is aff-eff a reserved test word of some kind, left over from FF's development? The FFs in the name are suggestive.

= = = = =

Another accidental realization that may be more useful: These modules have been through a year of development, and the text parts have been read repeatedly while I was mainly working on the animations.

The text normally appears on one 'page' while the animation appears on the facing 'page', in blocks about the same size as this blog column. During this final phase, for reasons too obscure to explain, I've had to do the proofreading on the raw HTML. In the HTML as viewed in a programmer's editor, each text page is one LONG line. So the proofreading is more like a ticker-tape than a page.



Scanning is purely left-to-right, with no downward movement and no switchbacks of the eyes. This ticker-tape mode is a VASTLY more effective way of detecting small errors like repeated words and missing periods. The errors weren't seen in dozens of page-style reads, but they stand out instantly in ticker-tape view.

The problem with page mode isn't entirely surprising; proofreaders have known about this for a long time. But the ticker-tape solution is new.

On the next project I'll do all the proofing in ticker-tape mode from the start!

Labels: se-lu

  ¶ 2:43 AM