Flexknowlogy – Jared Stein

This article explains an experimental approach to ensuring consistent line-length and font-size for the readability of text on Web pages. This is the first time I’ve posted an article related to Web development, but I hope it to be the first of many.

Though there have been a number of articles proving the usefulness of flexible and elastic layouts in Web design, too many sites still use fixed or fluid layout. I say “too many” because the key problem both fixed and fluid hold for users lies with readability. Usability studies have shown that most users find a line length of 40 – 60 characters to be easiest to consume (though at least one report ranges from 35 – 95 and another a more modest 40 – 80, depending on the font used). This falls in line with print typography guidelines that recommend anywhere from 11-15 words per line. As you can see, there’s no final word on line-length readability, except that it falls somewhere on either side of 50 characters per line (cpl), or 13 words per line (wpl).

Presuming, then, that a Web designer wants to present reading text at around 50cpl, flexible or elastic layouts come in handy, as they measure the width of text column(s) in em space. One can set the width of the column to, say, 45em, depending on the font, and end up with a rough average of 13 words per line. The added benefit is as the user increases or decreases her font size for readability, the width of the text column increases proportionally.

Fixed width designs are often measured in pixels, and a user increasing the font size does not increase the width of the line, resulting in too few cpl. Neither do fluid designs, which are measured in %–these often result in too many cpl. And for most users with ultra-high resolution screens, fonts are often too small and require resizing.

A few years back I tackled this problem from a different angle. I thought, wouldn’t it be great if, rather than changing the size of my window and/or the size of my font for optimal readability, the font size changed automatically proportional to the size of my window? So if I had a high-res screen with my browser maximized, the font would be larger. If I had a low-res screen, the font would be smaller. In either case, the proportion would equal Your Favorite Line Length.

There is no % unit of measurement for font-size in CSS, so I had to turn to JavaScript to calculate my font’s size based on the DOM window size. A few years back, our Web developer Brandon Groff worked with me to write the JavaScript that would do this, and the effect was most elegant: here’s a quite plain example.

A few notes:

1. JavaScript recalculates the desired font-size based on the window size and reloads the page on resize
2. The font’s proportional size is based on a JavaScript variable that can be static or adjustable
3. Changing the value in the text input before resizing alters the font-size’s proportion. A “1″ roughly equates to 100% of the body’s width.
4. At least one known bug: if the user increases or decreases the font size through their browser, the script it breaks.
5. This JavaScript is a bit old, and I hope to evaluate it line by line for currency and efficiency.

Roger Johansson posted up a good, general review of the new O’Reilly book, “Designing Web Navigation”. The first question Johansson asks is a good one, i.e. “We need a whole book on designing Web navigation?” If you’ve ever struggled with navigation of a Web site, or know anything about the idea of the “scent of information” I think you’ll agree that the answer is, “Yes.”

Chris Lott, commenting on his institution’s acquisition of Elluminate video-conferencing platform as a teaching tool concludes,

The real issue with any of these tools isn’t finding one that works, it is learning– and then teaching colleagues– how to teach in a way that takes advantage of the capabilities and doesn’t merely replicate the lecture mode in a distributed format. That’s deadly. As I always say, the only thing more deadly than the PowerPoint drone and lecture model is that same model through a mediating tool like Elluminate…About Elluminate

I agree that when video-conferencing avoiding replication of ineffective lecture modes is important; however, always the devil’s advocate (well, at least 50% of the time), have to ask, first, if this is a blanket condemnation of the lecture mode regardless of delivery method, or if the technology itself interferes with, disturbs, or detracts from the traditional lecture (which may in a classroom actually be effective).

I’m guessing most folks in educational technology or instructional design lament the continued use of straight lecture format (“sage on the stage”) regardless of delivery environment, but I, having been a student in more than a handful of damn good and several quite memorable lectures (from which I still retain a significant amount of information), causing me to assert that straight lecture is not de facto a bad thing.

At this point I have absolutely no empirical evidence that suggests straight lecture is or can be highly effective, but now (from this small comment tacked onto the end of a technology tool review, no less) I’m inspired to look into it. Comparitively speaking how effective is lecture for learning? What makes lecture more or less effective? There has to be a good deal of research on this already. (Any recommendations on salient books/articles are now being accepted!)

I can name some ailments of lectures delivered via video conferencing that I have witnessed. In both edtech informational sessions and in vendor presentations delivered via video conferencing, presenters do tend to follow a simple, generic pattern (much informed by PowerPoint) which centers on providing text-and-talk-heavy information in tedious spurts with brief pauses for “questions” (which, in and of themselves, often occur too late or at moments so ill-planned moments that they actually increase the presentations/presenter’s anesthetizing qualities). Any questions posed rarely lead to real dialogue or discussion; rather, questions are merely a challenge that the presenter must overcome before being allowed to continue with his/her script.

And though these ailments can certainly be present in a live, in-person classroom-style lecture or presentation, my instinct tells me that there’s something about phsyical human presence that either reinforces the delivery of the information, or provides for better audience attention through either overt or more subtle person-to-person engagement.

The next question, then, would be how does technology deliver methods affect the effectiveness of lecture? Video conferencing in particular should be examined, though of course some common attributes will need to be agreed upon so as to include a live fiber-optic system like we have at UVSC, or an Internet-delivered system like Elluminate.

I would hypothesize that a boring lecture in the classroom becomes worse when video-delivered, either because it becomes (a) less interesting for lack of physical presence (for whatever reason…engagement?), or (b) less compelling to one’s attention when technology-delivered (possibly because of the presence or availability of more distractors, or because of the absence of social pressure to show interest/passively participate).

It would be interesting to brainstorm presentation effectiveness on tech-delivered platforms with some ed researchers and public speaking experts. How does one leverage the live delivery method so that the end results are superior to static information delivery? How does one construct information to affect better learning? How does one engage with the audience and make an impact that may stimulate memory a la the affective factor?