Is your organization constantly going through the same development path to produce your e-Learning... rehashing the same code, digging through line after line of spaghetti, and not seeing any real reuse benefits? If you want to leverage your intellectual property, and put your toolset to work for you, come ready to take note of practical tools, tips, and techniques you can employ immediately to enjoy productivity benefits. In this session, you’ll learn secrets that Rapid Development gurus use. If you are tired of simple tools that speed up development, but really tie your hands when it comes to true customization, you need to learn more about application programming interfaces (APIs). The Web 2.0 world has largely been shaped by the emergence of Web services and the dominance of XML, yet so few e Learning development programs allow you to tap into those powerful tools. You’ll leave this session with ideas on how to build your own APIs, or use preexisting ones, right away. In this session, you will learn: * The benefits of building content in a reusable format * Practical examples of reusable e-Learning concepts * How to apply object-oriented development techniques to e-Learning * What APIs are, and how you can use them to speed up development * Techniques for designing your own e-Learning APIs * Designing data schemas for flexibility Audience: Advanced designers and developers with basic programming skills in ActionScript, and who have edited XML. Deeper understanding of XML concepts and terminology will assist in greater understanding of this topic.

1. Stop Building It From Scratch
Creating Reusable eLearning Components
presented by Chad Udell and Mark Tovey at DevLearn ’09
November 12th, 2009

2. Introduction

3. Introduction
• Who we are

4. Introduction
• Who we are
• Where do we work

5. Introduction
• Who we are
• Where do we work
• What do we do

6. Purpose

7. Purpose
• Who is this presentation best suited for?

8. Purpose
• Who is this presentation best suited for?
• What will you learn?

9. Purpose
• Who is this presentation best suited for?
• What will you learn?
• How can you implement it immediately?

10. A show of hands

11. A show of hands
• Who has rebuilt a feature more than
2-3 times?

12. A show of hands
• Who has rebuilt a feature more than
2-3 times?
• Who has a library of snippets they
refer to?

13. A show of hands
• Who has rebuilt a feature more than
2-3 times?
• Who has a library of snippets they
refer to?
• Who has used an API before?

14. A show of hands
• Who has rebuilt a feature more than
2-3 times?
• Who has a library of snippets they
refer to?
• Who has used an API before?
• Who has created their own API?

15. Some observations

16. Some observations

17. Some observations
• Everyone keeps a folder or two around on
their PC/Mac for their “best of” examples
and code reuse

18. Some observations
• Everyone keeps a folder or two around on
their PC/Mac for their “best of” examples
and code reuse
• APIs are used a lot in other areas, almost
never in eLearning (barring SCORM, of
course)

19. Some observations
• Everyone keeps a folder or two around on
their PC/Mac for their “best of” examples
and code reuse
• APIs are used a lot in other areas, almost
never in eLearning (barring SCORM, of
course)
• Version Control is used in other areas,
too, almost never in eLearning

20. Key Differences between APIs and Libraries

21. Key Differences between APIs and Libraries

22. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

23. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

24. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

25. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

26. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

27. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

28. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

29. Key Differences between APIs and Libraries
• APIs are by definition, basically
• A code “library” is always in flux.
stable.
• Libraries may vary from developer • With an API, everyone shares the
to developer same base
• Libraries may have collisions • APIs are designed from a holistic
between snippets view
• Documentation? ha! • Documentation is key!

30. The problem with libraries.

31. The problem with libraries.
• It’s impossible to establish coding
conventions

32. The problem with libraries.
• It’s impossible to establish coding
conventions
• Copy and Paste syndrome

33. The problem with libraries.
• It’s impossible to establish coding
conventions
• Copy and Paste syndrome
• Single source saves time

34. The problem with libraries.
• It’s impossible to establish coding
conventions
• Copy and Paste syndrome
• Single source saves time
• Bugs recur

35. The problem with libraries.
• It’s impossible to establish coding
conventions
• Copy and Paste syndrome
• Single source saves time
• Bugs recur
• Teamwork is tough

