Stop Building It From Scratch: Creating Reusable eLearning Components

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Stop Building It From Scratch: Creating Reusable eLearning Components - Presentation Transcript

    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
    102. • Building an API is tough work, but VERY rewarding
    103. • 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.
    104. • 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
    SlideShare Zeitgeist 2009

    + Chad UdellChad Udell Nominate

    custom

    411 views, 0 favs, 4 embeds more stats

    Is your organization constantly going through the s more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 411
      • 317 on SlideShare
      • 94 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 10
    Most viewed embeds
    • 89 views on http://visualrinse.com
    • 3 views on http://ionagroup.com
    • 1 views on resource://brief-content
    • 1 views on http://www.hanrss.com

    more

    All embeds
    • 89 views on http://visualrinse.com
    • 3 views on http://ionagroup.com
    • 1 views on resource://brief-content
    • 1 views on http://www.hanrss.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories