Jul 302015

I’ve been collaborating on a course with my colleague, Tanis. An unexpected benefit has been the ability to float an initial idea, talk about it, and have it improve from the discussion, from feedback, and from new ideas these things engender.

I want to talk about one of those engendered nuggets. I’m a bit hesitant, because when you get to the end, you may well think “Yeah, so?” For me the path was well worth following, and I might not have taken it without the back-and-forth with Tanis. So this is another form of working out loud.

The topic doesn’t actually matter much. If you’re curious, see the following aside; otherwise, just skip past.

About the topic:

Many pension plans allow purchase of service, a way for a person who hasn’t contributed to the plan (for example, during a leave of absence) to pay additional money into the plan. That payment is the purchase. The person then gains credit for the corresponding work time–that’s the service. Purchasing service can increase the amount of your eventual pension.

Different plans have different rules and coverage, and within a plan there are usually several types of purchase of service. You can see typical examples here (for an Ontario plan) and here (a Pennsylvania plan).

Some pension plans use other terms, but purchase of service is the one we use.

The nugget emerged as we juggled three goals for the first part of our course:

  • Introduce a new type of purchase
  • Connect this new type to what people already know
  • Provide a framework to show what the various types of purchase have in common

Employees taking our course would already have learned how to handle certain purchases, like the leave of absence mentioned above. In the new course, they’ll learn the details for purchasing arrears (payment for a period when contributions should have been made to the pension plan but were not–for example, because of clerical error).

Version one: framework → known → new

I can picture the right framework.

CC-licensed image by João Moura

Working with internal documents and with our subject-matter experts, we discovered a pattern that seemed to apply at a high level to all purchases:

  • Circumstances occur that make a purchase possible.
  • The plan receives an application for the purchase.
  • Plan staff analyze the application to see whether the purchase is permissible.
  • Plan staff calculate the cost of the purchase.

There’s a lot more to it, and there are nuances and conditions for each of those, but it didn’t seem like a bad framework. Having laid it out, we could ask participants how a leave-of-absence purchase would fit into this, since they’d already know how those purchases work. Then we could start talking about arrears purchases, to show how at this level they’re like other purchases the participants have worked with.

On second or third glance, though, this version felt abstract. Our plan staff don’t work directly with frameworks; they work with the specific purchases. And so we moved to…

Version two: known → framework → new

In the revision, we decided to start by describing out a leave-of-absence purchase according to our framework: a person goes on maternity leave; she later applies to purchase the service; the staff evaluate the application; we provide a quote for the cost. We’d make sure participants saw how at a high level thus was how the LOA purchase worked. Finally, we’d introduce arrears purchases using the same framework.

Yeah, yeah, I know...

CC-licensed photo by MTSOfan

This felt better, in no small measure because we began with the specific and not the abstract. And we felt we were doing a better job of connecting to what people already knew.

As we worked on other parts of the course, we’d revisit the intro. Gradually we began to feel that we were explaining for the sake of explaining.

I’ve been in the instructional design field longer than Tanis has, and I feel as though I should have known better. It’s always tempting to try and make things clear. As we poked at this, though, we realized that the key point is not that a leave-of-absence purchase follows these four stages, and so does an arrears purchase.

What was important? Knowing about LOA helps you to learn about arrears.

Version three: known → new

Here’s the sequence we now have–and in the course, the sequence takes much less time than you’ve spent reading this post:

  • Ask participants to describe the phases of a LOA purchase, from the member’s point of view, in 25 words or less. (We don’t care about word count; brevity encourages big-picture summary.)
  • Show a diagram with LOA information illustrating our four phases: the maternity leave, the application, our research, the cost estimate. Discuss how the experience of the participants aligns with this pattern.
  • Redraw the diagram with an arrears purchase replacing the LOA one.
Plenty of purchase

CC-licensed photo by James

We really like having the participants start by sharing their own ideas about the processes involved in the purchases they already work with. We then show our summary (the LOA in the four phases) and make sure they see their own experience in that summary. Finally, we can start talking about arrears.

