Lately I have had a lot of conversations with clients discussing why our Learning and Creative Services team builds in native HTML for our Brightspace customers vs. using a Rapid Development Tool (RDT) like Articulate Storyline, Captivate, or Elucidat, and then upload a SCORM package.
Here are a few considerations if you are weighing your options between the two.
Please note: When referencing HTML, we are paraphrasing the role of a front-end web developer that would use HTML5 for text and images, CSS for styling, and JavaScript for dynamic page elements.
Quality
Consistency in our development using the most up to date web standards is critical. Common browsers are always updating features and security, and this can greatly affect how your content is presented (or not presenting!). Newer RDTs will output to HTML, but the quality of code is less efficient and clean compared to a competent web developer’s,
leaving possibilities for issues with different web browsers, security issues, and page loading times.
Ensure your content is responsive
and meets accessibility standards
Accessibility
Organizations that need to meet or exceed local web accessibility standards will want to consider building in HTML. While the new RDTs are getting better, there are still a lot of issues with endless tabbing on screen readers. Much of this has to do with how we build in these tools, so if you are using an RDT, be sure to design with Universal Design for Learning in mind, and test your final product using screen readers and other assistive technology.
Responsive Content
Many RDTs claim full HTML responsivity, ensuring content looks as good on your phone as it does on your laptop. Our reviews find that while RDTs are improving, many are still simply shrinking down the desktop experience, which can create frustrating navigation experiences, extremely small text and graphics. Proper responsive development through the use of HTML templates considers effective mobile arrangement of content, not simply shrinking down the screen size, or adding a horizontal scroll bar.
Team to Build
To build with dynamic elements in JavaScript, you will need a front-end web developer to add in content. This is not the case with RDTs, where an instructional designer can do both the design and development simultaneously in the tool, creating elements of interactivity with no programming knowledge required. In terms of ease of use, RDTs are designed for simplicity in mind, and for audiences that don’t have a web development background.
That said, our team has recently provided some great, easy HTML templates that your team members should try out before using RDTs. They are free, look amazing, and can be stylized to your organizational branding.
Flexibility
Most RDTs that need SCORM publishing are fixed windows of content that don't allow for responsive material. Your page size is fixed from the initial set up so you can’t get a lot of content on a page, especially those based in PowerPoint formats where the original intent was to simply bullet the words on the page. With HTML, we can take advantage of the full screen size in the content, use up to 5 columns for text and imagery, and there is no limit to page length. In short, you can reduce the “next, next, next” annoyance of navigation by keeping your thoughts organized on a single page.
Customizations
Another major consideration is the flexibility a development team can bring using HTML. Working with a multimedia team like ours provides an enormous range of custom solutions like financial calculators, personality surveys/questionnaires, and simulations for software, Virtual Reality, and Augmented Reality.
Maintenance
Maintenance can be somewhat of a pain with RDTs, as any small changes force you to reauthor in the RDT and then reimport a course package to Brightspace. Using our templates, you simply edit the HTML inline or upload one replacement file.
Translations
A recent call had me explaining that we use Word with translation teams. We develop our English version in HTML, and then copy the layouts based on the localized text that we receive in Word. RDTs like Elucidat can take an XLF file and move it back into the tool that will automatically update the language. This saves about 6 hours per translated course, which could significantly impact your decision if you have hundreds of courses in multiple languages.
Data
From a data gathering perspective, building individual HTML pages can provide insight into where your learners are in a module, and how much time they’re spending on each page. While time on page is not always the most effective data set, if you find a large percent of your learners are stopping their progress on a certain page, you may want to ask why.
When uploading a single SCORM object, you are only getting one data set, as the SCORM object is a single topic in the Content, so insights into how much value learners are finding in specific topics is lost, as well as where they are in the course, and where they are potentially getting hung up.
To Summarize
While RDTs can certainly simplify, and in some cases, speed up the process of building out course content, our team has found that the benefits don’t outweigh the flexibility, and ultimately the end user experience to have a fully responsive and accessible course. This comes back to the age-old consideration of quality vs time vs budget that we all have to make in the eLearning industry.