Tuesday, July 17, 2007

Day 2 eLearnDevCon - Exquisitely Frustrating

The thing I love and hate about conferences like this is the number of great ideas I’m given. I love the intellectual and creative rush of seeing other people’s work and how they did it. I hate that I have no time to go play and attempt to implement some of these ideas in my own world.

So here’s my list of things I want to do over the next year or so as a result of what I saw today. If I accomplish ONE of these things, I’ll be a happy camper.

1) Build one educational game.

Mark Henry gave some really solid advice for planning and designing an educational game. He uses a fairly common process improvement practice as his planning strategy – capture the current workflow (and ask the people who actually do the work rather than the managers), then strip things down to the necessary.

His example – Apple’s 1978 Lemonade Stand. A simple and elegant simulation of entrepreneurship. Play it and let me know what YOU think you learned.

Here are some of my notes from his discussion:

Capture and Model the Business Practice
- Start with flowcharting the practice/process at a high level.
- Identify all of the relationships within the flowchart. The who or what does what.
- Also identify any external factors
- List what collected, manipulated, and passed on by those relationships (find the inputs, processes, and outputs)
- Gotta be able to articulate all of the pieces otherwise developer can’t help.
- Do for ALL of the pieces
- Gotta be as MINUTE and as detailed as possible.
- Take 1 item and list all of the possible variants / versions of that item.
- Identify what is within and outside of acceptable standards for those components. Take the variable – what happens when you deal with that variable. Converting into rules to run the simulation.
- Discover the casual factoid. What determines if those components are within or outside of acceptable standards? WHY do these variables behave this way? Why for these rules.
- Map all this out. Discuss with CURRENT WORKERS to validate. NOT MANAGEMENT. These guys are in the trenches.
- Adjust and update your model based on that input. Refne and revalidate until you’re satisfied.

Abstracting
- If you did your job modeling LOTS of info. Now - strip down to what is necessary.
- How do you know what is necessary?
o What does the audience have DIRECT influence over. The basis of the cause / effect. (Basis of the user interaction)
o What will effect them. What parts do they NOT have influence over but will effect their effort. (Game variables and algorithm)
o How important it is to the business that the student, understand, appreciate and have ability to CONTROL the cause and effect.
- Create model

Once all this is done, create a real quick and ugly prototype for proof of concept.
- Get comments from the trenches. Revise and validate until you have a finished product.

I walked out of that session truly inspired.

2) Seriously upgrade my Flash and ActionScript chops.

Adam Brown did a very fast-paced demonstration of ActionScript 3.0. I’ve done a little bit with Flash MX 2004 and ActionScript 2.0. Nothing terribly complicated. And I’ll admit that most of my ActionScripting has been of the copy / paste / and troubleshoot variety.

That may not change, and Adam is a die-hard hard-coder, but I figure that if I can improve my Flash chops, the technical quality of my tutorials will improve dramatically.

3) Figure out how to build Google Gadgets from scratch with feeds from my Moodle tutorials or some other source.

It would be really nice to build a robust desktop help tool for the Electronic Medical Record we use. The Google Desktop Sidebar may provide an option for delivery of the brief tutorials and materials at the point of need rather than forcing the user to navigate away from the program.

I have to think about the design. I’m learning that straight text may really be OK.

It looks like there’s some XML and database stuff involved. I’ll probably ask Dick Carlson for more information. He talked about how to build this beast briefly, but I was too busy playing with Google Desktop and didn’t pay as much attention as I should have.

I call this the independent Hands-On learning seminar….

4) Figure out how to build learning for mobile phones

Well, maybe not learning so much as checklists and references. Of course, this may require that I finally break down and get a “real phone”. You know, one that does camera, texting, internet and, oh yeah, phone….

Side note: I did get a chance to see the iPhone in person at Monday night’s dinner. The coolest thing about it – the graphics….. The touch screen, however, makes me uncomfortable. In practice, I’ve found touch screens finicky. Not having particularly solid small motor skills doesn’t help….

Overall – the technical presenters have been very honest about the strengths and limitations of the tools they use and have shared some good workarounds.

I hope to do just as well during my sessions.

2 comments:

Karyn Romeis said...

To add to your opening parapgraph - the other thing I hate is that cold stone in the bottom of your gut that tells you that there is no way on earth you're going to be allowed to try any of this for real when you get back to work!

Brent Schlenker said...

Wendy, I think building a Google Gadget sounds like fun. Let's get some people together online and start learning together virtually. Perhaps Dick could lead us?

Karyn (and Wendy), Let's tear down those walls and get some of this stuff tried out. Sure, there are some barriers that are just part of your particular situation. And those may stop certain technologies from happening. But there must be something that you think MIGHT get some grassroots traction...eh? There's a whole community out here ready to support you. Just start the conversation!