I think that relational concept mapping can have a tremendous clarifying effect. I would bet that this visualization may also aid in task recall.

I believe this is similar to what you mean. I’ve been drawing this simplified diagram to illustrate the concept foundation for awhile. I read and assimilate so much stuff on a daily basis I couldn’t tell you if it’s original or not. So if it’s original I attribute it to me – if not, it’s someone else’s:)

http://www.xpconcept.com/conceptRelationship.jpg

While modelling the behavior of using the system is important contextualization, I want an underlying conceptual model of the tech software, the handheld system, etc.

I have been thinking about the models in a different context. I considered the models as schema with the basic principles and concepts as the building blocks of the schema. For example, the principle of using a path and the concept of path itself would have been the elements to the schema/model of understanding in the Freehand case.

My key challenge is creating schema/models for many of the learning items I create. Sometimes I feel that a particular schema needs as sub-schema, which may mutate into a parallel schema/module altogther. I think I have a problem with multiple models, and very likely it is my inability to process multiple schema/models in a given context! :) Thanks!

In the past we have created software training for a handheld device that was also connected to the larger enterprise system back on the office floor. There were different roles that interacted with this software, right from on field sales people to the managers on the floor. In this case we first identified a path for learning which took into account the common components of the software, followed by role based components. In every section, we used scenario/problem based learning by picking up contextual situations of everyday business. for e.x we identified life of a sales person before and after introducing the software. We listed down X activities that he/she would now do using the software. Every activity was explained through a real life scenario that demonstrated the keystroke steps using a voice over.

We personalized the whole experience by introducing agents who would perform the tasks. So if field staff had to check on inventory before accepting an order in front of the customer, they could do that using their handheld device. To teach this we created a pseudo scenario where a customer places an order and oriented the learner on the steps accordingly. Obviously this would have been impossible without the dummy data provided by the SME’s.

The point is, rather than having tutorials, that explain what each functionality can do It is much more motivating for the leaner to see how functionality works in everyday life. The “WIIFM”
quotient is better in such cases.

If you’ll permit me, I think I have an example for Sameer that illustrates your comments.

We were asked to develop software training for a new support application that our repair technicians would use. The techs were in customer’s homes servicing home appliances and electronics. The software managed the technician’s day (providing a route of customers they would meet that day) and provided visibility to each service order (history of that particular product, warranty information, etc.). Each service order ended with payment of some sort – either internal because the repair was covered, or actual payment by the customer.

As Clark described, we could have easily designed this training to be an item by item description of each feature/function in the software. But that would have decontextualized for the associate when or why to do certain things.

Instead, the model we used was the technician’s day – linking software function to external triggers. When I wake up I need to do “X”. When I get in the van I need to do “Y”. The reason to use the software existed in the larger context of going about my day. As such, there were external influences that dictated when to do things, as well as external processes that the tech’s use of the software would trigger. Without this broader appreciation the techs would have little understanding of the impact their use (or misuse) of the software was having.

In addition, as Clark mentions about multiple representations, the training program create this awareness in different ways. Some early scenario’s simply started with textual narratives of what the tech should be doing with the software. Other scenarios brought in first-person interaction, where the tech would need to do things based on video of managers or customers that should provide the tech with external triggers. Finally, some scenarios relied on a third-person perspective – having the tech observe another tech’s actions and determine whether the actions were correct or not, then justify their responses.

This elaborate model helped provide real world context of how the software fit into the tech’s daily life, and also provided a greater appreciation for what happened ‘down stream’ based on their actions.

Hope that helps, Sameer. Clark, please feel free to tweak my illustration if I may be misrepresenting your ideas around modeling.

I was trying to learn to use FreeHand (had a free copy), and the tutorial had me build a picture with a cone and a sphere. The problem was, I wanted to use it to build the Quinnovation logo, which splits across the shared letters (inn). What the tutorial didn’t explain, and should’ve, is that the primitive element of Freehand is a path, and that those shapes (cone/sphere) were actually made of paths. I eventually found out that I could even convert fonts to paths, and then slice it with the ‘knife’ tool, and voila’, I got my logo (and the concept). So, I would’ve created the model that objects are created out of paths, and can be dis/aggregated, and that conglomerations are useful compounds, etc.

I may be doing this in the near future, as we assist some software vendors to tighten up their training.

Does that help?