36. What advantages does an API provide?

37. What advantages does an API provide?

38. What advantages does an API provide?
• Common, share-able code base (methods,
properties, events)

39. What advantages does an API provide?
• Common, share-able code base (methods,
properties, events)
• Extend as you need

40. What advantages does an API provide?
• Common, share-able code base (methods,
properties, events)
• Extend as you need
• Proven effectiveness/Productivity

41. What advantages does an API provide?
• Common, share-able code base (methods,
properties, events)
• Extend as you need
• Proven effectiveness/Productivity
• Company Risk Management & Intellectual
Property Protection

42. We need something better: Version Control

43. We need something better: Version Control
• Revision History and Committing
to a safe source.

44. We need something better: Version Control
• Revision History and Committing
to a safe source.
• Needed for quality

45. We need something better: Version Control
• Revision History and Committing
to a safe source.
• Needed for quality
• Needed to help transition from a
library to an API

46. What does version control provide?

47. What does version control provide?

48. What does version control provide?
SVN=!OMG.

49. What does version control provide?
• Risk Management
SVN=!OMG.

50. What does version control provide?
• Risk Management
• Forks
SVN=!OMG.

51. What does version control provide?
• Risk Management
• Forks
• Team Collaboration
SVN=!OMG.

52. What does version control provide?
• Risk Management
• Forks
• Team Collaboration
• Ease of deployment SVN=!OMG.

53. How can I get started?

54. How can I get started?

55. How can I get started?
• Make a list of common things you and your users routinely do.
• LMS Connections
• Bookmarking
• Scenarios
• Quizzes
• L10N

56. Now what?

57. Now what?

58. Now what?
• Make a list of things you have done in the past that were painful
• Getting content into/out of your LCMS
• Sharing media pieces through the course
• Integrating non-standard media
• Exporting for multiple formats
• Non-Linear/Non-Standard Navigation

59. Survey the landscape... What’s Flickr doing?

60. Survey the landscape... What’s Flickr doing?
• Or Twitter for that matter?

61. Survey the landscape... What’s Flickr doing?
• Or Twitter for that matter?
• Take a quick look at some developer sites like programmableweb.com
to see APIs you may want to emulate.

62. Survey the landscape... What’s Flickr doing?
• Or Twitter for that matter?
• Take a quick look at some developer sites like programmableweb.com
to see APIs you may want to emulate.

63. Key Tenets

64. Key Tenets
• There are a number of overarching
principles you should adhere to.
• This isn’t meant to be dogmatic or
inflexible, but merely a path to success

65. The Basics

66. The Basics
• Keep your users in mind!

67. The Basics
• Keep your users in mind!
• Once you deploy it, it’s tough to change it.

68. The Basics
• Keep your users in mind!
• Once you deploy it, it’s tough to change it.
• It can’t have everything in it!

69. The Basics
• Keep your users in mind!
• Once you deploy it, it’s tough to change it.
• It can’t have everything in it!
• It should be easy to learn, hard to abandon.

70. The Basics
• Keep your users in mind!
• Once you deploy it, it’s tough to change it.
• It can’t have everything in it!
• It should be easy to learn, hard to abandon.
• People should see value in it immediately.

71. Some Rules of Thumb
• Keep it small
• Methods, Properties and Events
• Can’t have a decent API with out all 3
• Don’t use abbreviations for functions or
variables
• It should be apparent what is going on
without reading the docs.

72. Samples: Some Rules of Thumb
• Example of Getter/Setter
• Code sample with abbreviation vs. code without.

73. Key Concept: Predictability
• Users shouldn’t be surprised by return
values.
• Users should be able to chain methods
• Users should be able to call/access all
methods/events at all times.

74. Samples: Predictability
• Code Sample - Non Surprising return value
• Code Sample - Chaining methods
• Code sample - flexible calling/returning

75. Key Concept: Supporting Ease of
Development
• A broader acceptance brings success
• Uniform data input/output is easier
• Arrays vs. Vectors – Using 0 vs. null
• Provide meaningful errors
• Compile time errors are better than runtime

