An eLearning player is a building block for more conventional [one with back and next for navigation buttons] eLearning courses. What’s an eLearning player? It’s a simple wrapper having global level functionalities like –
- Core logic for navigation features like next, back, menu etc.
- Communication logic to talk to the LMS (standards complaint)
- Global level functionalities like Notepad, add favorites, appendix, etc.
This post is based on our experience with development of Flash based eLearning players over the years. The considerations mentioned here would, however be applicable to any other (development technologies) eLearning player too. Here are some of the key considerations for developing an eLearning Player –
- Define end user system requirements – list the end user minimum system requirements. These requirements should include the recommended hardware and software needed in the user’s machine to run the eLearning player. Make sure these specifications do not use phrases “and above“, “or higher” [for ex. Windows XP or above] for operating systems, software or plug-in versions. The trouble is newer releases of OS or software may not have the full backward compatibility causing your eLearning player to stop functioning properly. It’s best to mention the minimum and maximum version of targeted OS, software or plug-ins and plan your testing as per the specifications. It is even better if all the targeted OS, software and plug-ins are explicitly mentioned. A good practice is to include a compatibility check screen in the course itself to test if the learner machine fulfills the requirements to run eLearning player.
- Get dimensions of player & content area right – based on the targeted systems resolutions define the dimensions of player and the content pages. We develop most of our courses for the systems with resolution 1024*768 as it is the most widely used resolution. Of course don’t forget to specify the targeted resolution in the recommended end users system requirements document.
- Modularize features – try to keep the global level functionalities modular and independent of each other so that adding or removing the features is easier.
- Think various delivery modes – the eLearning player should be easily portable to multiple delivery modes [like offline EXE, online without LMS, online with LMS]. It’s a good practice to keep a variable in an external text file form where you directly set various delivery modes directly without getting into the code every time to do the required updates.
- Simplify content updates – place the sequence of content pages, textual content and path of other media assets in external text or XML files especially for Flash/ SilverLight based courses instead of just placing them in the source file. This makes the content more manageable and easy to update. This is immensely helpful when you create multilingual courses.
- Test on actual environment – environment is the combination of hosting server and end user’s machine. While developing the player it’s important to test it in the actual environment with dummy assets and content. Make sure to include the all file types [like *.swf, *.flv, *.js, *.html, *.xml, *.mp3 etc.] that you foresee to be in the final deliverable. You do need to include all file types as some servers don’t allow the request for all media types by default and this has to be configured manually. For ex. *.flv [Flash video format] is not supported in some servers by default and it needs to be configured.
- Check LMS compliance – the player should also be tested on targeted LMS compliance standards. Though SCORM and AICC are standards but different LMS interpret some of the commands/APIs in a different manner so it’s advisable to check this in advance. While implementing compliance standards you could ask for the implementation guide for the LMS and course interaction to understand if the LMS follows standard SCORM or AICC features or it’s a customized one and update the player accordingly.
- Ensure LMS communication – in the player there should be some continuous checks to find out if the course is connected to the LMS or if there’s an error while updating data. In case of any errors or if the connection is lost the player should prompt appropriate message and exit.
- Make navigation easy to understand– the course navigation should be easy to understand and proper tooltips and instructions should be provided on the GUI. A detailed help page should be included explaining the function of each player element.
- Ensure documentation and code commenting – these are probably the two most important things which are often ignored by the developers. Each function and variable should have proper documentation and comments. This will help other developers to understand the code easily and maintain in future.
- Check for player constraints – while developing a player it’s good to know and list the constraints of the player. A few possible constraints for a Flash [AS 2.0] based eLearning player are –
- No support for AS 3.0 based pages
- No support for loading videos in case if the template library doesn’t have a video based template
- Not tested in Opera 7.0
There may be many more constraints like this and you may want to share these constraints with your client.
Hope you find these tips useful. Do share any more tips you may have on this.