So now we don’t belabor the four phases; they’re just stepping stones between the familiar and the new. We’re inviting participants to build the connections that work for them.

What comes next? We use this intro as a springboard to what’s different about purchasing arrears. We ask participants what they think might trigger an arrears. If they already have an idea, great–we can reinforce that. If they don’t, that’s okay, too; their interest level is higher as we move into the explanation.


Jul 282015

Joe Ganci, a prolific and generous e-learning consultant, just published a column in Learning Solutions Magazine: The State of Authoring Tools: Where We’ve Been, Where We’re Going.

I think it’s worth reading in full, especially since Ganci’s experience is deeper and far more recent than my own. His reflections on the origins of e-learning triggered a number of thoughts for me, and this post is a sort of extended comment on Joe’s article.

CC-licensed image by Patrick Finnegan

Oh, boy, we’ve got learning NOW!
(CC-licensed image by Patrick Finnegan)

He mentioned two of the ancestors of modern elearning: PLATO and TICCIT, both of which began in the 1960s. I first encountered mainframe-based computer-based training (as elearning was called then) in 1978 via the IBM Interactive Instructional System, and two years later was the head of a team developing training for Amtrak’s new reservation system, using a competing product, Boeing’s Scholar/Teach 3.

It’s telling that I couldn’t find a worthwhile link for either of these last two.

I also remember a long-ago conference where someone asked, “How many of you have seen PLATO?” Nearly every hand went up. “How many of your organizations use PLATO?” Not a one.

In 1979 I was put in charge of developing CBT for Amtrak’s new reservation system–to new it was still under development as we learned the authoring system and started designing the courses. Our IT department got the CBT software up and running, but we were left on our own when it came to using it. So I had to teach myself and then my team quasi-programming concepts like using variables to track progress, record quiz results, and control paths within a course.

I clearly recall the next stage of elearning, a proliferation of chip-laden devices rolling through trade shows like the Bandwagon Express. When Joe mentioned the two Authorware camps — icon-draggers and codeheads — I recalled a set of definitions that’s served me well for years:

Easy to learn: hard to use.
Ease to use: hard to learn.
Easy to learn and easy to use: won’t do what you want.

The reality is that the people who buy elearning systems (as with much other organizational technology) are not the people who have to use them, either as developers or, alas, as learners. Hence my agreement with this passage in Joe’s article:

Very often we hear vendors say that we no longer need instructional designers because the tools are so easy to use that Harry the Engineer can create the engineering course himself, or Susan the Physicist can build that physics lesson herself. The bean-counters in those organizations buying those tools are psyched at all the money they can save by not hiring or contracting instructional designers (and of course programmers) to fill their learning needs.

They don’t know, of course, that the resulting lessons are often at the very least anemic and at the worst nothing more than boring text and images punctuated with a Jeopardy game and quizzes. Learners end up expecting their eLearning to be onerous and are resigned to getting through it as quickly as possible and in some cases cheating if they can.

Some of those people may have taken a course I once worked on, aimed at supervisors. The client insisted that a lesson take two hours to complete–because that was the standard required by the state of California for the topic at hand.

This approach and similar ones have nudged corporate elearning ever closer to to the status of Death By PowerPoint, only with voiceover. And the inevitable Jeopardy review.

