Dev Learn Handout - Session 604


Published on

The accompanying handout for session 604

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Dev Learn Handout - Session 604

  1. 1. Stop Building It From Scratch! How to Build a Reusable eLearning Framework Presented by: Chad Udell ( & Mark Tovey ( Overview: APIs are prevalent in RIA and web design and development, but are relatively unheard of in eLearning development. Using APIs has a quantifiable return on investment and is a standard way to build robust functionality in application development. How can we start to move towards this sort of development process in eLearning? Why This Is important: There are significant cost and time savings possible in standardizing around an API for use in your learning development organization. Shorter development cycles, improved quality and more reliable testing results will be immediately noticeable. Protection of intellectual property and improved risk management for your company are also areas that will see benefits in implementing an API. Things to Consider: Creating an API is a worthwhile activity, but one that requires planning and collaboration between the API developers and the API users. Once you create an API and deploy it, it’s difficult to come back and wipe the slate clean if you need to start over. An API is a contract between two mechanisms. An API should consist of concise, intuitively named methods, properties and events. Any codebase utilizing the API can then be written to a simple interface, able to ignore the implementation details of that interface. How You Can Get Started: The first steps in creating an API are completely analog! Take stock in what you have to develop repeatedly in your courses. Survey your developers and determine what are some of the more difficult things they have to create. Review your existing code library for the “greatest hits.” Research publicly available APIs and note what you like and don’t like about them. For further reading: How To Design a Good API and Why It Matters: Why-it-Matters Page 1
  2. 2. Worksheet How do you know you when an API is right for you? If five or more of these situations apply to you, you’ve probably outgrown using a code library. You should consider moving to an API. 1. Your development team is three or more people. 2. You have junior level developers that need to produce “senior level products.” 3. You have to ask questions like, “Where is the latest version of the LMS connection script?” more than once a month. 4. You have projects with external developers with whom you need to collaborate. 5. You want everyone on your team to use the company’s “Best Practices” in creating their code. 6. Your code will have a multi-project shelf life. Some modules will be reused many, many times. 7. Your investment in your intellectual property is worth the effort required to create an API the right way. 8. You are standardized on a toolset, and need to standardize on an implementation path. 9. You have been burned by quality issues that could have been remedied by a standardized approach. 10. You are looking for new ways to enhance productivity in your development team. 11. You are deploying your code as a software product (SaaS or otherwise). If the following situations apply to you, proceed with caution. 1. You work alone. 2. You don’t have a standard toolset. 3. Your technology decisions are often ruled by forces outside of your department. 4. Spending dozens or hundreds of hours to get your toolset in order is not an option. 5. You have no need for reusable code as assets across multiple projects. 6. Code as intellectual property is a foreign concept to your organization and you won’t be able to change that anytime soon. Page 2