In my role as an instructional designer/ Learning Content Developer, a big part of the job is taking instructional materials that my subject matter experts (SMEs) have already created and transforming them into something that’s more attractive, instructionally effective, and optimized for online learning than simply sharing PDFs. In other words, my job is to take their ideas from the form they were born in and redesign them into the most effective online learning experience they can be.
This often involves taking learning content out of its original container (Word docs, PowerPoints, PDFs, audio and video recordings) and rebuilding it in a form that’s more conducive to the learning process — graphics, animations, video, audio narration, or pages in our HTML5 elearning authoring tool Adapt Learning. Adapt lets me pull all these diverse content types into a functional, beautiful, interactive course experience that works great in any browser, on any device, desktop or mobile.
Keeping your content clean
Since our finished product is essentially just an HTML website, it makes sense for as much of the content development process to take place in web-friendly formats from the start. This way, the content doesn’t get trapped in proprietary formats where it can’t be cleanly exported for publishing. For example, the way that Word adds extra formatting to your documents that can screw up the way it displays on the web, or how difficult it is to export speaker notes from PowerPoint, especially on Mac.
For this reason, I have a strong preference for open source writing tools that respect your freedom to import and export content in the ways that you see fit, rather than trying to get in your way.
A Web-Native Content Development Workflow
For my most recent course design project, I asked the subject matter experts if they’d be willing to use a wiki site as the first place where the content is developed. This way of working conferred a bunch of advantages on our creative process from the start:
- All of the content is saved as plain HTML text from the beginning, with no extra weird visual formatting code to strip out before adding the content to other platforms.
- All changes to the document are clearly tracked in the page history, so we can easily track which changes were made with each save. This lets us see what changed, who changed it and when, so we could make sure all updates to the wiki were also made in Adapt. Also, the wiki’s version history lets us view previous versions of the content and roll back changes if necessary.
- The Confluence wiki we used allowed stakeholders to easily copy/paste images and files into the wiki, removing some of the fidgetiness of working with a web-based WYSIWYG editor. The user experience of writing into this wiki is as good or better than working in MS Office documents, which really helps overcome any objections anyone could have based on the UX of the tool.
- The wiki space became an enduring resource itself, beyond the course experience, serving as a place where learners could read deeper on topics they found interesting, and a place where the SMEs could continuously update to reflect new information. As a result, we were able to give a brief and breezy introduction to the content within the course space, and still link out to a highly detailed, up-to-date resource that would always reflect the latest information.
- We uploaded the course videos to a cloud video hosting platform, allowing us to simply add embed code into the course experience and the wiki so we could update the videos once and changes appear in both locations.
- The wiki also had communication tools like in-text comments, twitter-style @mentions, and tasks that can be assigned and resolved, serving as a to-do list. These just gave us further tools for staying in touch and connected through changes in the content.
Reflection on this Approach
Overall, this approach added a great deal of value over our previous method of sharing content, in which SMEs would send us PowerPoints and Word docs in a OneDrive folder. The wiki interface encourages users to think of the content as a work-in-progress, continually evolving through collaboration, while a folder full of Office docs sends the message that the content is in its finished form. Adding additional pages and linking to them is a simple mouseclick, and it creates the feeling that the container can expand to fit the content, no matter what “shape” it finally takes. Contrast this to working in a Word doc and realizing you have an altogether different type of content that ideally should live on a different page but linking out from one doc to another would be awkward at best, impossible at worst.
Finally, the beauty of a wiki is that it is both a finished product and a work-in-progress at the same time. Any time you visit a wiki you’re seeing how it looks now, so there’s a sense to polish it as if it’s a finished web page. However, it’s also easy to make small improvements each time you visit, so you can keep iterating over time.
In this project, that meant that the collaboration space was not thrown away once the finished product (the online course) was done — as is so often the case with a cloud folder of files. Rather, the collaboration space became a valuable resource on its own, supplemental to the online course, allowing us to go into greater detail for the benefit of both learners and authors (who will surely need to provide documentation for this product).
Not All Wikis are Created Equal
I realize that not all wikis are created equal, and that this Confluence wiki tool we’re using is an unusually robust (paid, enterprise) tool compared with the more common open-source and free solutions that readers are likely to have easy access to. However, there are A LOT of wiki tools out there, all focused on different types of users and use cases, so it’s worth your time to familarize yourself with the major players (MediaWiki, TiddlyWiki, DokuWiki) as well as the new breed of flat-file wiki CMS tools like GitHub Gollum, Wiki.js, or BookStack.
In Conclusion….
I hope this article leaves you with the idea that the popular cloud file sharing tools like GDrive/OneDrive/Dropbox are not the only way to support your collaboration — they’re not even necessarily the best way. Wikis have long been the uncool older brother to these new, shiny cloud tools, but they possess unique features that continue to offer benefits to collaborative teams. The greatest benefit, in my opinion, is the ability to keep all your content in web-friendly formats the whole way through the content development process. This heads off formatting problems when you’re trying to get your content out of a proprietary platform that doesn’t want to give it back gracefully.
Liked this post? Follow this blog to get more.
