This Chair is Too Small: The Case Against Individual Authoring Tools

With today's file-based approaches, developers have flexible, rapid-development toolkits that allow them to develop in wizard-based, WYSIWYG development environments with standardized Web delivery formats. In comparison with the toolkits available even just ten years ago, today's tools enable richer, more interactive content (Flash, video, test interactions, etc.), yet require minimal technical expertise. Today's tools are also typically much faster - for example, many tools enable you to import a PowerPoint presentation into the course environment, enabling a developer to start with base material and either publish "as-is" to SCORM or AICC or extend and augment the material with additional interactions. In the past, either option would have required a full rebuild of the course material.

While these advancements allow for a richer learner experience and a "simplified" developer experience, they haven't fundamentally expanded the developer toolkit. The overall development solution, while faster, is still missing several elemental features. Chief among the limitations is the lack of any collaborative features.

In the absence of collaborative authoring environments, eLearning teams must manage several key processes manually or through external systems:

1. Simultaneous, parallel development
2. Task and project management
3. Reusing and recycling existing content or assets in multiple courses
4. Subject matter expert content contribution
5. QA review and approval

Depending on the specific tool, some of these issues are more problematic than others. Simultaneous, parallel development, for instance, may just not be possible in certain tools, no matter how hard the development team tries to bend the tool. Regardless of whether the impact can be mitigated, each of these externally managed processes has an associated business cost.

Subject Matter Expert & QA Review

In most tools, subject matter experts (SMEs) and quality assurance specialists can often only review the material after the course is compiled and deployed. This means that for each development version, all of the current files need to be assembled and posted. It also usually means that development ceases during the review cycle so that comments and edits can be incorporated into the next version of the course material. This linear development process, while necessary to ensure final quality, extends development timelines significantly.

Another challenging aspect of the review process is the communication between reviewers, such as subject matter experts and QA teams, and the development team. In most individual authoring tools, the review process occurs wholly outside the tool, through email, spreadsheets, documents, and sometimes even paper. When the team includes just one reviewer and one developer, this process might be marginally tenable. With larger teams, however, this process can become a project unto itself. Feedback and comments are often lost in translation, mishandled, misunderstood, or ignored. This has the effect of extending timelines and can impede the overall quality of the project.

In an externally managed QA process, it is often difficult to create comprehensive reports and audit trails, which can be problematic in highly regulated industries. These same reporting issues make it difficult to check a "pulse" of the project's status, resulting in missed deadlines and a long-term inability to identify trends for improving quality and process.

Task and Project Management

With today's authoring tools, teams also rely on external mechanisms to track project progression and individual tasks. Use of programs such as MS Project or spreadsheets is common. In this model, individual developers perform their actual work in one system and then update the external project tracking system independently, which actually creates more work. In this sort of process, there is also no way for a developer to see tasks in the context of the actual content or development environment.

Reusing and Recycling Existing Content or Assets in Multiple Courses

When development occurs in individual authoring tools, the outcome is almost always a file or a collection of files. These are typically stored on a file server, or in more sophisticated models, a version control system. In either case, the content is a "black box" - aside from creative use of file naming conventions, the other team members don't have any way of knowing what is in the file. This makes the reuse or repurposing of that content extremely difficult, sometimes even impossible.

A related issue is the question of logical vs. learning granularity. In a hierarchical directory structure, a file represents the atomic level of granularity. In a learning or course development model, the atomic level of granularity might be a piece of media or an interaction. These levels of granularity are not equivalent. It is often the case that multiple pages of learning exist in a single physical file. As a result, the course itself is not logically organized into physical files that match its course structure. For the individual attempting to reuse assets or the individual attempting to share them in the first place, this makes it all but impossible to find and reuse content.

The above issue of granularity can also lead to the challenge of "Frankenstein" courses. With many individual authoring tools, the interface "look" is built into the content. Reuse and repurposing, therefore, must also include time for tweaking the material to reflect the look and feel of the new course. Failure to do so results in a course where the learner sees varying graphical themes and navigation models as they progress: a Flash element from this course, a navigation layer from this one, a graphic from yet another. Addressing these inconsistencies can add considerable time to the overall development process.

A related issue is the inherent inability of individual authoring tools to enforce instructional design standards. A common problem in larger, distributed teams is inconsistency in the instructional design and overall course quality. While a problem unto itself, this further complicates the issue of reuse.

Even if a team manages to overcome the aforementioned challenges, there is still one remaining hurdle: Network access and domain-related issues. In distributed teams, individuals may not be on the same network and may not be able to easily see other's assets. Access rights and other, similar issues also need to be considered, especially for teams that work remotely or at multiple locations, which is often the case for consultants or off-shore partners.

Simultaneous, Parallel Development

Individual authoring tools are just that - tools for individual authors. They do not allow people to work in parallel on the same project. At best, one person can work independently and provide course elements to a project owner who may, in some tools, be able to import the work. At worst, the only course assets that can be pushed this way are external media such as images, audio, video and Flash. In either case, it's impossible for multiple developers to work on different pages of the same course while in the same development environment. Each person is essentially an independent island without the ability to access or view other team members' work or progress, aside from external communication channels.

These environment limitations make it very difficult to scale a development team to fit a larger project. In tight time frames when multiple team members might be available to assist in completing a project, that resource availability becomes irrelevant due to bottlenecks in the development environment itself. In cases where tools do allow some ability to import and use course assets developed on someone else's machine, the team still does not receive the maximum value of the available resources because one of these individuals needs to manage the imports and assign the work. Again, teams encounter associated project management overhead that must happen outside of the tools because these activities are not supported natively.

A related issue is the inability for developers to "pick up" where someone left off in the event of an illness or a computer crash. Absent rigorous backup procedures and extensive network file transfers, the source material for a given project or group of projects resides on the individual developers' machines. In the event of a hard drive failure or similar crash, the source material for entire courses could be lost. In less dire circumstances, illness may derail a project-not because someone else is unable to complete the work, but because the files only exist on one person's machine.

Subject Matter Expert Contribution

As timelines shrink, the old model of extensively interviewing SMEs for subject matter information is collapsing. Today, the two biggest aspects of eLearning development on many projects are design and QA. The challenges facing design are no less severe. As long as SME involvement exists outside of course development, so do opportunities for misunderstanding and confusion. If SMEs can be more directly involved in production, some of this design time can be eliminated in favor of collaborative design sessions and direct contributions from SME's as developers.

Summary

The combined business impact of these aforementioned challenges is significant. While this model provides many benefits to individual developers, it does so at the expense of team efficiency and overall development productivity. In this model, externally managed processes significantly slow down development, specifically with regard to design, project management, and review. The file-based model exposes projects to significant risk that would be unacceptable with other intellectual property or company assets, and the inability to share and reuse work across teams or even within teams significantly reduces the possible value of each learning investment. Rather than maximizing the ROI of each Flash or media file that is built, a file-based development model essentially restricts the possible value by making it difficult to reuse that asset across multiple courses.

In essence, today's file-based development practices are hindered by the lack of collaboration features. Design and QA cycles now consume a much larger relative percentage of time than they ever have, not because these efforts have become significantly more complex, but because the tools have become much more efficient in the production of robust content, while the development effort tied to design and QA is essentially unchanged. What is required now are tools that specifically address design, collaboration, and review as part of the overall model so that the development efficiency associated with these other aspects of course creation can be similarly improved.

Read part 3: This Chair is Too Big: The Case Against Individual LCMS Tools