Rectangles, Bottlenecks, and Judo

It's an old dilemma with the technology - should it accommodate what the user wants or should the user adjust to what the technology is capable of? Bottlenecks occur when the user expects the technology to deliver something that the technology is incapable of. Frustration ensues.

We've got a brand new classroom building with 18 swank classrooms, very well equipped. The last few days I've attended some training sessions, to help get the instructors ready for when classes start, a week from Monday. The sessions are very complete and cover all the functionality that is possible. Yet a little detail is missed, one that can create a bottleneck.

The native resolution of the projectors is 1024 x 768. It is now common for the instructors to have higher resolutions on their office computer or on the laptop they bring with them to the classroom. So they design their content in a view that the can't replicated on the classroom screen. Ditto for the pastel colors they use for fonts.

I've seen a similar problem with instructors who teach with a Tablet PC, which can be used in two different orientations, portrait or landscape. Portrait has the advantage that it seems like a piece of note paper and is thus more natural for writing. The projector, however, is designed for landscape. Standard computer screens have width exceed height. The projector can project the tablet image when in portrait mode, but only by shrinking the image and putting black bars on the sides. We've got a flat panel plasma TV at home and the same thing happens for TV signals that are not in High Definition, though the TV is smarter than the classroom projector because it enables other modes - stretch, zoom, and partial zoom, each a way to reduce or entirely get rid of the black bars.

Nobody explicitly taught me this, but I believe an important role for the learning technologist is to anticipate the bottleneck and make suitable accommodations, an approach akin to judo. Regular IT people don't do this, because it is not their primary responsibility to ask where will users go astray. Many years ago when the SCALE project supported FirstClass in a serious way, the staff produced an a manual about how the software function. It was thorough and well done in that it had many screen shots to illustrate the functions.

But in one way it was quite poor. The biggest bottleneck for users was that after they installed the client on their home machine, they didn't know how to get it to talk to the server. The configuration info for that was in the manual, to be sure. But it appeared on the penultimate page and as I recall the manual was twenty pages or longer. Many users couldn't find the info at all, because they didn't know how to look for it. It should have been on the first page.

I find myself doing this as a matter of habit and then get frustrated when that info is not presented but other functionality that users can discover on their own is covered. C'est la vie.