https://arstechnica.com/information-technology/2017/07/with-html5-webgl-javascript-ascendant-adobe-to-cease-flash-dev-at-end-of-2020/


As FLASH reaches its end, it is not dying a graceful death as far as courseware support is concerned. It's somewhere between Nightmare on Elm Street and some creepy Clown movie.  


MaxIT has a reached a place with FLASH-based content where we cannot provide the same level of services or support we do with HTML5 based content. This is because FLASH has constant announcements of security flaws, incompatibilities when run on a trusted intranet, and an unknown number of dependencies based on the security patch of the browser and version of the FLASH player. It's horrible. It's scary and we now define clearly what we will and wlll not support with FLASH-based content. 


Let me offer a example. A large client with multiple business locations had two problem locations where the FLASH-based content would not track in AbilityLMS. For the rest of the locations, FLASH worked at essentially zero errors. The course vendor said it was an LMS problem because it worked fine in SCORM Cloud and their LMS, the internal network resources said their network was fine. Faced with the LMS getting a bad reputation, MaxIT resources were drawn into the problem as to why the course was not tracking. After dozens of emails and several hours of web collaboration to the workstation of a problem user, we were able to make the course post properly under an obscure configuration. This incident had to do with FLASH on IE9 or Edge missing a service patch needed for supporting web proxy services on a trusted network. The problem manifested in FLASH but not in HTML5. Ugh!


It was never an LMS problem, but the client was facing a serious problem because the training is compliance related. Unfortunately, this was such a rabbit hole of time for the client and MaxIT, it created a lot of other hardships. The rabbit hole is filled if we just move away from FLASH entirely. 


While we say this in many of our support documents and in direct communication, it bears repeating that when you launch into AICC / SCORM / XAPI learning content, you leave AbilityLMS and you enter an application with its own design patterns and behaviors. When the content launches, the LMS passes parameters the content needs to speak to the LMS. Once launched the content has responsibility to ask for data and send data to the LMS. As AbilityLMS processes requests, we log the request to a text file for the user + course + enrollment record BEFORE the LMS ever touches the data. Whatever data shows in the logs represents the entirety of what the LMS received in the request by the course. If there is not data in the log to show complete or pass, the LMS will never show same. Unfortunately, there are times when the user experience may show Finished in the content, but because the content does not post back tracking to the LMS. we get into rabbit holes of time and the great majority of the time when it happens it is from FLASH-based content. Often times, the course just freezes or you answer a question right and you still see it record as wrong. 


For the great majority of FLASH-based users, FLASH works fine, but if you have the problem you typically will get good results the first time through, then the FLASH content is cached. If the user did not complete the lesson properly the first time, the FLASH-based content continues to report the original score. 


Problem solving is not easy. We will list a few things you can do to profile the problem. 


Clear the browser history, the browser application storage (cookies and the local database) and the flash cache (https://forums.adobe.com/thread/977699), close and restart your browser. 


The user of Fiddler may also trick the local browser to post properly. This is because Fiddler is a proxy server and this can trick other proxy servers to behave and not use cached data. https://abilitylms.freshdesk.com/support/solutions/articles/33000097122-using-fiddler-to-help-solve-courseware-problems


Another tick will be to slightly change the launch url for the course in the LMS and mirror the change on the web server where the course is stored. If the launch url is https://yourcompany.learnerhall.com/training/cbt100/start.htm and you edit the url both in the LMS (course module record) and on the web server (you need FTP access to do this)  to something like 

https://yourcompany.learnerhall.com/training/cbt100v2/start.htm this will force the user to get a new version of the course to their browser.  


None of these options will fix the problem, but it will help profile the problem. 


Moving forward, MaxIT is going to be a stickler to limit courseware support with FLASH-based courses in particular and course problems in general to what is in the log file. As we provide support for what is in the log file, you will be trained in how to read the log files. Most course vendors can put a course into a debug mode. Since the course has responsibility to post to the LMS or Scorm API, you will need to engage them to demonstrate the course is posting well formed data. It does not count if they use a 3rd party vendor like SCORM Cloud or their LMS. That "test" does not reflect the user experience connecting to the network and technology in play to accelerate the user experience and/or monitor user activity in how they use trusted applications. Our log is authoritative as it shows what the content posted or in absence of data the lack of expected data the content should have posted. 


The heart of the matter is FLASH is a dead technology. In 2020 you must be off FLASH as that is now non-negotiable by the makers of FLASH. If you have compliance requirements and the content is FLASH-based, you really need to accelerate getting of FLASH and to HTML5 as a priority. HTML5 works better, performs better and is easier to support. If you need help, we have consultants who can assist in refactoring courses to HTML5. 


FLASH RIP.