Wednesday, July 30, 2008
*Explain two of the reasons why Ranjith.A.R doesn't like learning objectives
*Explain your own view of learning objectives
*Develop an alternative approach to listing learning objectives in your next eLearning
I hate writing learning objectives. I see the value. I do. At least from the instructional designer's and the business's point of view. Learning objectives clarify exactly what it is you're trying to teach. But I find them painfully boring to read and to write.
Ray Sims has written a great summary on Writing Learning Objectives, with citations to some good resources, including Vicki Heath's post Learning Objectives: Writing Learning Outcomes So They Matter.Vicki states as the first benefit of learning objectives: "Learners can focus more easily on what is important to their actual workplace performance."Her statement is in keeping with traditional instructional design theory that says that learning objectives help learners organize their learning efforts. And yet one could argue that most learners don't even bother reading them.As Michael Allen says in Michael Allen's Guide to e-Learning: "Learners think, 'I'm supposed to do my best to learn whatever is here, so I might as well spend all my time learning it rather than reading about learning it." The objectives page is one that I always click NEXT to slide right on by.How about you? If you have ever taken an eLearning course (and be honest -- have you really taken an eLearning course?), have you taken the time to read those objectives? Really?
Write Better Objectives
One approach, as Cathy Moore demonstrates so well, is to write better objectives. See her recent post: Makeover: Turn Objectives into Motivators.Michael Allen thinks better-written objectives are a start, but wonders if any form of the "textual listing of objectives [is] really the best way to sell anyone on learning.
"Break the Rules"
Allen urges instructional designers to break the rules: "Don't list objectives."Pretty radical, isn't it? I called this one out as one of the top things I learned about learning in 2007.Instead, provide some meaningful and memorable experiences using interactivity, graphics, animation, and storytelling.
Alternatives to Listing Objectives
Here are some of Michael Allen's alternatives to listing out boring learning objectives ...
Put the Learner to work
Have the learner attempt a task. If they fail, they'll know what they are going to be able to do when they finish your program (hopefully, complete the task).
Create a scenario showing the risk of what could happen if the learner doesn't learn the content -- and the benefits that will happen when she does
Create a Game quiz
Instead of a traditional, boring assessment, create a game-like quiz. Based on their performance, learners will see if they are beginners or advanced, and where their gaps in knowledge might lie. And they'll be able to see what kinds of tasks they should be able to do at the end of the course.
Check out Karl Kapp's Gadgets, Games and Gizmos for Learning for some simple game ideas.
Thank you folks...!!!
Tuesday, July 8, 2008
- Learnability/Familiarity: for example, reduce short term memory load, ensure ease of understanding and guessability, make operations visible, use appropriate metaphors.
- Ergonomics/Human Factors: for exemple, allow for flexible input (like menus, shortcuts, panels), multiple communication, design for user growth
- Consistency/Standards: for example, likeness in behavior, consistent and clear user interface elements
- Feedback/Robustness: give appropriate quantity of response, offer informative feedback, let the user recover from errors or dead-ends, insure stability, task completeness and adequacy, respond in time.
- Visibility - knowing the stat of an object and the choices available
- Feedback - timely, in an appropriate mode (aural, visual, etc.), yet not distracting from task
- Affordance - use object whose actual properties are in accordance with its perceived properties (e.g. an icon depicting a switch should turn something on or off)
- Mapping - make use of the relationship between objects and their environment (e.g. placing a menu bar at the top of an application window)
- Constraints - limit the possible interactions physically, semantically (context-related meaning), logically, or culturally (learned conventions)
- Habituation - the use of the system should become internalized to the point that the user only thinks of the task, not the system
HCI design approaches
- Top-down or hierarchical problem solving - working from the functional level to the specific working out issues problems that arise
- Design by reuse - use of previous designs that are based on similar situations
- Design problem evolution - recognition and relaxation of assumptions thus engaging in a redefinition of the problem in cycles that involve planning, translating and revising in order to optimize a system so that it can satisfy diverging and contradictory requirements
- Design by deliberative recognition-priming - use of previous conceptual knowledge and experience to recognize useful patterns to by-pass hierarchical processes
- Design by serendipitous recognition-priming - ideas that arise from opportunistic comparisons and analogies not necessarily directly related to the design problem.
- Design by collaboration and confrontation - team-based design based on collaboration and confrontation activities.
Tom Erickson (1995) outlines some ways in which storytelling can be used as a tool for designing human-computer interactions. Stories reveal users' experiences, desires, fears and practices that can in turn drive effective user-centered design. He points out that stories, in contrast to scenarios, involve real people in particular situations and consequently involve unique histories, motivations and personalities.
- story gathering - gathering users' stories on the users' domain (a culturally, socially and physically situated environment) thereby collecting and building a shared language, referents and questions and issues to be addressed.
- story making - building 'scenario-like' stories that capture emerging common concepts and details from users' stories
- involving users - using stories with users to elicit dialog and discussions that bring essential ideas and problems to light that should be considered in the design.
- transferring design knowledge - being highly memorable and still susceptible to the uncertainty entailed in the particular being applied to the whole, “ stories become important as mechanisms for communicating with the organization by upport design transfer”, by “ capturing both action and motivation, both the what and the why of the design” (Erickson, 1995)
Personas in interaction design
Design of an interaction sets the conditions in which a conversation between a user and a system will take place. The system needs to speak and respond to the user. To envision more effectively how such a conversation may proceed, interaction designers determine user personas. Personas are defined models of intended and potential user types. These models can be defined through ethnographic research practices such as observation, interviews or direct user-testing with sample target users. Personas are widely used in user-centered design approaches.