De laatste tijd heb ik veel gesprekken gevoerd met klanten over waarom ons Learning and Creative Services-team native HTML bouwt voor onze Brightspace-klanten in plaats van een Rapid Development Tool (RDT) zoals Articulate Storyline, Captivate of Elucidat, en vervolgens een SCORM-pakket uploadt.
Hier zijn een paar overwegingen als u uw opties tussen de twee afweegt.
Let op: Wanneer we naar HTML verwijzen, parafraseren we de rol van een front-end webontwikkelaar die HTML5 zou gebruiken voor tekst en afbeeldingen, CSS voor styling en JavaScript voor Dynamische pagina-elementen.
Kwaliteit
Consistentie in onze ontwikkeling met behulp van de meest up-to-date webstandaarden is van cruciaal belang. Veelgebruikte browsers zijn altijd bezig met het bijwerken van functies en beveiliging, en dit kan een grote invloed hebben op hoe uw inhoud wordt gepresenteerd (of niet wordt gepresenteerd!). Nieuwere RDT's zullen naar HTML worden uitgevoerd, maar de kwaliteit van de code is minder efficiënt en schoon in vergelijking met die van een competente webontwikkelaar,
waardoor er mogelijkheden zijn voor problemen met verschillende webbrowsers, beveiligingsproblemen en laadtijden van pagina's.
Zorg ervoor dat uw inhoud responsief is
en voldoet aan de toegankelijkheidsnormen
Toegankelijkheid
Organisaties die aan de lokale normen voor webtoegankelijkheid moeten voldoen of deze moeten overtreffen, zullen overwegen om in HTML te bouwen. Hoewel de nieuwe RDT's steeds beter worden, zijn er nog steeds veel problemen met eindeloos tabben op schermlezers. Veel hiervan heeft te maken met de manier waarop we deze tools inbouwen, dus als u een RDT gebruikt, zorg er dan voor dat u ontwerpt met Universal Design for Learning in gedachten en test uw eindproduct met behulp van schermlezers en andere ondersteunende technologie.
Responsieve inhoud
Veel RDT's claimen volledige HTML-responsiviteit, zodat de inhoud er net zo goed uitziet op uw telefoon als op uw laptop. Uit onze beoordelingen blijkt dat hoewel RDT's verbeteren, velen de desktopervaring nog steeds gewoon verkleinen, wat kan leiden tot frustrerende navigatie-ervaringen, extreem kleine tekst en afbeeldingen. Een goede responsieve ontwikkeling door het gebruik van HTML-sjablonen houdt rekening met een effectieve mobiele rangschikking van inhoud, niet alleen het verkleinen van de schermgrootte of het toevoegen van een horizontale schuifbalk.
Team om op te bouwen
Om met dynamische elementen in JavaScript te bouwen, heb je een front-end webontwikkelaar nodig om inhoud toe te voegen. Dit is niet het geval met RDT's, waar een instructional designer zowel het ontwerp als de ontwikkeling tegelijkertijd in de tool kan doen, waardoor elementen van interactiviteit worden gecreëerd zonder dat programmeerkennis vereist is. In termen van gebruiksgemak zijn RDT's ontworpen voor eenvoud in het achterhoofd en voor doelgroepen die geen achtergrond in webontwikkeling hebben.
Dat gezegd hebbende, heeft ons team onlangs een aantal geweldige, eenvoudige HTML-sjablonen die uw teamleden moeten uitproberen voordat ze RDT's gebruiken. Ze zijn gratis, zien er geweldig uit en kunnen worden gestileerd naar de huisstijl van uw organisatie.
Flexibiliteit
De meeste RDT's die SCORM-publicatie nodig hebben, zijn vaste vensters met inhoud die geen responsief materiaal toestaan. Uw paginagrootte staat vast vanaf de eerste installatie, dus u kunt niet veel inhoud op een pagina krijgen, vooral niet die op basis van PowerPoint-indelingen waarbij de oorspronkelijke bedoeling was om de woorden op de pagina gewoon op te sommen. Met HTML kunnen we profiteren van de volledige schermgrootte in de inhoud, maximaal 5 kolommen gebruiken voor tekst en afbeeldingen, en er is geen limiet aan de paginalengte. Kortom, u kunt de "volgende, volgende, volgende" ergernis van navigatie verminderen door uw gedachten op één pagina te ordenen.
Aanpassingen
Een andere belangrijke overweging is de flexibiliteit die een ontwikkelingsteam kan bieden bij het gebruik van HTML. Werken met een multimediateam als het onze biedt een enorm scala aan maatwerkoplossingen zoals financiële rekenmachines, persoonlijkheidsonderzoeken/vragenlijsten en simulaties voor software, Virtual Reality en Augmented Reality.
Onderhoud
Onderhoud kan een beetje lastig zijn met RDT's, omdat kleine wijzigingen je dwingen om opnieuw te schrijven in de RDT en vervolgens een cursuspakket opnieuw te importeren naar Brightspace. Met behulp van onze sjablonen kunt u eenvoudig de HTML inline bewerken of een vervangend bestand uploaden.
Translations
Tijdens een recent telefoontje legde ik uit dat we Word gebruiken met vertaalteams. We ontwikkelen onze Engelse versie in HTML en kopiëren vervolgens de lay-outs op basis van de gelokaliseerde tekst die we in Word ontvangen. RDT's zoals Elucidat kunnen een XLF-bestand nemen en het terugplaatsen in de tool die de taal automatisch bijwerkt. Dit bespaart ongeveer 6 uur per vertaalde cursus, wat een aanzienlijke invloed kan hebben op uw beslissing als u honderden cursussen in meerdere talen heeft.
Gegevens
Vanuit het oogpunt van gegevensverzameling kan het bouwen van afzonderlijke HTML-pagina's inzicht geven in waar uw leerlingen zich in een module bevinden en hoeveel tijd ze op elke pagina doorbrengen. Hoewel de tijd op de pagina niet altijd de meest effectieve dataset is, Als je merkt dat een groot percentage van je deelnemers hun voortgang op een bepaalde pagina stopt, Misschien wil je vragen waarom.
Wanneer u een enkel SCORM-object uploadt, krijgt u slechts één gegevensset, aangezien het SCORM-object een enkel onderwerp in de inhoud is, dus inzicht in hoeveel waarde studenten vinden in specifieke onderwerpen gaat verloren, evenals waar ze zich in de cursus bevinden en waar ze mogelijk vastlopen.
Samenvatten
Hoewel RDT's het proces van het uitbouwen van cursusinhoud zeker kunnen vereenvoudigen en in sommige gevallen kunnen versnellen, heeft ons team ontdekt dat de voordelen niet opwegen tegen de flexibiliteit en uiteindelijk de eindgebruikerservaring om een volledig responsieve en toegankelijke cursus te hebben. Dit komt terug op de eeuwenoude afweging van kwaliteit versus tijd versus budget die we allemaal moeten maken in de eLearning-industrie.