76. Samples: Ease of Development
• Code Sample on input/output
• Code Sample on Compile time error vs Runtime error

77. That’s a lot... how do I do this?
• It’s probably not practical on your own.
• Focus on the end goal
• Start with a solid code base... OOP helps.
• The best tool to start with: A notepad.

78. On your own
• Re-familiarize yourself with your library.
• Catalog the best examples.
• Throw the rest out.

79. During Development: Agility

80. During Development: Agility

81. During Development: Agility
• Start small, build the best you can!

82. During Development: Agility
• Start small, build the best you can!
• Have a core set of methods you
can chain to do something great,
then grow.

83. During Development: Agility
• Start small, build the best you can!
• Have a core set of methods you
can chain to do something great,
then grow.
• Don’t throw in the kitchen sink!

84. During Development: Starting Simple

85. During Development: Starting Simple
Core

86. During Development: Starting Simple
•Core
•Should be focused on your key pain
point(s)
•Should have a clear ROI in mind
Core

87. During Development: Starting Simple
•Core
•Should be focused on your key pain
point(s)
•Should have a clear ROI in mind
Data Core

88. During Development: Starting Simple
•Core
•Should be focused on your key pain
point(s)
•Should have a clear ROI in mind
•Data
•Integrate with a CMS/XML/
etc.
•Work with translators, etc Data Core

89. During Development: Starting Simple
•Core
•Should be focused on your key pain
point(s)
•Should have a clear ROI in mind
•Data
•Integrate with a CMS/XML/
etc.
•Work with translators, etc Data Core Behavior

90. During Development: Starting Simple
•Core
•Should be focused on your key pain
point(s)
•Should have a clear ROI in mind
•Data
•Integrate with a CMS/XML/
etc.
•Work with translators, etc Data Core Behavior
•Behavior
•Ease Development in a larger team
•Expand rich media use/capabilties

91. Post development: Deploying

92. Post development: Deploying
• Don’t circulate beyond friends
until it’s ready

93. Post development: Deploying
• Don’t circulate beyond friends
until it’s ready
• Compilation, Obfuscation and
Minifying

94. Post development: Deploying
• Don’t circulate beyond friends
until it’s ready
• Compilation, Obfuscation and
Minifying
• Hosting the API (Amazon,
Sourceforge, etc)

95. Post development: Deploying
• Don’t circulate beyond friends
until it’s ready
• Compilation, Obfuscation and
Minifying
• Hosting the API (Amazon,
Sourceforge, etc)

96. Post development: Deploying
Robot Picture

97. Post development: Deploying
• Building Installers, SWC, MXP, etc.
Robot Picture

98. Post development: Deploying
• Building Installers, SWC, MXP, etc.
• http://blog.flashgen.com/
components/distribution/ Robot Picture
distribution-via-mxp/

99. Post development: Deploying
• Building Installers, SWC, MXP, etc.
• http://blog.flashgen.com/
components/distribution/ Robot Picture
distribution-via-mxp/
• Creating Docs (ASDocs, JSDocs,
JavaDocs)

100. Post development: Deploying
• Building Installers, SWC, MXP, etc.
• http://blog.flashgen.com/
components/distribution/ Robot Picture
distribution-via-mxp/
• Creating Docs (ASDocs, JSDocs,
JavaDocs)
• Automating Builds

101. Post development: Deploying
• Building Installers, SWC, MXP, etc.
• http://blog.flashgen.com/
components/distribution/ Robot Picture
distribution-via-mxp/
• Creating Docs (ASDocs, JSDocs,
JavaDocs)
• Automating Builds

104. • Building an API is tough work, but VERY
rewarding

105. • Building an API is tough work, but VERY
rewarding
• For more information check out the sites
listed in the handout, downloadable at
the DevLearn Site.

106. • Building an API is tough work, but VERY
rewarding
• For more information check out the sites
listed in the handout, downloadable at
the DevLearn Site.
• Contact us: chadu@ionagroup.com,
mtovey@ionagroup.com