Formal training in organizations has always struggled between flashy features (the ooh!and effective learning (the ah!). Far too often, the ooh wins — so you’ve got terabytes of animated demos of corporate systems, with the apparently mandatory click-click imitation typing, yet almost never a way for people at work to practice safely in the actual systems (such as via a robust training mode built into the system).

I admire Joe Ganci’s optimism, and I couldn’t agree more with this opinion:

If you ask yourself, “What will my tool allow me to do for this audience and this content?” then you’re asking the wrong question. The real question should be, “What is the best approach to have this audience learn and so what interactions should I build?”



Jun 192015

Lots of people in my extended network have been working out loud — sharing what they do, and the thought process behind it — long before #WOL as a term got very far down the street. This informal reflection (often followed by informal exchange) has made a tremendous difference in how I learn things and how I get better at things.

If you’re not familiar with the idea, for starters there’s John Stepper’s book, and there’s Jane Bozarth’s Show Your Work. In both cases the emphasis is not simply on what gets done, but how it gets done.

Before the week’s over, I wanted to go out loud with a small item that’s produced a lot of progress for me in the past six weeks. I’d like to have something more obviously impressive, but I’m going with “personally worthwhile.” I can’t find the original source — most likely because it’s buried in the cognitive junk drawer of my Twitter favorites. But the idea is this:

Tick, tick, tickIf you’ve got some future goal — say, you’re giving a presentation in four months — there’s research to suggest that framing your goal in days, rather than weeks or months, is a much more effective way of spurring yourself on.

Try it yourself: which has more psychological weight? “I’ve got three months” or “I’ve got 91 days.”

The notion intrigued me, and with not much searching I found the Countdown Widget at the Google Play store.

The day I installed it was four months ahead of the target I’d set for myself. But the widget counts down in days — so it displayed 120 on my phone.

As you can see in the screen shot I took this morning, that’s now down to 78. I’ve got work to do this weekend.

I made sure to put the widget on the home page, and so every time I glance at my phone, I’ve got a double reminder of the schedule I chose: the number of days appears, and the bright ring around the number disappears, bit by bit, with each passing day.

What this has done for me is probably what end-of-the-day reflection does for other people, or a carefully tended to-do list: I look at this and ask myself what I can do next to move forward toward my goal.

Another out-loud angle: I talked about this with a co-worker, and at least three times a week she’ll notice the countdown on my phone and ask what I’ve done on my project lately.



May 112015

I started to write about learning new software. But no one learns software for its own sake. Software’s like a second language: you learn it because you have a goal. Even the well-intended “everyone should know how to code” silliness has a goal, which is less about coding and more about something like logical thinking, understanding complex systems, or producing a result that the coder finds worthwhile.

I decided I wanted to write about two things: why I wanted to learn this particular software, and how I’m not learning the way the program’s developers think I should. I’m not even learning the way I might have thought I should. It’s going to take me a couple of posts; this is the first.

What I wanted to learn

Last year, I joined the Victoria Gaelic Choir. Gaelic (Gàidhlig, Scottish Gaelic) was the language of my ancestors and even my grandparents. I know only a few words and phrases, but I’ve know Gaelic singing for a long time–and if you don’t, there’s a list at the end of this post to get you started.

As I said last year, this opened a clutch of challenges. I needed to learn lyrics in a language I don’t speak–one whose spelling and pronunciation aren’t always easy for an English speaker:

O seinnidh mi dàn do dh’eilean mo ghràidh
(O, I’ll sing a song to the island that I love)

“oh shay-nee mee dawn doh yell-un mo gr-eye…”

And before the lyrics, I needed to learn the melody for many songs I’d never heard. (Tune first, words second; trust me.) Even for those I did recognize, I needed to learn the tenor part.

I can pick out a tune or a tenor line on guitar, but that’s not a practical way to learn a choral piece. I seriously considered buying an electronic keyboard, but my son (thank goodness) suggested I experiment with a 30-day trial of Sibelius First.


With Sibelius, I know what I’m doing. Or what I should do.

This $120 package lets you compose music on your computer and share it with others. I didn’t plan any composition, but the features that caused my son to suggest Sibelius include the ability to scan printed sheet music, to create an editable digital score, and to export sound files.

Sheet music to an mp3? Does it work?

Let me show, rather than tell. That line of Gaelic above is from Uibhist Mo Ghràidh (Uist, My Love), an archetypal Gaelic song about the island of North Uist, where my mother’s people came from.

O seinnidh mi dàn do dh’eilean mo ghràidh
far an d’fhuair mi m’àrach nuair bha mi nam phàisd’
Far am bi mo chrìdhe gu deireadh mo là
ann an Eilean Uibhist an eòrna.

O, I’ll sing a song to the isle of my love
where I was raised as a child
where my heart will be to the end of my days
In the Isle of Uist of the barley.

If you want some idea of how I felt when everyone else in the choir knew this, listen to Linda NicLeòid — Linda MacLeod — singing. (I’ll resume below below the video.)

A recording like this demonstrates the melody, and from Wednesday night choir practice I had a nodding acquaintance with the tenor line. But “once a week” takes the idea of spaced practice to an extreme. I needed to hear the tenor part on its own, a lot, so I could practice.

I chose Uibhist Mo Ghràidh for this post to show what I was able to do after working with Sibelius off and on for about three months. Starting with a good copy of the sheet music, arranged for soprano, alto, tenor, and bass:

  • I scanned the music into Sibelius.
  • I edited a few errors the scan didn’t quite catch.
  • From the digital version, I exported audio files for each part and for the four parts together.

Sibelius allows me to choose instruments–which means I can make the audio sound like piano, or like human voices. I went the latter route. Here’s the full choir audio, and here’s the tenor part.

The audio comes out as .wav files. It takes me less than a minute to convert them to mp3s, which I can then send to my phone or share with other members of the choir.

That’s where I went. Next time: how I got there.

It’s taken me a while to write this post, because I kept rethinking what it was I wanted to learn and how I could explain the context. If I had to summarize my own learning goal, it’d be “have the tune for the tenor parts to Gaelic songs I want to sing.”  That’s an oversimplification, but it was also a 14-word target I wanted to hit.

It took some effort before I could hit it, and the process of that learning is what will be in the next post.

Those Gaelic songs I promised

Raylene Rankin
(Click for an appreciation from the Halifax Chronicle Herald)

Song may be one of the most enduring ways to preserve and transmit a language. Here are a few examples–the links in the song titles lead to a recording of the song. When I’ve been able to find an online translation into English, I’ve put a link for that as well. (The links are set to open in a new window.)

Nov 202014

In a previous post, I showed a fictionalized example of an actual guide for assembling a piece of industrial equipment. These instructions weren’t particularly well done, and I set myself the task of making some improvements. I also wanted to explain what I did, and why I thought it was an improvement.

Revision, page 1

Revision, page 1

The original, written on seventeen sheets in an Excel workbook, had more than 50 steps. I didn’t fictionalize them all, and I haven’t tried to revise them all. I’ve done two pages (that cover what 5 of the original pages did). I think these revisions are representative. (You can click each image to open a full-sized version in another window.)

By the way: I don’t have any documentation other than what’s in the original widget vat instructions. In some places, I’ve made an educated guess about details that aren’t clear; in other cases I made things up. I’ll point these out along the way.

On to the revision!

Why my version looks this way

We’re guiding a task that’s mainly a procedure: a sequence of steps that follow one another logically, with relatively little decision-making.

Revision, page 2

Revision, page 2

I see this as a job aid for lots of reasons, including the large number of steps. A number of my revisions are part of what any good job aid should include.

A clear title

The original read “Main Assembly Instructions,” which is ambiguous at best, unless Quasimodo Corporation only assembles one thing.

Here I’m pretending that there are several models of widget vats that differ mainly in size. I’ve put the model numbers into the title so the assemblers can tell easily if these are the instructions they want.

First things first: safety and prerequisites

Every page of the original version had a box listing the same three pieces of safety equipment–as if the developer thought the assemblers might take off their safety glasses between pages 11 and 12.

I’m also pretending that the “submittal drawing” spells out things like how many fasteners you need of each type. If that were not the case, I’d have to find out from my client whether (for example) the fasteners were stored at the assembly point, and if so how the workers could get more when they needed.

Emphasis techniques

Emphasis techniques

Emphasizing what’s important

The original version didn’t make much effective use of contrast, alignment, or spacing, so it’s much harder to figure out what’s important. That’s one reason I’m a fan of language like “before you begin.” In my revision, that stands on its own as the header for a number of items that we want the worker to do before starting the assembly.

And rather than the original’s unfortunate use of ALL CAPS, I recommend using capitals, boldface, or similar techniques in specific, limited circumstances. One of those circumstances is to highlight words like DO NOT, EXCEPT, DANGER, and so on.

Don’t confuse people with detail

Although the original used over 50 photos, in my revision I’ve hardly used any. In part that’s because I didn’t have good replacements for the photos–but also because many of the original photos fail to contribute useful guidance.

One problem with the original images–and with photos in general–is that they often provide too much detail, making it hard to grasp what’s important in a particular step. Or they ignore context, also making it hard to grasp what’s important.

Take a look at these three examples on one page of the original (click to enlarge):

Details from the original instructions

Details from the original instructions

Drawbacks to these:

  • Left: Why do I need to see a picture of the parts cart? The instructions say it’s important to push rather than pull the cart–but they don’t say if there’s a specific end I should push from. If there is, show it. If there isn’t, spell that out.
  • Center: you might be able to figure out, after studying this picture, that you’re viewing the assembly area from the side–but you can’t tell whether the top of the assembled widget will be on the left or the right.
  • Right: the instructions tell you:
    • In my first revision, I’d missed the “four chocks total” part, which implies that neither the all-caps approach nor the FOUR (4) text/numeral approach helped.

image fix detail 2Although I didn’t have much to work with, I have a couple of examples of images I think would work better.

The top picture in “image detail” shows a closeup helpful for one assembly step: the flanges should face up, and they should face out from each other.

(Yes, I made up the term “bleem flange.”)

The lower picture is a line drawing rather than a photo. Line drawings are a great way to eliminate unnecessary detail. I’ve teried to reduce details to the essentials: you’re fastening two (more-or-less) L-shaped pieces together, and you fasten through holes that alternate large/small/large/small.

(I’ve made the assumption here that the assembler should alternate directions when fastening these things: one fastener from one side, the next from the opposite side. If it were important to do that alternating while fastening, I’d add a box to spell that out. If you can install all the fasteners from one side, and then from the other, I’d spell that out. )

Some  problems in the original version stem from the decision to always use three photos per page in the original. That’s a lot like deciding that you need to use one semicolon per paragraph: not wrong, exactly, but needlessly specific.

What I’d do instead:

  • Leave out the cart photo. My assumption: the assemblers know what the parts cart looks like. If they don’t, they shouldn’t be assembling widget vats.
  • Possibly include a close-up of the portion of the cart that I’m supposed to push, assuming there’s some sort of handle or push plate.
  • Use a bird’s-eye-view line drawing to show the layout of the assembly area.
    • In the text for this step in my revision, I made up some floor guidelines to show “top” and “bottom” of the assembled widget.
    • I also made up guidelines on the frame to show where to place some of the initial pieces.
  • Clarify where to place the wheel chocks.
    • Chock one wheel of each assembly fixture.
      • Written this way, it doesn’t matter how many fixtures you have, so you don’t need the FOUR (4) business so beloved by people writing procurement specs.
    • Place the chock so it’s closer to the center of the fixture than the wheel it’s touching. (If this is a best practice; I have no idea.)

Trying to build a useful set of performance guides like this can be a tool for analysis tool as well. You can’t create a successful guide without knowing what the inputs are, what the process is, what the outputs are, and what the standards for success are.

How many assembly fixtures do I need? On the framework, which side represents the top of the assembled piece? Can I install 20 fasteners in one direction, all in a row, and then 20 in the other? And what the hell is a “submittal drawing,” let alone the cryptic “BOM?”

What’s more, you can identify items that don’t need to be in the guide. Frankly, I think it’s…perhaps less than helpful to list “vat part cart” as an assembly aid. That’s like saying, “In order to build your IKEA Poang chair, buy the Poang chair and bring it home.”

The changes here, and the reasons behind them, apply to most performance guides like this. In my next widget vat post, I’ll show some revisions I’d make that are specific to procedural or step-by-step job aids like these instructions.