E-Learning Council

In this white paper, E-Learning Council speaker Linda Warren and Mike Hruska discuss the significance of the Experience API also known as xAPI and “Tin Can”. The jump from SCORM to xAPI is a big one and learning managers and designers need to be aware of the limitations of SCORM and how xAPI is designed to address them.

The paper helps you gain basic knowledge of terms and an understanding of the standards that provide the foundation for SCORM and xAPI (such as “TinCan“), and then discusses the how xAPi addresses some of the key limitations of SCORM in areas including:

• Security
• Use outside the LMS
• Use outside the browser
• Offline support
• Web and native app tracking
• Tracking virtual worlds and simulations
• Tracking informal learning
• Tracking group performance

Download Tracking and Reporting Standards for Training: SCORM and xAPI

By Adib Masumian

Erik Soell joined the Federal Reserve Bank of St. Louis in 2001, where he leads the Fed’s Rapid Communications team, which manages Rapid Response, Ask the Fed, and other similar programs.

Erik began his talk by outlining four key functions of the Federal Reserve:

• Influencing the supply of money and credit
• Responding to financial panics
• Regulating financial institutions
• Serving as a banking and fiscal agent for the U.S. government

After explaining the purpose of the Fed, Erik outlined the causes of the subprime mortgage crisis of 2008, chief among them the bust in the housing market. In addition, he pointed out that large investment banks were at the epicenter of this debacle because of their role in creating securities from mortgages.

The ensuing decline was “fast and extended,” in Erik’s words, and the situation called for quick action. Along with the Federal Deposit Insurance Corporation (FDIC) and the US Government, the Fed was one of the first responders to the crisis. To mitigate the damage dealt by the crisis, the Fed eased the country’s monetary policy and provided funds to stabilize financial markets both domestically and internationally. These measures—a joint effort between the Fed, the Treasury, and the FDIC—ultimately prevented the collapse of the United States’ financial system.

The Rapid Response program was born in August 2008 out of the aftermath of the aforementioned crisis. That turbulent time was marked by quick, frequent, and sometimes unpredictable change. In these changes, the Federal Reserve saw the need to provide bank examiners with detailed and pertinent “just in time” information on emerging financial issues—such as regulations, supervisory letters, and administrative directives that come from the board—so that they could be better equipped to address handle future fiscal turmoil.

In the past, the nature of the Rapid Response program was kept low-tech to maximize ease of access; it consisted of a teleconference call with a PowerPoint presentation. Prior to the session, registrants received a copy of the PowerPoint presentation through e-mail delivery, along with a toll-free teleconference number. At the scheduled time, attendees joined by desk phone, conference phone, or mobile phone from wherever they happened to be working. Most calls lasted an hour and were moderated by a member of the Rapid Response production team – just in case unanticipated problems arose. The moderator also assisted with the Q&A portion of the session and wrapped the call up at the end. During the presentation, the presenter typically spent 30–40 minutes on his or her presentation, allowing time for questions throughout. While the general format of these Rapid Response sessions remains still very much the same, they have now evolved to also include a webinar format.

Erik gave an example of how one such Rapid Response session played out. In July 2009, the state of California did not pass a budget. Aware of the implications that this action would have—such as costing the state millions in interest, potentially hurting its bond rating, and rendering it unable to pay its residents and businesses on time—The Fed decided that they needed to deliver information to bank examiners quickly. The Rapid Response team worked with the senior person at the board, who was highly privy to the budget situation, and asked her to host a Rapid Response session. In a week’s time, they were able to put together content and hold the session, which nearly 250 people attended. Participants learned about things like registered warrants (IOUs) and what they mean if they live in California; whether the warrants apply to businesses, vendors, or tax refunds; and the steps that a bank should take when they receive a note stating, “I owe you X amount of money, but I’m not going to pay you until October.” Apart from the material given by the presenter, the attendees themselves also shared their own experiences, which helped to foster the session’s collaborative environment.

The audience for Rapid Response was initially restricted to Federal Reserve examiners, but was eventually expanded to include state examiners. Since its inception nearly six years ago, the Rapid Response program has enjoyed continued success. By their estimate, the Fed will hold their 500th Rapid Response session sometime in August 2014.

Erik closed his presentation by sharing the “secret sauce” of Rapid Response—in other words, the decisions, approaches, and philosophies that have propelled the program to success:

• Aim for 80% right. To aim for a perfect 100% is unreasonable; you won’t achieve it—no one ever has—and you’ll only end up stressing yourself and straining your resources in the process. Set feasible goals and success will follow.
• You’re always in beta. Have you ever noticed how, after all these years, the team at Google still advertises Gmail, Google Chrome, and other popular products as being in “beta” stage? This is because they know that, just as they are continuing to grow as a company, their products are constantly evolving alongside it.
• Admit to people that the product isn’t perfect. There is no such thing as a bug-free service. Admit first to yourself and then to other people that your product will be flawed, but also that product development is a learning process which demands that new information be incorporated along the way.
• Create a concept paper. Fleshing your ideas out on paper always helps. You need to have a clearly defined conceptual basis for your idea before building its infrastructure. You should establish what the purpose of your idea is, who will need to be involved in it, what it will take to make it a reality, and methods for gauging its success long before you set out to bring it to fruition.
• Start small. Diving into a fresh venture can often lead to biting off more than you can chew.
• Brand it. A sleek logo isn’t just for show—it’s also a powerful marketing tool. Your brand can get extensive circulation on just about anything from thank you notes to coffee mugs.
• Effective phone management. Rapid Response presenters speak through a host line while attendees are put on a participant line, which is muted by default. Employing a two-line phone system makes it easy to facilitate Q&A sessions, as well as the general flow of conversation.
• Governance. The Rapid Response team has a small group of people that reviews every response before it goes out. This level of governance is ideal for ensuring a consistent image for your organization.
• Revise your approach. Every so often, reevaluate your approach by checking it against current technologies or services. Are there more effective alternatives to the method your organization is using right now? Would switching be feasible, and would it make logistical sense to do so? Recall how Rapid Response started with simple phone calls and eventually shifted to webinars.
• Life favors the prepared. It’s okay to try something and fail, but don’t go into it blind. Do your due diligence, check and double-check the resources you have at your disposal, and make sure you have the right people on board before committing to your idea.

Please share your thoughts on this post with us in the comments section at the bottom.