May 17, 2016
|
Things I learned from my presentation feedback
|
8231 hit(s)
At the end of March I gave a presentation at the ACES conference on "Tips and Tricks for Using Microsoft Word Styles." For years I've taught a class about Word styles at Bellevue College. My experience is that even people who use Word don't necessarily know all the ins and outs of using styles, so when the call for papers for the conference came out, I submitted a proposal. It was accepted, and I was given a 60-minute slot.
I spent a lot of time preparing for the session, agonizing about what material to include. Much of my indecision was because I simply didn't know who my audience would be. Would there be people new to styles? Were all of my tips already old hat to an audience of experienced editors? Plus I only had an hour, which I know from experience seems like a lot of time, but is nothing. (My course at BC runs 6 hours.)
I ended up presenting a quick overview, and then a lightning tour of how to apply, create, and manage styles. Along the way I threw in tips that I reckoned could be useful to even people who had worked with styles: keyboard shortcuts; tips for naming styles; style inheritance; styling TOCs; taming multi-level list styles; and more. There were about 60 people in the room.
I got the evaluations back recently. There was enough positive feedback to suggest that yes, it was a useful session and that people got good information from it. Big relief! A number of commenters indicated that they liked "technical" sessions, which I hope means I'll have another shot at a session like this.
What was particularly useful, though, was feedback from people who had suggestions or complaints. There were several classes of feedback that I think I've learned different lessons from.
Not the right level. Some felt it was too advanced; a few others felt it wasn’t advanced enough. (This was, of course, precisely my fear.) The solution here, I think , was suggested by more than one person: the session description should have indicated a lot more clearly what level I was aiming at. I got to write my own session description, so this was well within my control.
The session was fast and there was a lot of (too much) information. Boy, this one is a dilemma. There's only an hour, so how do you make it less rushed? One solution, obviously, is to spend more time but try to get through less information. I guess this is possible if I also do the previous, which is to set expectations correctly about what we'll cover.
No hands on. The conference organizers had told me that people like hands-on sessions, and I can see why. But I know also that when people are following along, the pace is just slower, and I knew we would already be pressed for time. I think a solution here might be to request a longer session time (some 90-minute slots are available), or to think about creating an online course.
No Mac information. Someone noted in a slightly annoyed comment that I was unable to answer questions about Word styles on the Mac. Boy, I really dropped the ball on this one. Although I don't use a Mac myself, I know that many people do, and I should have been able to explain which of my tips did and didn't apply to Macs. I won't give this session again without fixing this issue.
All in all, it was a gratifying experience. As with most teaching, the need to present information cohesively forced me to organize and articulate stuff I had floating around in my head, plus I was obliged to research some corners of Word that I knew about but was fuzzy on. Armed with my list of ways to improve the session, I'll pitch it again for the next ACES in conference.
|
|
