Sunday, August 22, 2010

Being Explicit, or I think we need to talk about this

Another busy week--so busy that I didn't get a chance to post last week. In addition to teaching last week, Jan and I drove to Ottawa (wonderful week there: ate at the Sweetgrass Bistro with some new friends and Serena Williamson who gave us a copy of the CD she based her one woman show around, prowled around Byward Market and brought home some unpasteurized Quebec cheese, cool sausages, and duck fat). Learning Tree's marketing arm wanted some input from me about the SOA course I wrote for them (running for the first time in New York near the end of September and then--possibly--in Chicago). In there, I was also commissioning and editing articles for Learning Tree's Management Insight's newsletter and trying to get caught up with my responsibilities with Visual Studio Magazine (who are being incredibly patient). I did a little bit of software development in there, also, but it will be this week before I can really get to write code again. Oh, I almost forgot: I edited an early draft of my son's book on Transformers (there's more than meets the eye, there).

I also was doing some course development work for one of my clients and one of the first reviewers brought out a key point that I hadn't discussed. The material I was working on centred around creating a community in a social networking tool. The reviewer pointed out that users didn't have to enter all the information required to set up the community at one time: They could enter part of the information, save their work, and return at a later date to complete setting up the community. If a user was going to employ this tactic they'll want to leave the community's access level at "private" so no one can see the community until the user does complete it.

I came up with what I thought was a great way to cover this material. I went through the whole "community setup screen" covering all of the options during the "lecture" part of the course material. Then, in the "exercise" part of the course material, I walked the course participant only through the initial steps of setting up their community. After the first few steps, I suggested that the participants save their community and finish it later--pointing out that they should only make the community public when they finished setting it up. This would let the user see the tactic in action rather than just being told about it.

A later reviewer didn't notice my clever way of addressing this tactic and asked if we intended to cover it. We decided to insert a new bullet in the lecture portion of the course that explicitly called out the tactic. And, you know, I'm not sure that's a bad thing. I think that allowing the course participant to see, discover, and experience things is very valuable. But I also think that "saying things out loud" is important to, either before or after the experience. I know that I don't really remember anything until I see it in print (and I also recognize that may just be my personal kink).

Looking back, I can see that I'm moving more towards calling out material after giving the participant an opportunity to use it: Let the participant have the experience and then step in afterwords to help the participant make sense of what just happened. But the calling out part is still important I suspect that I might be omitting that.

And, by the way: My client's client (who we're building this course material for) has an amazing style guide. Fortunately, I'm not expected to memorize it because there's a dedicated reviewer who either brings my written material in line with the style guide or points out where I have to modify my text to be in line with the guide. The guide covers everything (for instance, using "because" instead of "since" unless referring to an ordered set of events). I suspect that I could start implementing some of the style guide when I write but I'm not sure that having the reviewer apply it isn't the most efficient use of everyone's time.

Reading or read

No comments: