One thing that sets EdBooks apart as a 21st century publisher is our approach to content development. We eschew many traditional product publishing practices and, instead, employ something more akin to a software development model.

Here are some of the ways we follow a software development paradigm in our content and product development.

Modular design with reusable code

Software development often employs a modular product architecture. This approach separates the functionality of software programs into independent, interchangeable modules, which are written independently and then assembled at a later time.

There are a number of benefits to this modular approach. First, it allows teams to to work semi-independently on different modules. This supports project assignments based on the skill specializations of developers.

Modular software development has other advantages as well. It results in modular products that are highly flexible, meaning it is much easier to provide customization for clients who want to use a product but don’t need specific modules. In addition, the different modules used in this type of software development are often reused across different projects, resulting in much greater efficiencies.

At EdBooks, our Stackable Lessons™ technology is designed as part of a modular content development framework. We create independent, self-contained content blocks that can be stacked and reused flexibly across products. This allows us to create course-based media books by grouping and assembling approximately 120 related lessons. However, if a client wants to remove or shuffle lessons, there is no loss of product integrity.

Moreover, our modular approach allows us to reuse lessons efficiently across multiple products, without redevelopment. For example, in our modular process, we only need to develop 1 lesson that provides a historical context for the Renaissance period. This same lesson can be used, without modification, across a number of courses — Western Civilization. Literature and Western Civilization, Art and Western Civilization, and Introduction to Christianity.

Finally, a modular design — both our Stackable Lessons™ and the independent content sections within those lessons — gives us greater flexibility in our content development workflows. For example, multiple authors can work on the same lessons, each one focusing on a specific element that matches his or her skillset or interest more directly.

Agile processes

15 years ago, when I first began working on designing and developing software platforms, we used a standard “waterfall” development model. In this model, companies design and deliver large platform releases that flow downward through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. After months or years of development, a product or update is finally released into the market.

This contrasts with an “agile” model, which is based on continuous planning, frequent iteration and releases, and continuous feedback. This model is lightweight and inherently adaptable. It focuses on empowering people to collaborate and make decisions together quickly and effectively.

From an organizational perspective, EdBooks works agily by establishing an overall product vision and allowing individual process and module owners to work independently on the best expression of that vision for their specific component or module. This applies to authors, editors, media developers, and platform developers. These owners communicate constantly and seek internal feedback during development cycles to ensure that their work remains in alignment withthe overall vision.

We augment internal communication/feedback by releasing individual lessons as quickly as possible into a public library through a partnership with TEL Library. This allows for initial feedback and immediate revision.

Finally, there is a continuous evaluation layer to our work that involves weekly and monthly examination of design decisions, process and feedback. From an overall development perspective, we ask how we can leverage the modular nature of our product into more modular development components. We are also concerned with balance specialized and non-specialized skills where they make the most sense.

Layered feature development

In software development, having a layered-feature architecture means designing core functionality with the most basic features with a plan to layer additional features or expanded functionality on top of the original foundation. A layered-feature model assumes the development of minimum viable products (MVPs) that will evolve over time with continuous feedback.

This model and mindset is about both architecture and process. We must design an initial architecture that anticipates this kind of expansion (and scale), as well as processes based on rapid feature development and continuous feedback.

At EdBooks, our core content product consists of two primary elements — information architecture and learning design. Our information architecture — in the form of taxonomies and connected vocabularies — is inherently flexible and extensible. Our learning environment design is completely modular so that we can extend, rearrange, and delete components over time with minimal disruption.

Our layered-feature development model is supported by a highly granular content model. Each content section in the learning environment for our Stackable Lessons™ is a self-contained element with its own product and pedagogical purpose. We can expand the design easily to include new elements or content features.

Rapid feature development

Many developers today prefer a rapid application development (RAD) model for building products. This also applies to individual features or modules within an application. This approach emphasizes building prototypes, releasing MVPs and individual product features quickly into the market, and being willing to adapt requirements and priorities based on internal and external (user) feedback.

With rapid feature development, teams work within company-established quality thresholds for functionality and user experience, but do not insist on “perfection.” Prior to releases. The spirit of this approach is captured well in the Mark Zuckerberg famous mantra, “Done is better than perfect.”

At EdBooks, we have robust editorial and product QA processes that are present throughout every part of our product workflow. We are keenly aware, however, that these are only one part of testing for a quality learning product. We must also evaluate our products’ learning effectiveness. We believe the best way to do this is to release lessons quickly to market, once they meet established quality thresholds, and receive feedback from learners. We do this through our partnership with the public, non-profit TEL Library for life learners, as well as via continuous pilot cycles. As we receive feedback, we make rapid and frequent revisions as necessary.

css.php